[whatwg] Proposal for secure key-value data stores

On Thu, Apr 8, 2010 at 1:09 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Apr 7, 2010 at 4:54 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> > On Thu, Apr 8, 2010 at 12:48 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> On Wed, Apr 7, 2010 at 4:29 PM, Jeremy Orlow <jorlow at chromium.org>
> wrote:
> >> >> > 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 disagree. Having data time out is a good "additional layer" of
> >> security. For example if your laptop gets stolen, then it's much
> >> better if the thief only gets access to the sites you've used the last
> >> 24h, than any site you've ever used.
> >>
> >> This is why people do things like enforce password changes every X
> >> weeks. Yes, password changing has social downsides, like people
> >> writing down passwords on post-its etc. However those problems do not
> >> seem to apply here.
> >>
> >> So I don't think anyone is arguing that expiration is good security in
> >> and of itself. But it is a good (and low cost) way of getting
> >> additional security.
> >
> > Sure, but it should not be thought of as anything more than a hint.  If I
> go
> > to a site that says expire the data in 24 hours and then I turn it off
> and
> > don't use it for a year, that data is still there.
>
> This is true, and important.
>
> > Anything that has the outward appearance of adding more security than it
> > actually does worries me.  (I'm obviously worried a lot. :-)
>
> I think it's pretty obvious though that expiring the data X seconds in
> the future doesn't in and of itself give any protection what so ever
> until the data has actually been expired.
>
> I guess it could be argued that it isn't obvious that the data is only
> expired if the browser is running.


It's possible UAs can be a bit more smart about this as well.  For example,
many OSs have a way to schedule things to run in the future.  (And could
have a helper program that does the deleting.)


> I don't think this is enough of a
> problem to kill the feature though.
>

I think this is a good feature to try and integrate into existing APIs if
it's possible to do so cleanly.  I don't think it's worth creating yet
another persistent storage API over, though.

It seems as though expiration policies could be added to the creation of
databases and the new FileWriter/FileSystem APIs pretty easily.  For
localStorage, we could add a origin-wide setting or add an optional param to
setItem.

But still....we need some use cases.  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100408/cdebc146/attachment.htm>

Received on Wednesday, 7 April 2010 17:44:06 UTC