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

On Fri, Aug 22, 2014 at 3:28 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> On Fri, Aug 22, 2014 at 3:12 PM, Ángel González <angel@16bits.net> wrote:
>
>> Jeffrey Yasskin wrote:
>> > 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 simplest hole is probably a url with a hash which must match the
>> content. Eg. like
>> http://en.wikipedia.org/wiki/Magnet_URI_scheme?oldid=622277458#cite_ref-4
>>
>> I think I have also seen urls that used hashes appended after the # for
>> verification, but can't find them now.
>>
>
> So, roughly, allow requests under
> https://w3c.github.io/webappsec/specs/subresourceintegrity/, in whatever
> form that winds up, even if the origin is mixed.
>

​I'd assumed this would not fly because it does not address privacy.​

However, if that mechanism did allow mixed content (Goal 5), then this
would go a long way to addressing the video distribution use-case. There
are some details related to streaming that would need to be worked out and
calculating and managing the hashes across a large content library is no
small task, but here you are in the territory of one-off engineering
effort, which is much easier to justify.


>
> I'm not the person who'd need to be convinced that this approach is
> acceptable, but it seems like a reasonable way to get most of the user
> benefits of the secure origin proposal without forcing Netflix to spend
> lots of money in a hurry to replace their serving hardware.
>

>
>> > 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?
>>
>> That looks initially good as it would also provide confidentiality.
>> However, I'm afraid that you would end up having to spec a VM for how to
>> decrypt the message. IMHO the hole should only require integrity (hashes
>> or private key signatures). Decryption should be performed by WebCrypto
>> on top of that. But you will find that there will be cases where it's
>> not desired (eg. the download of a .deb or a Linux CD) and others where
>> it's not enough (the tracking could be perfomed on the encrypted file).
>> If you need to reencrypt for every user, you don't help the CDN use case
>> where they precisely want static files. The only benefit is that you
>> could encrypt offline the same content several times, and then serve
>> each user a different token (and file) to decrypt them.
>>
>
> Fair 'nuf.
>