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

Reading

https://w3c.github.io/webappsec/specs/mixedcontent

I would like to point out a major concern with whole mixed-content landscape

I would like to introduce a requirement:

	No script which works when served as http: should fail when instead served from https:

Justification:

1) There are important and valuable scripts which run when sourced from http: which one should be able to serve over https: for security.

2) We are trying to get people to move to move in general to HTTPs, and this assurance is going to make that much easier. 

3) We are trying to make the web platform a powerful one competing with native apps, and any way in which HTTPs apps are hobbled defeats that.

4) The development of the web is supposed to be back-compatible so that old web sires work in new borwsers

This means that no access to insecure content should be blocked just because the original script was served over HTTP.

When a script is served over HTTPs, it should be trusted, if anything, more than one served over HTTP.   Anything which works for the HTTP case should therefore work for the HTTPs case.

The current mixedcontent  document, and current browsers, block access to HTTP: resources  by anything served over HTTPS.

This means that  there is  large class of applications which have to be written as HTTP: apps or native apps.
This needs to fixed.

Of course, while the access should not be blocked, the level of trust in the site as represented in the UI could reflect that the page has not retrieved all its data by HTTPS.

This is related to Issue 12 on web-https  https://github.com/w3ctag/web-https/issues/12
See some discussion around that.

A case inpoint is the access to open HTTP CORS-enabled resources.  When an HTTP-origin script access data from a different origin, that is enabled if the CORS headers are set appropriately.  However if an HTTPs script does the same it is blocked.

There are arguments that the data should be blocked because it may be private information, but that is what the CORS headers are for.

There are arguments that the data access should be blocked because the user's access itself may be a sensitive thing. However, insisting on HTTPs for the data access here doesn't actually help completely, as those spying on the connection will see an HTTPS connection to a specific domain, so the HTTPS case is not a whole lot better, especially now that the origin-based regime now  promoted the use of smaller domains for the same of cutting down inter-domain leakage.  So an https data access it to for example timbl.github.com not github.com.  The origin-based secuirity system is actually making HTTPS accesses more revealing than before.


Tim BL
timbl@mit.edu


Director hat OFF