[webkit-dev] DOM Storage and private browsing

[Brady Eidson]

On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote:
> I'm pretty confused by the policy decisions in DOM Storage with  
> respect to private browsing.

> Just to be clear, I understand that Safari's private browsing has a  
> different philosophy from Chromium's incognito mode.

Right.  To re-clarify for this discussion:
WebKit's private browsing feature exists as direct result of the  
design of Safari's private browsing feature from many years ago.   
Safari's private browsing feature has always been about "do not leave  
any local footprint on the user's disk pertaining to this browsing  
session" and has never been about creating an anonymous profile for  
the wild.

Take a look at cookies, for example - a private browsing session  
starts with an in-memory copy of the cookies that existed at the time  
the session starts.  Any changes to cookies during the session are not  
persisted to disk.  When the private browsing session is over, we  
revert back to the stored cookies as they existed when private  
browsing began.

We definitely discussed applying that model to LocalStorage, and it's  
certainly not off the table to do so.  But such a solution would be  
much more complex, and were more concerned with closing the  
"LocalStorage changes are written to disk during private browsing" bug  
in the meantime.

> When in private browsing, both LocalStorage and SessionStorage  
> return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply  
> ignore removeItem() and clear() calls.  This is different from the  
> behavior when LocalStorage persistence is disabled (because page- 
> >settings()->localStorageDatabasePath() returns nothing) which  
> returns a LocalStorage object that is not database backed.

I think this is a bug.  The crux of the emails to whatwg that you  
reference is that we have two strong convictions:
1 - LocalStorage is guaranteed to be persistent.  We're giving web  
developers simple, reliable, persistent storage and we plan to treat  
it like user data that only the controlling web apps or users  
themselves can make decisions about
2 - Since LocalStorage is guaranteed to be persistent, we should never  
give a web app the indication that we've stored some data when we  
actually have no intention to store it.

If we can get a LocalStorage object that is not database backed, this  
goes against that philosophy and is a potential bug.

> According to a FIXME in LocalStorage::fullDatabaseFilename [2],  
> there's also plans to allow LocalStorage (but just not back it with  
> a database) when there is no quota.
>
> The first question is why private browsing affects SessionStorage?   
> The original email [1] on the matter didn't mention changing this,  
> and I can't see any reason why it needs to.

 From the ChangeLog for r42302 - "...made the change to restrict  
SessionStorage to read-only, also, with the understanding that the  
spec allows for SessionStorage to persist across relaunches, even  
though our implementation currently doesn't do this."

This may have been overzealous preparation for the future, but  
hopefully it explains the thinking behind it.

> Next, why the (planned) inconsistency in quota handling?  This seems  
> to go against the Apple view on LocalStorage persistence ("[doing  
> this] would lead to bizarre behavior where data that the application  
> thought was saved really wasn't" is the only example I could find in  
> 1 minute, but I believe there's others in [3] and other threads).   
> It also seems confusing that the script would get a  
> QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non- 
> database backed storage if there's 0 quota.

As said above, if we can't back a LocalStorage object with a database,  
we shouldn't be pretending to store data in it.  This is a bug.  Same  
with 0 quota.  It should probably end up having the read-only behavior  
as currently implemented for private browsing.

> Lastly, I have to ask (at the risk of rehashing [3]) why private  
> browsing gives access to data accumulated before entering private  
> browsing (which could be sensitive and user identifying!) and why  
> it's considered ok to silently ignore requests to clear/remove data  
> (even though it's not OK according to [1] to offer a non-persistent  
> LocalStorage).
> I'm bringing this up because (as far as I can tell) WebKit is not  
> consistent internally.  If any changes need to be made as a result  
> of this discussion, I'm happy to make them.  :-)

I started out with a description of Safari's Private Browsing  
philosophy then clarified a few points on our LocalStorage  
philosophy.  Hopefully that - combined with the acknowledgement of  
some bugs! - clears up the inconsistencies.  ;)

As far as "silently ignoring requests to clear/remove data" - I  
personally hate the fact that we silently ignore such requests.  One  
intent of my original email to whatwg was to get a mechanism to ignore  
these requests LOUDLY.  But unlike the setItem() case where the spec  
gave us an out in the form of "QUOTA_EXCEEDED_ERR," there was no  
spec'ed behavior we could adapt for the ignoring remove/clear requests.

 From our viewpoint, there's two great reasons to have the "read-only  
LocalStorage" mode.  One is our private browsing philosophy.  Two is  
the other cases where changes to the LocalStorage object won't  
actually be saved to disk (such as the "no database filename" or "0  
quota") issues.

I completely understand that Chromium has a different philosophy with  
Incognito mode versus Safari's private browsing.  But I think the "we  
should never pretend to store data that we have no intention to store"  
philosophy is a more fundamental WebKit issue.  WebKit shouldn't  
lie.  :)

~Brady




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090520/b5e729cb/attachment.html>