- From: Mike West <mkwst@google.com>
- Date: Fri, 16 Jan 2015 06:24:55 +0100
- To: Tanvi Vyas <tanvi@mozilla.com>
- Cc: Brad Hill <hillbrad@gmail.com>, Brian Smith <brian@briansmith.org>, Michael Cooper <cooper@w3.org>, David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=fTJS_=rB5mM94q6P5sBZtGSzs-87poX=VJ+gzsdzhwKQ@mail.gmail.com>
Great! I'll update the "at risk" list accordingly: https://github.com/w3c/webappsec/commit/57e40cbd64bd8ff9d6c9b814f4c52b6c37288ca5 -mike -- Mike West <mkwst@google.com>, @mikewest 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.) On Thu, Jan 15, 2015 at 9:22 PM, Tanvi Vyas <tanvi@mozilla.com> wrote: > Dan and I brought this up on Monday's call because we were worried about > it being added to the spec late in the Last Call period. But after looking > at Chrome's implementation and discussing it further, I have no objection > to keeping strict mode in the spec as written. > > Thanks! > > ~Tanvi > > > > > On 12/16/14 10:25 AM, Brad Hill wrote: > > LGTM! Thanks. I'm running it by some other Facebook folk to see if they > have further thoughts. > > On Tue Dec 16 2014 at 1:40:40 AM Mike West <mkwst@google.com> wrote: > >> FWIW, this definition of strict mode turns out to be pretty trivial to >> implement in Blink: https://codereview.chromium.org/811773002/ is up for >> review to put it behind the experimental flag so we can start playing with >> it. I'm hopeful it would be equally simple to poke at in other engines. >> >> -mike >> >> -- >> Mike West <mkwst@google.com>, @mikewest >> >> 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.) >> >> On Tue, Dec 16, 2014 at 10:15 AM, Mike West <mkwst@google.com> wrote: >>> >>> I don't think this has much to do with your cluefulness, but rather with >>> the sloppily written strawman. I've dropped the <iframe> bit and clarified >>> the effects of strict mode in the hopes of being a bit more comprehensible. >>> WDYT of https://w3c.github.io/webappsec/specs/mixedcontent/#strict-mode? >>> >>> -mike >>> >>> -- >>> Mike West <mkwst@google.com>, @mikewest >>> >>> 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.) >>> >>> On Mon, Dec 15, 2014 at 10:39 PM, Brad Hill <hillbrad@gmail.com> >>> wrote: >>>> >>>> Yes. Upon a more careful re-read, I see there is one more algorithm >>>> that needs to be updated. >>>> >>>> if(mkwst.confused) /* shouldn't happen */ { >>>> doubleCheck(brad.clue) >>>> } >>>> >>>> On Mon Dec 15 2014 at 11:52:38 AM Mike West <mkwst@google.com> wrote: >>>> >>>>> On Mon, Dec 15, 2014 at 8:48 PM, Brad Hill <hillbrad@gmail.com> >>>>> wrote: >>>>>> >>>>>> Aha, yes, my mistake. >>>>>> >>>>>> So then I more emphatically suggest that we need a resource-level >>>>>> flag. One of the other unfortunate things ads do is start as a <script> >>>>>> tag and then dynamically inject an <iframe>. Preventing any HTTP requests >>>>>> from happening in descendant contexts seems a reasonable goal. (even if >>>>>> <script> => <iframe> is a horrible pattern) >>>>>> >>>>> >>>>> Right. That's what the CSP header would do, right? >>>>> >>>>> I guess what you're saying is that we don't need both the header and >>>>> the attribute. That is, if you opt into strict checking for a protected >>>>> resource, then it and all of its descendents block all mixed content >>>>> period. That property makes the <iframe> attribute a bit superfluous, and >>>>> there's probably no good reason that you'd want a single frame to be >>>>> strictly processed while others weren't. >>>>> >>>>> Is that your point? >>>>> >>>>> -mike >>>>> >>>>> -- >>>>> Mike West <mkwst@google.com>, @mikewest >>>>> >>>>> 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 Friday, 16 January 2015 05:25:44 UTC