[whatwg] Private browsing vs. Storage and Databases

[Tab Atkins Jr.]

On Tue, Apr 7, 2009 at 7: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.

Having read the thread, as both a user and an amateur author, I think
#3 or #4 are the most reasonable.  All of the others are going to
break sites and provide bad user experiences.

There's really no way to argue this.  Most authors are idiots (just
like most users are idiots).  They'll use exactly as much of a feature
as they need, and nothing more.  They won't read standards, and they
won't check for errors.  #1 will *obviously* break things, especially
if accesses to LocalStorage throw during private browsing.  #5 will
put applications in an inconsistent state pretty quickly, as they
assume their writes were successful.  #2 is probably the most
pernicious, as it will bite users hardest when the author is *just*
smart enough to do some basic error checking (such as testing for
quota size) before they start to use LocalStorage.

Those three, each in their own way, feel more technically correct than
#3 and #4, and so I perfectly understand why they seem attractive to
implementors.  But they *will* cause serious problems for users, and
they *will* prevent people from using private browsing on
badly-designed LocalStorage/Database-using sites (which will be a
large percentage of them).

#3 and #4 are the realistic solutions here, both of which address the
problem while acknowledging the limitations of common author
abilities.  Which one is chosen is largely a matter of preference, and
aren't that significant.

~TJ