Native JS Encryption

Erik Corry erik.corry at
Mon Mar 21 01:40:02 PDT 2011

2011/3/19 Brendan Eich <brendan at>:
> 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.

You want to protect the user from a compromise of Mozillas servers,
but the JS code that does the encryption and the browser in which it
is done are both served from those servers.  I'm sure there are use
cases for JS encryption but this doesn't sound like one of them.  You
can use SSL and encrypt on the server.

> 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.
> To your point about the API being "best, most current" crypto-standard (for
> a given key size, perhaps): that is usable but often in our modern era, JS
> clients must chat with JS server peers using precisely *this* or *that*
> crypto protocol. So I imagine we'll need both kinds of APIs: best-latest and
> exactly-this.
> Mark Miller alluded to a crypto API task group without Ecma TC39. I'm open
> to it, provided we can include some of the domain experts who have
> participated on this list (but who may not be employed by Ecma members).
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list