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

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