[webkit-dev] DOM Storage and private browsing

[Jeremy Orlow]

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 [1] 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
clean manner.

Thanks,
Jeremy

[1] https://lists.webkit.org/pipermail/webkit-dev/2009-May/007684.html


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 [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/cc5ad969/attachment.html>