Re: Proposal: Prefer secure origins for powerful new web platform features

On Wed, Aug 20, 2014 at 9:43 AM, Mark Watson <watsonm@netflix.com> wrote:
> Yes, and there could be much simpler ways of authenticating flat files
> downloaded over HTTP. For example having a secure origin vouch for them with
> some form of signature over the resource. I'm not proposing that as a
> solution, not least because it does not address privacy, just pointing out
> that there may be other options that could be looked at.

I wasn't present when this was discussed, so I apologize if I'm
bringing something up that was already shown to be thoroughly idiotic.

It sounds like you (Netflix) have a driver page that could relatively
easily be HTTPS, but you would have a lot of trouble converting your
video streams away from HTTP. Since browsers block mixed content over
XMLHTTPRequest and WebSockets, that prevents you from fixing your
driver page.

https://w3c.github.io/webappsec/specs/mixedcontent/#category-blockable
ratifies this by including those requests in the set that UAs MUST
block as mixed content. However, that spec can change. Would it make
sense to say, roughly, that in a document with a CSP that blocks
unsafe-inline and unsafe-eval, "Data" is only optionally-blockable?

Then you could bootstrap your secure protocol from an HTTPS page,
fetch encrypted movies as data from your insecure origins, and use
WebCrypto/EME from the trusted context to decrypt the movies and feed
them to the video player.

What am I missing? :)

Jeffrey

Received on Friday, 22 August 2014 00:21:55 UTC