Re: CfC to publish a LCWD of CSP 1.1

We discussed this on today's call.  The consensus was that the
outstanding issues can proceed to full resolution during LC, and we
can advance, but a few issues were raised I'd like to work out here
before finalizing the transition:

1) How long should the LC period be?   Dan pointed out that summer is
difficult to enlist people's time.  I suggested that perhaps we end LC
immediately before TPAC and we can use the session time there to
resolve any issues raised.

2) Who should we specifically reach out to for review and comment?
I'd suggest the WHATWG Fetch team (though they are watching this list
already), the IETF WebSec group, and W3C Security IG as a start.  Also
SVG WG.   Others?

3) Glenn asked if we want to mark any features as "at risk" at this
time.  It's not necessary, but good to start thinking about it now.
The referrer and reflected-xss directives come to mind both because of
current discussions to possibly move them elsewhere, and because we
only have one confirmed intent to implement reflected-xss at this
time.

-Brad

On Wed, Jun 11, 2014 at 7:37 AM, Glenn Adams <glenn@skynav.com> wrote:
> +1 for LCWD
>
>
> On Wed, Jun 11, 2014 at 2:14 AM, Mike West <mkwst@google.com> wrote:
>>
>> Hello, lovely Webappsecians,
>>
>> Over the last week or two, I've landed some changes to the spec which (I
>> hope) resolve the outstanding issues folks have raised since I last asked
>> about moving to last call (in January[1]). The remaining open issues on both
>> GitHub and the webappsec tracker are targeting CSP 1.2, which I'd like to
>> get started on once CSP 1.1 is safely on it's way out the door.
>>
>> I think CSP 1.1 is ready to move on; I'd like to see if the group agrees,
>> hence this Call for Consensus to move to Last Call. Best case, you all
>> agree. Hooray! Worst case, this is a forcing function for all of you to note
>> the things you consider blockers, which is also a good outcome. :)
>>
>> Please read through the current draft, up for review at
>> https://w3c.github.io/webappsec/specs/content-security-policy/, and send
>> comments to public-webappsec@w3.org. Positive feedback is encouraged.
>>
>> This CfC will end at our next scheduled call (June 18th, 2014).
>>
>> ---
>>
>> The only major issue raised between January and now was covered in the
>> long thread concerning redirects and paths (and, tangentially, all of CSP's
>> reporting) that started at [2]. The resolution proposed in the draft is the
>> following:
>>
>> * After a redirect, the path component of source expressions is ignored,
>> as noted in
>> https://w3c.github.io/webappsec/specs/content-security-policy/#source-list-paths-and-redirects
>>
>> * Redirects are blocked by default: authors must opt-in to enabling
>> redirects (which must still match directives' source list) via the new
>> 'unsafe-redirect' source expression:
>> https://github.com/w3c/webappsec/commit/d1fd42a6df58ef2a7afedcd12ae2bff76a096d1a
>>
>> * Reporting does not include the origin of a redirect's target, but only
>> the origin of the originally requested URL.
>>
>> I believe this is a reasonable set of compromises for CSP 1.1, does the
>> working group agree? Are there additional issues that need to be resolved
>> before LC which shouldn't be punted to CSP 1.2? Now's the time to speak up!
>>
>> [1]:
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0121.html
>> [2]:
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html
>>
>> --
>> Mike West <mkwst@google.com>
>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>>
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
>

Received on Wednesday, 18 June 2014 23:41:39 UTC