- From: Peter Eckersley <pde@eff.org>
- Date: Thu, 19 Mar 2015 11:24:59 -0700
- To: Mike West <mkwst@google.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, David Walp <David.Walp@microsoft.com>, Tanvi Vyas <tanvi@mozilla.com>, Crispin Cowan <crispin@microsoft.com>, Dan Veditz <dveditz@mozilla.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eric Mill <eric@konklone.com>
On Thu, Mar 19, 2015 at 08:31:13AM +0100, Mike West wrote: > Given this use-case, I don't understand how we'll ever be able to retire > the header. It doesn't seem possible to distinguish between legacy users > whose UA doesn't support the upgrade mechanism, and totally up-to-date > users on the other hand, without adding some information to the request. > > I think the `mixed-safe` directive is supposed to address this somehow, but > I don't completely understand the mechanism. Is it basically an assertion > that the website isn't going to be using the upgrade mechanism? That's right. Once an origin is committed to HSTS for every client, the header is retired for that origin. > If so, perhaps we could reuse the `preload` directive proposed at ` > https://hstspreload.appspot.com/` rather than inventing something new. > The thought would be that if you're willing to ask for anyone and > everyone to preload your HSTS preference, you can't be terribly > concerned about the specific capabilities of the client doing the > preloading. I agree that the existing "preload" directive looks like a better way to achieve that. -- Peter Eckersley pde@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Received on Thursday, 19 March 2015 18:25:35 UTC