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

Remember this isn't just about user agents.  A specifically motivating use
case is sites that need to access data that is only available over http
from legacy origins which are perhaps mostly-unmaintained and may take a
very long time to get with the https program.

In such cases, it is ideal to provide an application owner a way to get
user-agent assistance in rewriting links automatically from http->https,
a-la-HSTS, but not simultaneously force entire origins to be exclusively
available over https, since they may need to occasionally send users to an
application loaded from http in order that it might access insecure
third-party data at legacy endpoints.

On Tue, Mar 17, 2015 at 10:02 AM Mike West <mkwst@google.com> wrote:

> On Tue, Mar 17, 2015 at 5:42 PM, Daniel Kahn Gillmor <
> dkg@fifthhorseman.net> wrote:
>
>> On Mon 2015-03-16 05:26:39 -0400, Mike West wrote:
>> > 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).
>>
>> If Chrome provides degraded UI for plain http:// sites (i think this has
>> been discussed recently, but don't have a link handy), then the site
>> operators will have only one way to fix this, which is a move to full
>> HTTPS with mixed content at all, right?
>>
>
> Indeed.
> http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> is certainly a potential end game for plaintext, but I don't think we can
> assume that it's going to happen quickly enough to make developers happy
> with a proposal that doesn't deal with the status quo.
>
> -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.)
>