- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 17 Feb 2015 12:51:35 -0800
- To: Tom Ritter <tom@ritter.vg>
- Cc: Mike West <mkwst@google.com>, Tanvi Vyas <tanvi@mozilla.com>, John Wong <gokoproject@gmail.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Alex Russell <slightlyoff@google.com>, Joel Weinberger <jww@google.com>, Emily Stark <estark@google.com>, Jim Manico <jim.manico@owasp.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
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-security-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 20:52:04 UTC