W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE] Consider plan B for reduced complexity?

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>
Message-ID: <20150319182459.GX881@eff.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC