On Mon, Mar 23, 2009 at 1:02 PM, Darin Fisher <[email protected]> wrote:
> On Mon, Mar 23, 2009 at 12:44 PM, Michael Nordman <[email protected]>wrote: > >> >> >> On Mon, Mar 23, 2009 at 12:03 PM, Darin Fisher <[email protected]>wrote: >> >>> On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow <[email protected]>wrote: >>> >>>> *If you don't care where various bits of the localStorage >>>> implementation live and you aren't scared about letting stuff out of the >>>> sandbox, you can stop reading now.* >>>> >>>> * >>>> * >>>> Background: >>>> >>>> For those who don't know the spec by heart: SessionStorage can be >>>> thought of as 'tab local' storage space for each origin. >>>> >>> >>> SessionStorage can probably be implemented entirely within WebKit. We >>> should be able to share this implementation with Safari (except for the >>> differences in JS bindings of course). >>> >> >> The other difference will be around how the existing sessionStorage is >> cloned when spawning a new top-level browsing context from an existing >> one. Right-click open in new tab/window, should result in a new tab/window >> whose sessionStorage is pre-populated with the contents of the original's. >> > > Interesting. I wonder why this is so different than session cookies. > /shrug > The use of the term session is a little misleading in this API. This repository is really a tab specific collection of transient name/value pairs. I would love to see a "session" specific (in the more conventional use of the word session) non-persistent collection in addition to the per tab bag of bits currently provided. > -Darin > > > > >> >> >>> >>> >>> >>>> LocalStorage is shared across all browser windows of the same origin >>>> and is persistent. All data is stored in key/value pairs where both the >>>> key >>>> and value are strings. It's possible to subscribe to DOM storage events. >>>> Events and ease of use are why a developer might use localStorage even >>>> though the database interface exists. The exact spec is here: >>>> http://dev.w3.org/html5/webstorage/ >>>> >>>> >>>> *Where should the localStorage implementation live? >>>> * >>>> >>>> I'm planning on implementing localStorage very soon within Chromium. >>>> Unfortunately, how to do this is not very clearcut. Here are all the >>>> possibilities I know of so far: (Note that I'm intentionally ignoring the >>>> backing file format for now...as that debate will partially depend on how >>>> it's implemented.) >>>> >>>> 1) The most obvious solution is to have have the browser process keep >>>> track of the key/values for each origin and write it to disk. The problem >>>> with this approach is that we're allowing user supplied data to exist in >>>> memory (possibly the stack at times, though we could probably avoid this if >>>> we tried) outside of a sandbox. Ian Fette (and I'm sure others) have >>>> pretty >>>> big reservations for this reason. That said, this is definitely the >>>> simplest and cleanest solution, so if we can figure out something that >>>> we're >>>> confident with security wise, this is how I'd like to do it. >>>> >>> >>> We do this for cookies, so doing it for localStorage is no big deal. >>> >>> >>> >>>> >>>> >>>> 2) What follows from #1 is simply pulling all the localStorage code >>>> into its own (sandboxed) process. The problem is that, unless a lot of the >>>> internet starts using localStorage, it seems disproportionately heavy >>>> weight. Starting it on demand and killing it off if localStorage hasn't >>>> been used for a while would mitigate. >>>> >>> >>> Why would we need a separate process? It seems like we could just have >>> some IPCs to get/set localStorage values. We could mimic what we do for >>> cookies. I don't see much value in sandboxing the storage component of >>> localStorage. >>> >>> >>> >>>> >>>> >>>> 3) A completely different solution is to use shared memory + the code >>>> recently written to pass file handles between processes. The shared memory >>>> would be used to coordinate between processes and to store key/val data. >>>> One render process for each origin will take responsibility for syncing >>>> data >>>> to disk. Event notifications can occur either via IPC (though sharing >>>> key/val data can NOT for latency/responsiveness reasons) or shared >>>> memory--whichever is easier. Obviously the chief problem with this is >>>> memory usage. I'm sure it'll also be more complex and have a greater >>>> bug/exploit cross section. >>>> >>> >>> I think this is too complex for something that is not used much on the >>> web. We don't do this for cookies, so we shouldn't need to do it for >>> localStorage. >>> >>> >>> >>>> >>>> >>>> 4) A variation of #3 would be to keep all key/val data in the file and >>>> only use shared memory for locking (if necessary). I'm not going to >>>> discuss >>>> the implementation details because I don't want us to get hung up on them, >>>> but the general idea would be for each process to have an open file handle >>>> for their origin(s) and somehow (shared memory, flock, etc) coordinate with >>>> the other processes. This will almost certainly be slower than memory (if >>>> nothing else, due to system calls) but it'll use less memory and possibly >>>> be >>>> easier to make secure. >>>> >>>> 5) One last option is to layer the whole thing on top of the HTML 5 >>>> database layer. Unfortunately, there's no efficient way for this layer to >>>> support events. Even hooking directly into sqlite won't work since its >>>> triggers layer apparently only notifies you (i.e. works) if the >>>> insert/delete/update happens in your own process. Of course sqlite can be >>>> the backing for any other option, but please, let's hold off on that >>>> discussion for now. >>>> >>>> >>>> *So here are my questions:* >>>> >>>> How paranoid should we be about passing a user created string to the >>>> browsing process and having it send the data on to the renderer and some >>>> backend like sqlite? >>>> >>>> Do we trust sqlite enough to use it outside of a sandbox? (Hopefully, >>>> because we're already doing this, right? If not are there other mechanisms >>>> for storing the data on disk that we do trust?) >>>> >>> >>> we use sqlite to store cookies. we run that in the browser process. >>> >>> -darin >>> >>> >>> >>>> >>>> Would we feel more comfortable with #1 if the renderer processes somehow >>>> mangled the keys and values before sending them out? For example, they >>>> could base64 encode them or even do something non-deterministic so that >>>> attackers have no guarantee about what the memory would look like that's >>>> passing through the browser process? >>>> >>>> >>>> And, most importantly, which option seems best to you? (Or is there an >>>> option 6 that I missed?) I'd rank them 1, 2, 4, 3 personally. >>>> >>>> >>>> >>>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
