[whatwg] window.cipher HTML crypto API draft spec

[Henri Sivonen]

On Tue, 2011-05-24 at 07:48 -0700, David Dahl wrote:
> > Consider for example a DropBox-style service that has a browser-based UI
>   but that has a design where content is encrypted on the client-side so
>   that the service provider is unable to decrypt the data. In this case,
>   it would make sense to be able to implement a file download by having a
>   plain <a href> to an excrypted file and have the browser automatically
>   decrypt it. Likewise, a service that allows the transmission of
>   encrypted images should be implementable by having <img src> point
>   directly to an encrypted file.
> 
> I think someone was asking about that kind of functionality during my presentation at Mozilla. Again, this would be a pretty advanced complement to this API - I would love to see something like that spec'd and implemented as well.

My main worry is that if the two ways of doing crypto don't appear at
the same time for Web authors to use, the Web will shift in an
unfortunately hashbangy direction.

> > I suggest adding a Content-Encoding type that tells the HTTP stack that
>   the payload of a HTTP response is encrypted and needs to be decrypted
>   using a key previously initialized using the JS API.
> 
> cool. I'll look into that.

Thanks.

> > On the other hand, it seems that letting Web apps generate per-user key
>   pairs and letting Web apps discover if the user possesses the private
>   key that decrypts a particular message is a privacy problem. Someone who
>   wishes to surveil Web users could use private keys as supercookies,
>   since the generated private key is most probably going to be unique to
>   user.
> 
> Currently, my implementation requires the enduser to open a file from the file system in order to view the contents of the private key. It is only accessible to privileged code - content has no access to it whatsoever.

I didn't expect content to have access to the key bits per se. I
expected Web content-provided JS to be able to encrypt and decrypt stuff
with a key it has asked the browser to generate (if the user has
authorized the origin to use the crypto API). The ability to decrypt or
encrypt a message with a particular private key is proof of possession
of that key, so users in possession of a particular key could be
tracked.

This could be mitigated by granting the crypto permissions to a pair of
origins: the origin of the top level frame combined with the origin that
wants to access the API. This way iframed Web bugs could track the user
across sites after having once obtained a crypto permission for their
origin.

See http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf

> > Currently, it is unfortunate that choosing to use a webmail client
>   effectively prevents a person from using encrypted email. To allow
>   people to use end-to-end encrypted email with webmail apps, it would be
>   useful to support OpenPGP as an encryption format. (Obviously, a
>   malicious webmail app could capture the decrypted messages on the
>   browser and send them back to the server, but when the webmail app
>   itself doesn't contain code like that, putting the decryption in the
>   browser rather than putting it on the server would still probably be
>   more subpoena-resistant and resistant against casual snooping by bored
>   administrators.)
> 
> I think with an API like this we might see a whole new breed of communications applications that can supplant email and webmail entirely. 

Maybe. But Google Wave flopped and email is still here. I think it would
be good to design for the ability to plug into email's network effects
instead of counting on a new breed of communication making email
irrelevant.

> > The public key discovery section shows a </meta> end tag. I hope this is
>  just a plain error and having content in a meta element isn't part of
>  any design.
> 
> The tag is unimportant as well - can you explain why you hope this wil not use a meta tag?

A meta tag can be used if there's no need for the meta element to have
child nodes. You can't make a meta element have child nodes or an end
tag.

>  I could just as easily use <addressbookentry>

You can't introduce an addressbookentry element as a child of the head
element. The result would not degrade gracefully.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/