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

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

From: Mike West <mkwst@google.com>
Date: Mon, 16 Mar 2015 10:26:39 +0100
Message-ID: <CAKXHy=e4kuHX6FoaeywKGydfZ9AZH1dcxs9OWkXmqmfCX9x6vw@mail.gmail.com>
To: Peter Eckersley <pde@eff.org>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eric Mill <eric@konklone.com>
On Mon, Mar 16, 2015 at 10:11 AM, Peter Eckersley <pde@eff.org> wrote:

> Daniel's proposal to make UPGRADE-like behaviour the default (with HSTS2
> as a way to make HSTS safely enableable on the same origins) allows
> sites to do resource-specific, or user-specific, migration from HTTP to
> HTTPS if they want to.

How? Without an explicit signal (from the server or the client), it's not
clear to me how you'd choose which users you could safely send to HTTPS for
a given resource. Could you spell this out in a little more detail?

(As an aside: I don't at all think that Daniel's proposal runs counter to
the UPGRADE spec. I think we can evaluate how to make aspects of that spec
default behavior in parallel to shipping it as an opt-in.)

> Is the main issue that you're flagging here the fact that sites can't
> similarly UPGRADE the optionally blockable mixed content on the
> resources of their choice?

The main issue I was flagging was control, and it's not clear to me how
you're proposing that it would be dealt with in an on-by-default world.
Maybe we're proposing the same thing? :)

Optionally-blockable mixed content is certainly also an important issue,
though, as it creates UI degradation, which developers very much wish to
avoid (as noted in #2 in the email you're responding to).

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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 16 March 2015 09:27:27 UTC

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