[whatwg] Private browsing vs. Storage and Databases
Ian Fette (イアンフェッティ)
ifette at google.com
Tue Apr 7 17:55:53 PDT 2009
Yes. An incognito session starts with a blank profile, so no cookies, no
On Tue, Apr 7, 2009 at 5:52 PM, Brady Eidson <beidson at apple.com> wrote:
> 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> wrote:
>> 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
>> Option 2 is only a little more complicated, but also seems unsatisfactory.
>> 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