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

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