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

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.)
>>>
>>>>