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

Tim,

Thanks for chiming in.  If I may endeavor to clarify a couple of things:


> I would like to introduce a requirement:
>
> *No script which works when served as http: should fail when instead
> served from https:*
>
>
There is a distinction here that the phrasing of this requirement misses -
between the behavior of a secure document context and the location from
which a script is served.

In the strict sense, this requirement as phrased above is already correct
and would not be changed by the proposed Mixed Content draft.  e.g. If I
load the insecure resource:

http://example.com/foo.html

and it contains the following markup:

<script src=http://example.com/scripts/doStuff.js>

that link can ALWAYS be changed to:

<script src=https://example.com/scripts/doStuff.js>

and nothing will break.

Also, if I load the secure resource:

https://example.com/foo.html

and it contains the following markup:

<script src=http://example.com/scripts/doStuff.js>

That script today will ALWAYS be blocked from loading by modern browsers,
for some years now.

So any script which today can be served over http and be allowed to execute
can be upgraded to https and continue to work.

The rest of your message seems to indicate you're not actually or
exclusively concerned with where/how a script is served, but with whether
secure document contexts can load insecure content.

There are many legitimate reasons to be concerned about introducing
insecure content into a page that has made some assertions to a user about
its security, as Michal has already pointed out in his reply.

If I might suggest a pivot here along the lines of the compatibility and
path forward you (and we all) desire, perhaps we ought to discuss the
possibility of automatic / optimistic upgrade from HTTP -> HTTPS for
requests issued from a secure document context.  So if you load a script
over https from a secure context, just auto-fixup all links to https.

We have always shied away from doing this in the past because there is no
formal guarantee that the resource at an URL with the http scheme is
semantically equivalent to one available at the "same" URL with the https
scheme.

Perhaps that shyness is worth revisiting today in light of the broad push
to move as much as possible to secure transports.  If resource authors
simply started serving the same content over https as they do today over
http, we could make vast improvements and avoid much of the pain
mixed-content blocking creates for such transitions today.

The edge cases introduced by this kind of optimistic upgrade may very well
be fewer and less harmful than those introduced by allowing insecure
content into secure contexts.  In fact, the EFF probably already has a good
amount of data on exactly this from the HTTPS Everywhere extension.

What do you think?

-Brad Hill
(chair, webappsec)