[webkit-dev] SessionStorage being serialized to disk
Jeremy Orlow
jorlow at chromium.org
Tue May 12 16:41:05 PDT 2009
True, but it's definitely harder to force data into the page file, gain
access to it, and to know where to look for the data. (Your point does make
my comment about securing the SessionStorage memory seem a bit silly,
though.)
On Tue, May 12, 2009 at 4:25 PM, Adam Barth <abarth at webkit.org> wrote:
> I don't see a security problem with writing sessionStorage to disk.
> Site already aren't guaranteed that their memory won't be paged out to
> disk.
>
> Adam
>
>
> On Tue, May 12, 2009 at 3:50 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> > Is anyone here dead set against window.sessionStorage ever being written
> out
> > to disk (in an unencrypted form)?
> > Session storage needs to be stored for the life of the Page class since
> the
> > user can always navigate back to a site or hit the back button. This
> means
> > that a very long lived tab could start wasting a lot of memory in a world
> > where session storage is commonly used.
> > The only reason I've heard against writing session storage to disk is
> > security. For example, a web site storing some security token client
> side.
> > Unfortunately, you never know when your memory is going to get paged to
> > disk, so if we're serious about keeping session storage secure, we'd need
> to
> > address that--at least for sites using HTTPS.
> > The spec itself doesn't explicitly say either way. It does suggest that
> the
> > lifetime of a browsing context (and thus session storage) is not
> necessarily
> > connected to the lifetime of a browsing process. Since some crash
> recovery
> > implementations work by serializing the browsers state to disk, the spec
> > seems to be suggesting that it _can_ be written to disk, but I'm not
> aware
> > of any browsers actually doing this yet.
> > If we did feel strongly about making security guarantees for session
> > storage, we should probably suggest on WhatWG that it be guaranteed by
> the
> > spec.
> > J
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090512/9bd1515d/attachment.html>
More information about the webkit-dev
mailing list