W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: CfC to publish a LCWD of CSP 1.1

From: Brad Hill <hillbrad@gmail.com>
Date: Fri, 20 Jun 2014 09:04:06 -0700
Message-ID: <CAEeYn8gQv5XFz08ET2FSUfeuiuQGbEcbkKad2MNfZCx0Nn0WMg@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Glenn Adams <glenn@skynav.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>, Sigbjørn Vik <sigbjorn@opera.com>, Wendy Seltzer <wseltzer@w3.org>, Adam Barth <w3c@adambarth.com>
We queried Microsoft on the call.  They'll get back to us.  Mozilla doesn't
have a reflected xss filter/auditor so that's where I think the potential
issue lies.

On Fri, Jun 20, 2014 at 1:03 AM, Mike West <mkwst@google.com> wrote:

> On Thu, Jun 19, 2014 at 1:41 AM, Brad Hill <hillbrad@gmail.com> wrote:
>> 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:
> Hooray!
>> 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.
> 3.5 months is a long time, even during the summer. Do you think we really
> need that long? If there's consensus, great, but I'd suggest something more
> like 8 weeks. I'd like to keep things moving, and that already seems like a
> reasonably long period of time for feedback.
>> 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?
> The privacy interest group would be reasonable, given previous concerns
> about the reporting functionality. I'd also suggest looping the Web
> Applications WG in, as CSP looms large in interaction with things being
> specified in that group.
>> 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.
> Blink has implementations of both these directives. If other vendors
> (Mozilla? Microsoft? Apple?) aren't interested, then we could certainly
> mark them as "at risk" (although I think it's premature, since we haven't
> yet issued a call for implementations). Perhaps folks from those browsers
> could weigh in?
> -mike
Received on Friday, 20 June 2014 16:04:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC