W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

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

From: Mike West <mkwst@google.com>
Date: Fri, 16 Jan 2015 06:24:55 +0100
Message-ID: <CAKXHy=fTJS_=rB5mM94q6P5sBZtGSzs-87poX=VJ+gzsdzhwKQ@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: Brad Hill <hillbrad@gmail.com>, Brian Smith <brian@briansmith.org>, Michael Cooper <cooper@w3.org>, David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Great! I'll update the "at risk" list accordingly:
https://github.com/w3c/webappsec/commit/57e40cbd64bd8ff9d6c9b814f4c52b6c37288ca5

-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 Thu, Jan 15, 2015 at 9:22 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:

>  Dan and I brought this up on Monday's call because we were worried about
> it being added to the spec late in the Last Call period.  But after looking
> at Chrome's implementation and discussing it further, I have no objection
> to keeping strict mode in the spec as written.
>
> Thanks!
>
> ~Tanvi
>
>
>
>
> On 12/16/14 10:25 AM, Brad Hill wrote:
>
> 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.)
>>>>>
>>>>>>
>
Received on Friday, 16 January 2015 05:25:44 UTC

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