- From: Jose Kahan <jose.kahan@w3.org>
- Date: Mon, 21 Sep 2015 13:48:59 +0200
- To: Mike West <mkwst@google.com>
- Cc: Wendy Seltzer <wseltzer@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Sep 21, 2015 at 01:27:48PM +0200, Mike West wrote: > > > > That's not possible. We have too much content and this is what > > the combination of HSTS and Upgrade-Insecure-Requests is supposed > > to do. > > > > I do hope that you see `upgrade-insecure-requests` as a transitional phase, > and that you're working to fix the mixed content errors on the site, rather > than relying on browser support in perpetuity. We need a solution that will allow to assume all content is https, in perpetuity, without needing to upgrade all legacy content. We cannot do a systematic redirection from HTTP to HTTPS for the moment. > I guess it's not clear to me why you're fine with the current setup for > browsers like Safari, but aren't fine with it for Firefox? Wouldn't you > just treat Firefox like every other browser that doesn't support the > upgrade directive? That is: > > * If you don't see an `upgrade-insecure-requests` header in the navigation > to `http://w3.org/`, don't redirect to HTTPS. That's how we set it up. > * If you don't see an `upgrade-insecure-requests` header in a navigation to > `https://w3.org`, downgrade to HTTP (and don't serve HSTS)? > > This use case is why we added the signaling header. :) That doesn't make sense. When browsing protected resources, you need HTTP, you cannot downgrade it to HTTP systematically. What I think you mean to say is that for public resources, apply the rule you said. I may be missing some of the context in your statement. -jose
Received on Monday, 21 September 2015 11:49:10 UTC