- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 3 Feb 2015 11:50:39 +0100
- To: Mike West <mkwst@google.com>
- Cc: Ryan Sleevi <sleevi@google.com>, "Eduardo' Vela" <evn@google.com>, Wendy Seltzer <wseltzer@w3.org>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>
On Tue, Feb 3, 2015 at 11:16 AM, Mike West <mkwst@google.com> wrote: > Let's say we introduce Eduardo's "upgrade-unsafe". What would you expect it > to do? > > I'd expect it to blindly rewrite first- and third-party HTTP images (and > etc.) to HTTPS before fetching, which would simply fail for images > unavailable over HTTPS. It's not clear to me that that's really worse than > the browser telling the user that the page is insecure, and it seems like > different site authors would react differently. This is what I would expect. And from experience with deploying TLS on whatwg.org and html5.org I know that we had made sure that the thirty or so domains for in use (for both primary and subresources) supported TLS. It was just an enormous hassle to make sure that the content also matched that. If we had a header to upgrade the content deployment of TLS would have gone a lot smoother. > An alternative would be to rewrite first-party requests only. Would that > address enough of the problem to be worth offering? No, often you have e.g. resources.domain.example or potentiallyinsecuresubresources.example to avoid cookies in requests, as a simple means of load balancing, or simply because it makes it easier to manage resources in that way. -- https://annevankesteren.nl/
Received on Tuesday, 3 February 2015 10:51:04 UTC