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
Flores
(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.3.1 : Monday, 23 October 2017 14:54:11 UTC