[whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

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

Thanks,
~Brady