[webkit-dev] DOM Storage and private browsing
jorlow at chromium.org
Wed May 20 14:01:41 PDT 2009
Thanks a lot for the quick response. This does clear up a lot for me.
Hopefully I'll send my first DOM Storage re-factoring  patch out in a day
or two. Once the re-factoring is squared away, I'll try to tackle these
inconsistencies. (And, a little further out, I'm hoping to add Quota
support and memory reclamation code.) In the mean time I'll file a bug.
Note that, with respect to some of these corner cases, I think Chromium's
behavior may need diverge from the default WebKit behavior. (For example,
incognito mode will be different from WebKit's private browsing.) That
said, I think it should be pretty easy to handle these differences in a
On Wed, May 20, 2009 at 1:38 PM, Brady Eidson <beidson at apple.com> wrote:
> 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 , 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  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  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 ) 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  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. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev