Native JS Encryption

Robert Accettura robert at
Fri Mar 18 19:07:10 PDT 2011

On Mar 18, 2011, at 9:44 PM, Shabsi Walfish wrote:

> On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich <brendan at> wrote:
> On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote:
>> I'm not convinced that this use case, or any other use case I could think of for the web (with the possible exception of DRM/encryption on streaming media), would really benefit from speed. On the whole, you would most likely be encrypting fairly small quantities of data, and any larger quantities of data would typically be handled in a context where the encryption/decryption can even be done asynchronously. Even on a mobile phone, a few blocks of AES could probably done in pure JS without noticeable delay. Have you done any experiments with SJCL ( ) for example?
> In support of Robert's point, we have Firefox Sync [1], which client-side encrypts many blocks of user data (not just passwords; cookies, history, etc.) to hide it from our own (or an alternative; the server is open source) sync service.
> This needs native speed, which we provide via privileged-JS-only (our so-called "chrome" user-interface JS) access to our native crypto module (NSS). The volume in blocks and bytes requires it. Using pure-JS crypto lowers performance an order of magnitude or two.
> I'm not convinced that you need native speed even for this (and its a bit specialized, since it lives in the browser chrome). It sounds like you are talking about a few MB of data, at most. Native code could probably do that in something like 10 or 20 ms, and even if you are slower by an order of magnitude you can do it in 200 ms in JavaScript (and the performance gap appears to be steadily decreasing at that). Either way, the sync time is probably dominated by network performance. I expect that approximately the same would hold true for mobile.

localStorage I believe today is 50 MB, but I think it's safe to say that will climb just like disk cache has been climbing.  Even with SSD's disk space is relatively cheap.  I don't think 99.99997% of users would even notice if that was raised to 100 MB.  I think we could pretty easily fill 50 MB playing with something like <canvas/> and offering the ability to save like a Photoshop or Paint clone.  Want to do something awesome like Gmail offline with your whole mailbox? More will be needed.  That would be the perfect example of where this would be handy on the client side alone.

I think local data is right now at it's infancy.  There are many reasons for an app to store data on the client (performance, offline support, privacy).  Mobile is just further pushing this into the forefront.  Users are concerned about privacy.  Many vendors would love to be able to say they employ encryption without having to sacrifice performance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list