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 hsivo...@iki.fi http://hsivonen.iki.fi/