- From: Mike West <mkwst@google.com>
- Date: Fri, 16 Jan 2015 06:24:55 +0100
- 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>
- Message-ID: <CAKXHy=fTJS_=rB5mM94q6P5sBZtGSzs-87poX=VJ+gzsdzhwKQ@mail.gmail.com>
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