[webkit-dev] DOM Storage and private browsing

[Jeremy Orlow]

Oh, and I forgot to mention: given your philosophy on private browsing and
the potential for session data being written to disk in the future, I think
it's reasonable to disallow writing to SessionStorage while in private
browsing mode.  I'll add a comment in the StorageArea.cpp code explaining
this decision.

J

On Wed, May 20, 2009 at 2:01 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

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