- From: Mike West <mkwst@google.com>
- Date: Tue, 16 Dec 2014 10:15:49 +0100
- To: Brad Hill <hillbrad@gmail.com>
- Cc: 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=dwBYizg-iaXeFi8XZCG3eBmewRXWfsG3YahQeV3tMq4A@mail.gmail.com>
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 Tuesday, 16 December 2014 09:16:38 UTC