[whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

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/6a2f4632/attachment-0002.htm>