- From: Brad Hill <hillbrad@gmail.com>
- Date: Fri, 20 Jun 2014 09:04:06 -0700
- 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>
- Message-ID: <CAEeYn8gQv5XFz08ET2FSUfeuiuQGbEcbkKad2MNfZCx0Nn0WMg@mail.gmail.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