Re: Use Cases | ACTION-13 Revisited


On Aug 16, 2012, at 7:16 PM, Ryan Sleevi wrote:

> On Thu, Aug 16, 2012 at 3:55 PM, Arun Ranganathan <> wrote:
>> While working through the use cases (per [ACTION-13]) with Wan-Teh (wtc), we
>> came up with the following:


>> 1. The use cases rsleevi added to the draft [spec] are pretty solid;  they
>> are only missing a "local storage" scenario, first mentioned on the Wiki
>> [cf. local].
>> [cf. local]

> I'm a little concerned about the "local storage" case, and wondering
> whether it's something that would necessarily be in scope for this
> group.

> Consider the example of IndexedDB, which uses "Keys" (IDB keys -
> ) and returns "Values" (
> ), and can
> alternatively be accessed via indices (
> ).

> A naieve assumption would be that this API would only protect the
> Values - not the keys, nor the indices. However, as practically
> deployed today, that wouldn't offer much protection, since both Keys
> and Indices often reveal quite a bit of information.
> Further, by ciphering contents, it's a tradeoff between efficiency and
> privacy. Perfect privacy (storing no relationships about keys/indices,
> everything randomly distributed) is the worst efficiency, while
> perfect efficiency (which is what is afforded by today's IndexedDB)
> has no privacy/cryptography.
> A refinement might be to have the IndexedDB actually take a Key
> (Crypto API key), that it can use to protect however the IndexedDB is
> stored - keys, indices, everything. Call it an "EncryptedIndexedDB".
> This is better, in that it allows the user agent to decrypt on the fly
> (see caveat), and allows applications to use existing indices/keys.
> The caveat, however, is that encryption requires defining an
> encryption algorithm, and the choice of encryption algorithm directly
> affects the efficiency of the API. For example, under today's
> IndexedDB, a user agent can load data on the fly (eg: from disk), but
> under EncryptedIndexedDB with say, a block cipher alg like AES, it
> might have to read the entire DB into memory, then decrypt, in order
> to be able to offer this functionality.
> Even more fundamentally though, is the question about what attack this
> is trying to defend against. The arguments I've heard for encrypted
> local storage seem to be about a remote server, serving a web
> application, distrusting the client platform. If that's the case, it
> doesn't seem like any level of cryptography will save them. As I noted
> in the existing security considerations, it SHOULD be perfectly valid
> for a user agent to store a key in plaintext on disk, so what actual
> protections are afforded by this?

You're right -- if the use case is primarily about an untrusted multi-user machine or virtual computing environment, we're only as safe as general user safety anyway.  This doesn't seem to be a use case we can salvage, nor one that should influence the API.  We should probably not include it.


> If something like EncryptedIndexedDB is what is meant here, then this
> seems like something that would likely live in the Web Apps WG (since
> it's about extending IndexedDB).

Maybe -- I doubt it's worth their while to solve for that use case either :).  Interestingly enough (and not to confuse matters, but) we've just heard from Facebook [FB-ScriptSigning] about localStorage (or IndexedDB) used as a script cache.  People are already using IndexedDB and localStorage in unsafe-ish ways.  Of course, we shouldn't confuse script signing with a general use case for protected/encrypted local storage, but perhaps if we jettison the "protected local storage" use case, we can bolster the "document signing" use case to explicitly refer to documents extracted from local storage for signature verification.

This raises the sticky issue of types of documents.  We might naively say that a script is no ordinary document, and can be used by the relevant JSON primitive if it passes signature validity.  

In a nutshell, I'm saying: perhaps we cannot cater to an encrypted local store use case, but we may be able to flesh out the use case for signature verification, including extraction from local storage.  Our use cases should encourage patterns of behavior that we think are desirable.  We can't control or solve for undesirable patterns of behavior :)

> I just want to make sure that we're carefully considering the use case
> and the security implications before committing to them, as well as to
> figure out what parts of the spec may need to change in order to
> meaningfully implement them.


-- A*


Received on Friday, 17 August 2012 15:48:33 UTC