On Mar 18, 2011, at 9:44 PM, Shabsi Walfish wrote:
>
>
> On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich <[email protected]> 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 ( http://crypto.stanford.edu/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.
-R
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
