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

On Thu, Mar 19, 2015 at 7:24 PM, Peter Eckersley <pde@eff.org> wrote:

> > 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.
>

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. :(


> > 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.
>

I've cleaned up the pull request at
https://github.com/w3c/webappsec/pull/209, and merged it into the draft.
This does a few things:

1. Adds `HTTPS: 1` to all outgoing navigational requests that aren't
"preloadable" via the `preload` directive.
2. Drops the `Upgraded: 1` header, as it's a somewhat useless signal if
we're sending `HTTPS: 1`.
3. Adds a number of definitions and brought in a number of HSTS concepts in
order to make some of the explanations more clear.

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?

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Friday, 20 March 2015 13:23:04 UTC