[SRI] Escaping mixed-content blocking for video distribution

All,

I expect most people are familiar with the debate as to whether Encrypted
Media Extensions should require a secure origin and also the fact that that
debate might become moot if it were possible to deliver video content over
HTTP on an HTTPS site (including video fetched using XHR and played using
the Media Source Extensions).

I understand that HTTP is no longer considered eligible for SRI, for good
reasons [1]. Also that the ability of SRI / HTTP resources to escape
mixed-content blocking is not something which had been agreed.

Nevertheless, whilst the debate over EME / HTTP continues, I wonder if it
is worth thinking about whether there may still be an SRI-based solution ?

First, it's worth noting that EME/HTTP, assuming some strong normative
requirements with respect to EME identifiers and security, is still likely
a worse solution from a security / privacy perspective than EME / HTTPS +
SRI / HTTP.

Second, requiring HTTPS doesn't really solve the Verizon identifier attack,
or similar: such an identifier could still be associated with the TLS
connection, for example in a TCP option, some extension to the initial TLS
exchange or even a totally independent message sent to the destination
identifying the TLS connection by its IP 5-tuple.

But, anyway, is there anything that could be done in terms of request
integrity with HTTP ? Thinking aloud, could the response be required to
include an HMAC of the request, using a key provided to the UA by the site
? That does not prevent destination server and network colluding, but does
prevent modification of requests sent to non-colluding sites.

I would expect that response headers be not visible to JS on the XHR, to
avoid the attacks where networks attach unique identifiers to responses.

Another line of thought would be whether TLS could be used for HTTP sites ?
This would give them access to some of the capabilities previously reserved
for HTTPS sites but without any representation to the user regarding
security / privacy and so more relaxed SRI-based mixed-content exceptions ?
Again, this would be an improvement over EME / HTTP.

...Mark

[1] http://www.wired.com/2014/10/verizons-perma-cookie/