Re: Protection of decrypted data from malicious servers?

On Tue, Mar 25, 2014 at 1:57 PM, James Marshall <james@jmarshall.com> wrote:

> New here... glad to see work happening on this.  I've wanted client-side
> encryption for a while.
>
> In the current draft, is there any protection against a compromised or
> malicious server learning decrypted content, e.g. by having JS that
> decrypts data and then sends that back to the server?  Ideally, client-side
> encryption can protect data from a malicious server.  For example, I'd like
> to see a webmail site with full end-to-end encryption, without making us
> trust the server at all.  CSP helps, but is not a full solution.
>

No. This is impossible. This is not a valid threat, and not something in
scope for this WG.

You're running executable code you just downloaded from an arbitrary
server. If you don't trust that server, no amount of machine learning magic
is going to help you determine whether this code is safe or not.

If you don't want to trust a server to deliver your code, you can use an
extension/webapp/whatever your UA vendor of choice calls their particular
version of SysApps ( http://www.w3.org/2012/sysapps/ ). These apps are
delivered out of bands, using a form of code-signing, and don't require
trust in any particular server. They do require trust in the entity
delivering the code, though. Which has been well understood for a Very Long
Time ( http://cm.bell-labs.com/who/ken/trust.html )

It is quickly turtles all the way down. Can the browser protect against the
OS? Can the OS protect against the hardware? It's a layering issue, and
fundamentally, you must trust the server.


>
> If this hasn't been addressed, I think of two possible solutions, neither
> one very good:
>
> 1) Use a kind of "taint", where decrypted data and all data derived from
> it is prevented from being sent back to a server.
>

> 2) Use HTML to define an element to display decrypted data, without
> allowing JS to access the content of that element.  Something like
>
>     <div id="mysecret" type="encrypted" algorithm="..." ...></div>
>
> ... and something similar for an input field that is to be encrypted
> before JS can access its data.
>
> Am I missing something, and has this been addressed?
>
> Thanks,
> James
>
>
This fundamentally does not work with the Web Security Model, and we are
not attempting to redefine the Web Security Model.

There are plenty of secure, robust ways to created this "Don't trust the
server" solution - using Apps/Extensions - but fundamentally, executing
code you're downloading from a server requires an element of trust in its
non-maliciousness.