- From: Peter Eckersley <pde@eff.org>
- Date: Fri, 20 Mar 2015 08:56:44 -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 Fri, Mar 20, 2015 at 02:22:15PM +0100, Mike West wrote:
> On Thu, Mar 19, 2015 at 7:24 PM, Peter Eckersley <pde@eff.org> wrote:
> I'd suggest that we publish a new working draft with this content, and
> start experimenting with implementations to see if these things that we've
> been talking about are going to effectively meet developers' needs.
>
> WDYT?
Sounds great.
> > That's right. Once an origin is committed to HSTS for every client, the
> > header is retired for that origin.
> >
>
> I very much hope we can find new carveouts in the future. It's fairly
> utopian to suppose that substantial amounts of traffic will be covered by
> this one. :(
I can see a way to further reduce the bytes-on-the-wire cost of the new
draft, though I'm not sure I'm actually advocating it:
HTTPS: 1 -- this client supports upgrade-insecure
HTTPS: 2 -- this client upgrades blockable mixed content by default
HTTPS: 3 -- this client has HSTS active for this origin
HTTPS: 4 -- this client has HSTS active and is
upgrading *all* mixed content by default?
The availability of 2 and 4 would allow servers to avoid sending the CSP
header in many additional cases. If our worries about the HTTPS: header
are about bytes on the wire, this might alleviate them, though it
doesn't help if our main worries are about protocol complexity.
--
Peter Eckersley pde@eff.org
Technology Projects Director Tel +1 415 436 9333 x131
Electronic Frontier Foundation Fax +1 415 436 9993
Received on Friday, 20 March 2015 15:57:16 UTC