- From: Peter Eckersley <pde@eff.org>
- Date: Sun, 8 Mar 2015 04:49:17 -0700
- To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Cc: public-webappsec@w3.org
On Fri, Mar 06, 2015 at 07:11:29PM +0100, Daniel Kahn Gillmor wrote: > Here's a strawman: > > * create a new HTTP Response header, HSTS2. HSTS2: has the same > semantics as Strict-Transport-Security:, except that it should only > be implemented by clients that do opportunistic upgrade of blockable > mixed content (that is, they try a secure upgrade for subresources > instead of blocking insecure content). > > New clients can do opportunistic upgrade of blockable mixed content on > any secure connection. Server operators can choose to opt into either > Strict-Transport-Security: or HSTS2:, depending on whether their sites > require this upgrade of blockable mixed content to work securely. Instinctively I like this plan slightly better than upgrade-insecure, if it can be landed as swiftly -- doing the upgrades by default reduces the number of new/obscure web features that site operators need to learn about. One problem with it that I realised after we talked last week was that it wouldn't give sites an elegant way to perform the HTTPS -> HTTP downgrades they'd need in order stay unbroken on browsers with MCB but no HSTS2 support. -- Peter Eckersley pde@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Received on Sunday, 8 March 2015 11:49:47 UTC