[whatwg] Private browsing vs. Storage and Databases

[timeless]

2009/4/8 Jeremy Orlow <jorlow at google.com>:
> If a user is in private browsing mode typing up a message, they should
> definitely not expect it to be there when they leave such a mode.  If they
> do expect it to be there, then they really wanted multiple profiles.
> I know it's bad to make presumptions, but I just can't see any web developer
> depending on the localStorage or database API as anything more than a cache.
>  When a user is on a web application, they expect to be able to go to
> another computer and access that information.

> Also note that, if you assume these APIs are anything other than fairly
> permanent caches, then your browser had better have a good story for when
> the user upgrades/downgrades their browser or even switches computers.  This
> feels like we're going back to the POP3 era of email.  :-)

speaking of which.

Is there any API in localStorage to enable the browser to tell the web
app that it wants to reduce the size of its cache, to e.g. 0?

Because if we had an API which would let the browser tell an app "my
user has decided to reduce your available space to <x>" and the user
picks 0, then the app can choose to flush all of its pending data.

And private browsing could use that API at the end. Sadly, it might be
worth giving the user some indication of how much data has been stuck
in private browsing by a given web page.

I'd suggest 3 w/ a thing to flush stuff. Preferably flushing as soon
as the user closes the last page of a site (i.e. before the user
closes the last page in their private browsing session). It should
probably be in the form of a visible opt in bit:

This site is using <counter> MB of data. When I leave it, I <[x] do
not> want the site to know that its data is being removed. [?] <hide
banner>

1 - Disable LocalStorage completely when private browsing is on.
Remove it from the DOM completely.

Many sites will just assume that they know a given useragent supports
localstorage, so they'll be surprised and break.
This will mean that a user can't use certain sites.

2 - Disable LocalStorage mostly when private browsing is on.  It
exists at window.localStorage, but is empty and has a 0-quota.

This will enable sites to know that the user is browsing in private,
which is probably also a violation of the user's trust model.
If I were to be browsing in private, I wouldn't want most sites to
know that I'm doing this (which is why the banner i mention above must
give the user the choice).

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.

This means the site will know who you are (on average), and is almost
certainly never what the user wants. If the user wants to tell the
site who they are, then the user can log in after enabling private
browsing.

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.

This acts like 4 and isn't helpful either.