[whatwg] Private browsing vs. Storage and Databases

[Ian Fette (イアンフェッティ)]

In Chrome/Chromium, "incognito" mode is basically a new profile that is in
memory (plus or minus... the cache will never get written out to disk,
although of course the memory pages could get swapped out and hit the disk
that way...). The implication is that, for many of these features, things
could just naturally get handled. That is, whilst the session is active,
pages can still use a database / local storage / ... / and at the end of the
session, when that profile is deleted, things will go away. I personally
like that approach, as there may be legitimate reasons to want to use a
database even for just a single session. (Perhaps someone wants to edit a
spreadsheet and the spreadsheet app wants to use a database on the client as
a backing store for fast edits, I don't know...). I just don't like the idea
of saying "Sorry, incognito/private/... means a class of pages won't work"
if there's no reason it has to be that way.
In short, I would prefer something closest to Option 3. It lets pages just
work, but respects the privacy wishes of the user. (AppCache / persistent
workers are the one exception where I think Option3 doesn't apply and we
need to figure something out.)

-Ian

On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson <beidson at apple.com> wrote:

> A commonly added feature in browsers these days is "private browsing mode"
> where the intention is that the user's browsing session leaves no footprint
> on their machine.  Cookies, cache files, history, and other data that the
> browser would normally store to disk are not updated during these private
> browsing sessions.
>
> This concept is at odds with allowing pages to store data on the user's
> machine as allowed by LocalStorage and Databases.  Surly persistent changes
> during a private browsing session shouldn't be written to the user's disk as
> that would violate the intention of a private browsing session.
>
> Let's take the specific case of LocalStorage, which is what I am currently
> working on with WebKit.  In attempting to fix this bug I came up with a few
> possible solutions:
>
> 1 - Disable LocalStorage completely when private browsing is on.  Remove it
> from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
> window.localStorage, but is empty and has a 0-quota.
> 3 - Slide a "fake" LocalStorage object in when private browsing is enabled.
>  It starts empty, changes to it are successful, but it is never written to
> disk.  When private browsing is disabled, all changes to the private
> browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing layer.  It
> starts with all previously stored contents.  Any changes to it are pretended
> to occur, but are never written to disk.  When private browsing is disabled,
> all items revert to the state they were in when private browsing was enabled
> and writing changes to disk is re-enabled.
> 5 - Treat LocalStorage as read-only when private browsing is on.  It
> exists, and all previously stored contents can be retrieved.  Any attempt to
> setItem(), removeItem(), or clear() fail.
>
> Option 1 is simple but painful for applications to get such different
> behavior.
> Option 2 is only a little more complicated, but also seems unsatisfactory.
> Option 3 is simple to implement and option 4 would difficult to implement
> efficiently.  Both would lead to bizarre behavior where data that the
> application thought was saved really wasn't.
>
> For now we're going with option 5.  setItem() during private browsing will
> fail with the QUOTA_EXCEEDED_ERR the spec mentions.  removeItem() and
> clear() will silently fail, since the spec assumes they always succeed and
> doesn't provide a failure mechanism.
>
> It seems the same issues apply to all the storage mechanisms, be it
> LocalStorage, SessionStorage (with optional session resuming), and
> Databases.
> I have a few questions I think it would be wise for the spec to address for
> all of these:
> 1 - What *should* the specified behavior be?
> 2 - If read-only ends up being the specified behavior, should we have a
> mechanism for removeItem() and clear() to demonstrate that they failed?
>
> Thanks,
> ~Brady
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090407/4ac90273/attachment-0002.htm>