Re: [MIX] Require HTTPS scripts to be able to anything HTTP scripts can do.

The nice thing about being on extended vacation is that smart people say
all the things I would have wanted to say, both more eloquently and clearly
than I would have said them. I agree with Brad's characterization of the
problem space, and I agree with Chris' arguments in favor of the behavior
which the mixed content spec mandates (and which browsers, with the notable
exception of Safari, have generally already implemented). I'll also note
Eric Mill's comment on a related GitHub issue, which is highly relevant to
this conversation:
https://github.com/w3ctag/web-https/issues/12#issuecomment-68627767.

That said, I do think it's worthwhile to add explicit (non-normative)
consideration of this concern to the spec, and to point developers to
mitigation strategies. I'll put something together this week.

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

On Tue, Jan 6, 2015 at 12:25 AM, Brad Hill <hillbrad@gmail.com> wrote:

> If I may attempt to clarify the scope of the solution space a bit:
>
> Our primary motivating goal is to make the applications used on the Web
> Platform more secure.  After all, if we didn't care about actually making
> them more secure, we wouldn't bother to move to HTTPS, we'd be happy to
> just stick with HTTP.
>
> As part of that goal, TBL has identified an area in which HTTPS apps are
> disadvantaged relative to HTTP apps: they cannot interact with open data
> sets not offered over secure transports.
>
> We would all like to eliminate this disadvantage.  However we must keep
> our primary goal in mind.  What many people are trying to explain here is
> that simply eliminating the restrictions on mixed-content scripting and
> data fatally undermines that goal, for many reasons, some quite subtle.
>
> If we cannot provide the meaningful security guarantees of HTTPS, I guess
> I would like to ask why it is harmful for apps using such data to remain
> HTTP themselves?
>
> The only thing I can think of is that we are starting to make "Powerful
> Features" of the Web Platform only available to secure applications.   And
> this is a deliberate choice to encourage HTTPS adoption.  We do not want to
> break legacy applications, but we want to set the expectation that if you
> are doing maintenance on your application to add support for new platform
> features, the first feature you need to add is a secure transport.
>
> Perhaps the 3rd party open data example demonstrates that this is not a
> reasonable incentive, because the actors who wish to create new
> applications with powerful features are not empowered, regardless of their
> incentives, to make the data they rely on available over secure channels.
>
> I think it is reasonable to revisit that discussion.  (
> http://www.w3.org/TR/powerful-features/)
>
> I think it is also reasonable to look at other changes that can ease the
> burden on operators and data providers to offering their information over
> secure channels.   Automatic protocol upgrades from http -> https have
> promise here.  It is not a cost-free strategy; it may break some things,
> but we might decide that the things it would un-break are more valuable
> than the things it would break. (or that the people who would be broken by
> the change are in a better position to un-break themselves than those
> currently broken by the status-quo)
>
> But I really don't think it is reasonable to insist that we undermine
> HTTPS security in order to get more people to use HTTPS "for security".
> That is not just chasing our tail - it is catching it and giving it a good,
> hard bite.
>
> -Brad Hill
>
>
>
>
> On Mon Jan 05 2015 at 3:06:05 PM Brad Hill <hillbrad@gmail.com> wrote:
>
>>
>>>> FWIW, if all the resources retrieved over HTTP were protected with
>>> sub-resource-integrity, then I think you have lost only some
>>> confidentiality and you still have ​integrity and authenticity.
>>>
>>>>
>>>>
>> Unfortunately, it is worth very little.  The motivating use case here is
>> the the ability to pull in arbitrary open data for use in mashups, so the
>> application cannot reasonably know in advance a secure digest value of the
>> content and any plausibly secure way to provide this metadata assumes much
>> more competence and effort on the part of the data providers than merely
>> offering the same resources over https.
>>
>