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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC