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

Re: Strict mixed content checking (was Re: MIX: Exiting last call?)

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 15 Dec 2014 21:39:37 +0000
Message-ID: <CAEeYn8i4fkNNBfTGxkcKFUcjTkfCK1-6RXnHt8s3VDwmhn3WgA@mail.gmail.com>
To: Mike West <mkwst@google.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>
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 */ {

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 Monday, 15 December 2014 21:40:04 UTC

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