W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2013

Re: [webappsec] Reminder: please send your preferences

From: Neil Matatall <neilm@twitter.com>
Date: Tue, 8 Oct 2013 09:29:59 -0700
Message-ID: <CAOFLtbgkbZBMA_3bDOO2qYBDTd+ag+TUqXcfv1Fwfq0ZTYFgTw@mail.gmail.com>
To: "Carson, Cory" <Cory.Carson@boeing.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
> 1: We should close the feature set of CSP 1.1?  Agree / Disagree

agree

> 2. We should include the application of 'unsafe-eval' semantics to the CSSOM in the core CSP 1.1 feature set? Agree / Disagree

Defer

> 3. We should include the suborigin sandboxing proposal in the core CSP 1.1 feature set? Agree / Disagree

Disagree

> 4. We should include the "Session Origin Security" policy in the core CSP 1.1 feature set?  Agree / Disagree

Disagree

> 5. We should include the "cookie-scope" policy in the core CSP 1.1 feature set?  Agree / Disagree

Disagree

> 6. We should make changes to core CSP 1.1 behavior (including possibly specifying a new directive about user script) as requested by Bug 23357?  Agree / Disagree

Disagree

> 1. Flesh out Alex Russell's (http://infrequently.org/2013/05/use-case-zero/) and Yehuda Katz's (http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/) proposals. They are substantially more interesting than what we have at the moment. This has been on my plate for months.
>2. Kill the DOM API for the moment, and do #1 in 1.2, along with a more complete integration with ServiceWorkers.
>I'd like to do #1, but #2 is probably more realistic. I'll break this out into a separate thread.

I agree this should be discussed :) I'm leaning towards #2...

On Mon, Oct 7, 2013 at 3:01 PM, Carson, Cory <Cory.Carson@boeing.com> wrote:
>
>
> From: Brad Hill [mailto:hillbrad@gmail.com]
> Sent: Thursday, October 03, 2013 5:12 PM
> To: public-webappsec@w3.org
> Subject: [webappsec] Reminder: please send your preferences
>
> This is a request again, for all WG members, to please send your response to this simple poll before our call on Tuesday:
>
> 1: We should close the feature set of CSP 1.1?  Agree / Disagree
>
> Abstain
>
> 2. We should include the application of 'unsafe-eval' semantics to the CSSOM in the core CSP 1.1 feature set? Agree / Disagree
>
> Agree
>
> 3. We should include the suborigin sandboxing proposal in the core CSP 1.1 feature set? Agree / Disagree
>
> Disagree
>
> 4. We should include the "Session Origin Security" policy in the core CSP 1.1 feature set?  Agree / Disagree
>
> Disagree
>
> 5. We should include the "cookie-scope" policy in the core CSP 1.1 feature set?  Agree / Disagree
>
> Disagree
>
> 6. We should make changes to core CSP 1.1 behavior (including possibly specifying a new directive about user script) as requested by Bug 23357?  Agree / Disagree
>
> Disagree
>
> ---
>
> Boeing is interested in suborigin sandboxing and "cookie-scope" because they address security concerns of large multi-component web applications. However, it is Boeing's opinion that 3 and 5 be incubated longer before Boeing backs them. Eg, perhaps there is a way to adjust suborigin sandboxing to include 'cookie-scope's goals?
>
>
>
>
>
Received on Tuesday, 8 October 2013 16:30:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC