On Mon, Mar 23, 2009 at 12:44 PM, Michael Nordman <micha...@google.com>wrote:
> > > On Mon, Mar 23, 2009 at 12:03 PM, Darin Fisher <da...@chromium.org> wrote: > >> On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow <jor...@chromium.org>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 -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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
