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

Hi Daniel!

I'd originally misunderstood your proposal as linking the upgrade behavior
to the presence of the HSTS2 header. Now I understand that you'd like
something similar to the UPGRADE spec to be the default behavior for sites
delivered over HTTPS. HSTS2 only comes into the discussion as a way of
locking those clients that upgrade into HTTPS.

I'll trim out the vast majority of the discussion below to try to stay
focused on the core questions. If I trim something you think is important,
just bring it back in. :)

On Tue, Mar 10, 2015 at 2:03 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> if the default for new User Agents is to upgrade blockable mixed
> content, then site operators don't have anything to do at all to those
> resources on their site that only need an upgrade.
>

I do agree that user agents should experiment with this kind of behavior
for blockable mixed content.

However, I don't think that's going to be enough to enable publisher
migration, for three reasons:

   1. The amount of work that has gone into HTTPS Everywhere regexen shows
   that HTTP and HTTPS versions of a host often have complex relationships
   with each other. Forbes.com is the canonical example, but it's certainly
   not the only one. Browser vendors will need to carefully evaluate whether
   automagically switching to HTTPS for some requests will do more harm than
   good. I don't think that's going to happen quickly.

   2. Optionally-blockable content is even trickier, but we need to address
   it in order to allay publisher concerns regarding the security UI the user
   agent presents. On this point, Netflix's response to a recent
   insecure-XHR-for-media proposal[1] is instructive: if the browser
   (accurately) shows a mixed content warning, they won't upgrade to HTTPS,
   period.

   3. Finally, there's the central question of risk and motivation. I'd
   like to target those authors who are on the fence about migrating to HTTPS.
   I expect those authors to be skeptical about their TLS configuration, and I
   would like to give them a way of slowly rolling out behaviors across their
   user base in order to gain confidence and fix bugs for a subset of users,
   before turning on a behavior for everyone. I don't think they'll accept
   anything less.

A resource-specific opt-in that covers both content types seems to provide
a path forward on these problems (and certainly doesn't prevent user agents
from experimenting with changing behavior for blockable mixed content in
parallel).

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