RE: Upgrade mixed content URLs through HTTP header

To answer Ryan question - we, Microsoft, are working on a responses to Eric's question to our blog post.  Hoping to have something soon.  Stay tuned.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Tuesday, February 17, 2015 12:52 PM
To: Tom Ritter
Cc: Mike West; Tanvi Vyas; John Wong; Devdatta Akhawe; Alex Russell; Joel Weinberger; Emily Stark; Jim Manico; public-webappsec@w3.org; Anne van Kesteren; Adam Langley
Subject: Re: Upgrade mixed content URLs through HTTP header

Hopefully Microsoft will reply to
http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx#10593884


Particularly relevant to this are questions 2 and 3.

On Tue, Feb 17, 2015 at 12:49 PM, Tom Ritter <tom@ritter.vg> wrote:
> On the topic of using HSTS to blocked mixed content, it seems like
> IE10 has just done that:
> http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-se

> curity-comes-to-internet-explorer.aspx
>
> I haven't tested it though, so I'm not sure if it's active, passive, or both.
>
> -tom
>
> On 9 February 2015 at 02:37, Mike West <mkwst@google.com> wrote:
>> Hey Tanvi!
>>
>> On Fri, Feb 6, 2015 at 8:27 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
>>>
>>> * Option 1 - Fallback and try the HTTP version; the mixed content 
>>> blocker will be invoked and the content will be blocked if it is 
>>> blockable with an option for the user to override the blocking 
>>> (shield shows up in Firefox and
>>> Chrome) or loaded if it is optionally blockable with a degraded security UI.
>>> * Option 2 - No attempt to access the HTTP version and no mixed 
>>> content UI.
>>>
>>> Option 2 will result in a user experience that is worse than the 
>>> current experience with mixed content blocking.  Also, with Option 
>>> 2, sites may be less likely to set the CSP directive because it 
>>> could potentially break their site. Hence, I like Option 1 where we fallback to the HTTP version.
>>> But this could cause performance issues since in the fallback case 
>>> we are doing two resource loads instead of one.
>>
>>
>> The strawman I posted is option #2; resources are upgraded, and if 
>> the upgrade fails to target a viable resource, you'll end up with a 
>> network error, just as you would if you typed the upgraded URL manually.
>>
>> The intention is that only sites for which this behavior provides a 
>> net gain will opt-into it. So, while I agree that there's some risk, 
>> it can be a calculated one which sites can choose to opt-into.
>>
>>>
>>> We could also have Option 3 - only fallback for optionally blockable 
>>> subresources, since many users don't click the shield and override 
>>> protection anyway and hence end up with a similar user experience.
>>
>>
>> This is probably worth experimenting with today, especially in 
>> combination with HSTS. I worry that it's likely to have negative 
>> performance impact on sites, as it would no longer be opt-in, meaning 
>> that sites that wouldn't support upgrade for particular resources 
>> would be generating unexpected requests that they weren't prepared to handle.
>>
>> -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 Tuesday, 17 February 2015 21:52:27 UTC