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

On Tue, Mar 17, 2015 at 9:05 PM, Brad Hill <hillbrad@gmail.com> wrote:

> Proxying  content on the back end is one way around this for some use
> cases, but not a universal solution.
>
> On Tue, Mar 17, 2015 at 12:39 PM Daniel Kahn Gillmor <
> dkg@fifthhorseman.net> wrote:
>
>> On Tue 2015-03-17 13:10:50 -0400, Brad Hill wrote:
>> > 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.
>>
>> But it *is* about user agents.  If a site needs to access data itself
>> (without a user agent involved) it can do so with whatever policy it
>> wants.
>>
>
I think the more central point here is less about proxies, and more about
the intuition that not all sites that wish to use
`upgrade-insecure-requests` will also want to use HSTS, nor does use of
`upgrade-insecure-requests` on one page mean that it should be applied
unilaterally to all of a hosts' pages.

Giving developers the ability to poke at things on a per-resource basis is,
I think, valuable.

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