[whatwg] Private browsing vs. Storage and Databases

[Jonas Sicking]

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.

For what it's worth, I believe we're currently planning on doing 2 in
firefox. (not sure if it's been implemented in nightly trunk builds
yet).

> 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.

We felt like there was a risk of data loss with this approach. For
example imagine a web app that lets you write an email. Every 2
minutes the app saves your email in case of a crash or power loss or
similar. The app uses localStorage if possible, but if not uses
XMLHttpRequest to save the data to the server.

In this model it is significantly worse if it looks like a write is
successful, but in fact isn't.

> 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.

My concern with this is the same as the reason we in firefox clear all
cookies when entering private browsing mode. The concern is as
follows:

1. A search engine stores a user-id token in a cookie. They then use
this token to server side store the users 10 last searches.

2. A user uses this search engine to search for various items. Doing
this causes the user-id token to be stored in a cookie.

3. The user then switches to private browsing mode.

4. The user makes a search for a present for his wife.

5. The user switches back into normal browsing mode.

At this point it is still possible to see the search for the wifes
present in the websites store of recent searches.

Something very similar could happen for localStorage I would imagine,
where the user-identifing information is stored in the localStorage
rather than a cookie.

However other browsers have decided *not* to clear cookies as I
understand it. For these browsers 5 would make a lot of sense. So I
suspect we need to leave some headroom here for various implementation
strategies for private browsing mode.

/ Jonas