On Wed, Apr 7, 2010 at 10:26 PM, Dirk Pranke <dpra...@chromium.org> wrote:
> On Wed, Apr 7, 2010 at 2:14 PM, Nicholas Zakas <nza...@yahoo-inc.com> > wrote: > > I’ve actually already seen a very common repeated pattern as it comes to > > client-side data storage: > > > > 1. “Hey let’s try using localStorage to improve our user experience.” > > > > 2. “Sounds great, but the data can’t be stored in plain text if its user > > data.” > > > > 3. “That’s okay, we’ll just use the XYZ JavaScript encryption library.” > > > > 4. “And then use it on every read and every write?” > > > > 5. “Ugh, you’re right, nevermind.” > > > > Presumably the "ugh" is a reaction to the perceived slowness of doing > the crypto in JS? Has anyone > benchmarked JS crypto performance compared to what the imagined C/C++ > perf would be? > Or are there any actual examples of where someone was going to use JS crypto but abandoned it because it was too slow? If the issue is that it's "too hard" but yet no one's bothered to make a library to make things easier, then honestly I find it hard to believe this is a super important issue to more than a handful of web developers. > > > > I’ve had, or participated in, this conversation multiple times. I also > know, > > from speaking with others about this proposal, that this conversation > isn’t > > uncommon. > > > > > > > > Again I’ll say I’m all for adding crypto into JavaScript. I think in > > addition to that, there should be affordances for what will likely be > common > > usage patterns. To me, any and all mechanisms for client-side storage > should > > have some basic crypto built-in, so why not start here? > > > > > > > > In regards to data expiration, part of ensuring the security of data is > > knowing how long it will be stored on disk. If I let someone borrow my > > computer to check their email, and the email client happens to save some > > data onto the client, then that person’s data will now be on my disk for > who > > knows how long. That represents a data security issue. By allowing an > > expiration date to be tied to the data, you can have reasonable assurance > > that the data isn’t just going to be sitting around waiting for someone > to > > try and use it. > > > > It is true that not having control over your data could be an issue, but > simply > embedding expiry into the data may not buy you much to protect it. Insofar > as the crypto wouldn't be running in a TPM, it would be easy to reverse > engineer > it and extract the data; it would also be fairly easy to reset the > clock on the device > to keep data from being deleted. > One thing that might be interesting is a way to cache large amounts of data that are deleted when the browser and/or tab closes. This might be something for the new file system API to consider (hence adding ericu to the thread). But time based controls aren't going to do anything more than give perceived security. (In your use case, expiration doesn't add much actual security for the reasons Dirk mentioned.) > I continue to think that the requirements for a secure storage API > that fit a wide > range of use cases are not particularly clear (and it would be easy to see > this > balloon into a wide API designed for lots of different corner cases). > I think the ideal > approach for this would be to build a JS-based implementation on top > of the existing > libraries and, if such a library sees wide adoption, push for it to be > implemented natively. > > If there are fundamental missing primitives, then by all means we > should look at adding > them, but I'm not sure that we are missing anything. > Yes. We generally only add surface area to APIs (let alone APIs themselves) for use cases that are either not possible or performance problems. Doing crypto in JS certainly seems as though it could be the latter. Expiration is the former. But for both, we need clear use cases that are not possible/practical today. Despite me asking several times, you haven't given any clear use cases. If you search the list archives, you'll find that whenever we talk about new APIs, they're very rooted in specific use cases. > > -- Dirk > > > > > > > -Nicholas > > > > > > > > ______________________________________________ > > > > Commander Lock: "Damnit Morpheus, not everyone believes what you > believe!" > > > > Morpheus: "My beliefs do not require them to." > > > > ________________________________ > > > > From: whatwg-boun...@lists.whatwg.org > > [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow > > Sent: Tuesday, April 06, 2010 6:55 AM > > To: Nicholas Zakas > > Cc: whatwg@lists.whatwg.org; Dirk Pranke > > > > Subject: Re: [whatwg] Proposal for secure key-value data stores > > > > > > > > Sorry for misunderstanding your original suggestion. > > > > On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas <nza...@yahoo-inc.com> > > wrote: > > > > I certainly can't argue against a focus on JS crypto. :) What I'd like to > do > > is eliminate what I believe will be a repeated pattern for developers in > the > > future. It would be really nice if, in addition to having access to > crypto > > functions, there was an area where I could stick data that would get > > encrypted automatically (and of course, where I could be sure the data > would > > be eliminated after a set amount of time). > > > > > > > > It seems to me that Dirk is right that crypto in the browser is a more > > general problem and that a general crypto API would be much more valuable > > than creating new APIs with similar/duplicate functionality + crypto. > > Optimizing for "repeated patterns" probably should wait until we see > what > > patterns are actually common. :-) > > > > > > > > My proposal is less about encryption and more about providing better > control > > over how data is stored and for how long. > > > > > > > > Can you provide some concrete use cases for expiration of content? > They'd > > probably have to be pretty dramatic to warrant creating yet another > storage > > mechanism. > > > > > > > > Maybe this can somehow be integrated into IndexedDB? There's very little > > chance of it being a v1 feature, but maybe we could make sure it's > possible > > to add in future versions. > > > > > > > > -Nicholas > > > > ______________________________________________ > > Commander Lock: "Damnit Morpheus, not everyone believes what you > believe!" > > Morpheus: "My beliefs do not require them to." > > > > -----Original Message----- > > > > From: whatwg-boun...@lists.whatwg.org > > [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke > > Sent: Tuesday, March 30, 2010 3:09 PM > > To: Nicholas Zakas > > Cc: whatwg@lists.whatwg.org; Jeremy Orlow > > Subject: Re: [whatwg] Proposal for secure key-value data stores > > > > On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas <nza...@yahoo-inc.com> > > wrote: > >> Yes, that's precisely what I'm talking about. It seems to me that this > >> will end up being a pretty common pattern (encrypting/decrypting data > stored > >> locally). > >> > >> The idea behind letting the key to be defined by the developer is to > allow > >> any usage that developers deem appropriate for the situation. For > example, > >> one might want to only use a server-generated key to access the data, in > >> which case this data won't be available offline but will be used to > >> supplement the online behavior. Another might determine the key based on > >> some information in a cookie, which is less secure but does allow > offline > >> access while also ensuring that if the cookie changes or is deleted, the > >> data remains secure. > >> > >> The idea behind the expiration date is to allow developers to be sure > the > >> data won't stay around on disk indefinitely. Think about the Internet > café > >> use case where people are repeatedly logging in and out - we don't want > >> everyone's data living on that computer for however many years it's in > use. > >> > >> One way or another, I think JavaScript crypto is going to be important > in > >> the next few years. > > > > Perhaps we should instead focus on a set of JS Crypto APIs, since that > > is largely orthogonal to the storage APIs? > > > > -- Dirk > > > > >
