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

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