[whatwg] Private browsing vs. Storage and Databases

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

Yes. An incognito session starts with a blank profile, so no cookies, no
cache, ...
On Tue, Apr 7, 2009 at 5:52 PM, Brady Eidson <beidson at apple.com> wrote:

> That's interesting.  I'm not exactly clear what an "incognito" session
> starts out with.  Does it start without any cookies, for example?
> ~Brady
>
> On Apr 7, 2009, at 5:39 PM, Ian Fette (イアンフェッティ) wrote:
>
> 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/85dac2f8/attachment-0001.htm>