[webkit-dev] DOM Storage and private browsing

Jeremy Orlow jorlow at chromium.org
Wed May 20 13:03:39 PDT 2009

I'm pretty confused by the policy decisions in DOM Storage with respect to
private browsing.

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

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.

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 sorry if these questions sound antagonistic, but I just want to
understand what the overall way of thinking/vision is here.  Just to be
clear, I understand that Safari's private browsing has a different
philosophy from Chromium's incognito mode.  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.  :-)


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

More information about the webkit-dev mailing list