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

On Thu, Aug 21, 2014 at 5:32 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
>
> On Thu, Aug 21, 2014 at 5:21 PM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>>
>> 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,
>
>
> 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.
>
>
> Exactly.
>
>>
>>
>> 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? :)
>
>
> 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.
>
> ...Mark

That's what I'm suggesting. I'm not sure whether "block ALL mixed
content" or "block insecure access to user data" is the stronger push,
but it seems like there's at least a chance that folks will be willing
to keep a regulated hole in the mixed-content wall, especially if it
makes it easier to adopt Chrome's secure-origins manifesto.

I don't really know what the regulated hole should look like. What
would you be happy with?

The argument at
https://groups.google.com/a/chromium.org/d/topic/security-dev/Uxzvrqb6IeU/discussion
makes me think there may be more objection to just opening
XHR/WebSockets than I'd thought, even given a CSP that blocks the
obvious hole of executing script from them. What if, instead,
WebCrypto provided a direct way to open a WebSocket where each message
is passed through decrypt() before being given to the user?

Jeffrey

Received on Friday, 22 August 2014 01:07:10 UTC