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

On Thu, Aug 21, 2014 at 5:21 PM, Jeffrey Yasskin <>

> On Wed, Aug 20, 2014 at 9:43 AM, Mark Watson <> 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,

​Yes, and I think we would like it to be.​

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


> 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? :)

​IIUC, you're saying that there would be a mode where an HTTPS page can
XmlHttpRequest an HTTP resource​. If this was universally supported without
user permission dialogs / warning bars etc, then I believe that would be
fine for us. But what I've been given to understand by others is that
browsers are very much moving in the direction of always blocking all kinds
of mixed content.


> Jeffrey

Received on Friday, 22 August 2014 00:33:14 UTC