[whatwg] Private browsing vs. Storage and Databases
beidson at apple.com
Tue Apr 7 17:52:27 PDT 2009
That's interesting. I'm not exactly clear what an "incognito" session
starts out with. Does it start without any cookies, for example?
On Apr 7, 2009, at 5:39 PM, Ian Fette (イアンフェッティ) wrote:
> In Chrome/Chromium, "incognito" mode is basically a new profile that
> is in memory (plus or minus... the cache will never get written out
> to disk, although of course the memory pages could get swapped out
> and hit the disk that way...). The implication is that, for many of
> these features, things could just naturally get handled. That is,
> whilst the session is active, pages can still use a database / local
> storage / ... / and at the end of the session, when that profile is
> deleted, things will go away. I personally like that approach, as
> there may be legitimate reasons to want to use a database even for
> just a single session. (Perhaps someone wants to edit a spreadsheet
> and the spreadsheet app wants to use a database on the client as a
> backing store for fast edits, I don't know...). I just don't like
> the idea of saying "Sorry, incognito/private/... means a class of
> pages won't work" if there's no reason it has to be that way.
> In short, I would prefer something closest to Option 3. It lets
> pages just work, but respects the privacy wishes of the user.
> (AppCache / persistent workers are the one exception where I think
> Option3 doesn't apply and we need to figure something out.)
> On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson <beidson at apple.com>
> A commonly added feature in browsers these days is "private browsing
> mode" where the intention is that the user's browsing session leaves
> no footprint on their machine. Cookies, cache files, history, and
> other data that the browser would normally store to disk are not
> updated during these private browsing sessions.
> This concept is at odds with allowing pages to store data on the
> user's machine as allowed by LocalStorage and Databases. Surly
> persistent changes during a private browsing session shouldn't be
> written to the user's disk as that would violate the intention of a
> private browsing session.
> Let's take the specific case of LocalStorage, which is what I am
> currently working on with WebKit. In attempting to fix this bug I
> came up with a few possible solutions:
> 1 - Disable LocalStorage completely when private browsing is on.
> Remove it from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on. It
> exists at window.localStorage, but is empty and has a 0-quota.
> 3 - Slide a "fake" LocalStorage object in when private browsing is
> enabled. It starts empty, changes to it are successful, but it is
> never written to disk. When private browsing is disabled, all
> changes to the private browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing
> layer. It starts with all previously stored contents. Any changes
> to it are pretended to occur, but are never written to disk. When
> private browsing is disabled, all items revert to the state they
> were in when private browsing was enabled and writing changes to
> disk is re-enabled.
> 5 - Treat LocalStorage as read-only when private browsing is on. It
> exists, and all previously stored contents can be retrieved. Any
> attempt to setItem(), removeItem(), or clear() fail.
> Option 1 is simple but painful for applications to get such
> different behavior.
> Option 2 is only a little more complicated, but also seems
> Option 3 is simple to implement and option 4 would difficult to
> implement efficiently. Both would lead to bizarre behavior where
> data that the application thought was saved really wasn't.
> For now we're going with option 5. setItem() during private
> browsing will fail with the QUOTA_EXCEEDED_ERR the spec mentions.
> removeItem() and clear() will silently fail, since the spec assumes
> they always succeed and doesn't provide a failure mechanism.
> It seems the same issues apply to all the storage mechanisms, be it
> LocalStorage, SessionStorage (with optional session resuming), and
> I have a few questions I think it would be wise for the spec to
> address for all of these:
> 1 - What *should* the specified behavior be?
> 2 - If read-only ends up being the specified behavior, should we
> have a mechanism for removeItem() and clear() to demonstrate that
> they failed?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg