[whatwg] window.cipher HTML crypto API draft spec

On Fri, 2011-05-20 at 08:04 -0700, David Dahl wrote:
> The draft spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

I think it's great to get browser-side crypto so that services like
DropBox could be implemented with Firefox Sync-style crypto in the
future.

- -

It seems unfortunate that crypto is only available when a JavaScript
program explicitly drives encryption. This means that in order to use
crypto, the Web app has to be written in such a way that all its
resource handling is programmed in JavaScript instead of using
traditional browser-handled resource retrievals.

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

- -

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.

OTOH, wiping keys along with cookies could lead to accidents.

Is there a plan on how this will integrate into various private data
deletion UIs in such a way that users have the option to delete keys but
understand the implications and don't delete them accidentally?

Are all the methods that take a success callback meant to pop up a
geolocation-style asynchronous authorization UI until the user
perma-authorizes a site to use crypto?

- -

Is the plan to use Firefox Sync to sync the user's private keys across
multiple browser instances so that the user doesn't need to manually
transfer keys in the usual case?

- -

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

- -

It seems unfortunate that the proposed API entry point is yet another
special name in the global scope. It seems to me that it would be better
to put the new stuff on the existing window.crypto object or, if mixing
with the old object is considered confusing, it would make sense to put
the new stuff on the navigator object as navigator.crypto or
navigator.cipher in order to avoid polluting the global scope.

- -

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 public key discovery section is generally confusing. Is <meta
name="addressbook-entry"> meant to represent an email addressbook entry
that may happen to have a public key associated with it? Or is "cipher
addressbook" crypto lingo that I'm unfamiliar with and <meta
name="addressbook-entry"> always represents a public key plus metadata?
Without understanding the general design, it's hard to comment on the
choice of minting special name="addressbook-entry"-specific attributes.

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

Received on Tuesday, 24 May 2011 00:25:53 UTC