W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2009

[whatwg] Private browsing vs. Storage and Databases

From: Brady Eidson <beidson@apple.com>
Date: Tue, 07 Apr 2009 18:07:02 -0700
Message-ID: <83251D81-757E-440A-BACA-3FCA028D84AA@apple.com>

On Apr 7, 2009, at 5:50 PM, Aryeh Gregor wrote:
>
> How are cookies handled right now?  Surely the issues should be pretty
> much the same?

They are unspecified.  From this thread I have learned that Chrome and  
Firefox start with no cookies.  Safari starts with a snapshot of  
cookies at the point where the user entered private browsing mode.  I  
would not be surprised if Opera or IE8 were subtley different from  
either of these two approaches.

>> 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.
>
> I certainly can't think of how 3 could ever cause a problem.  It
> should be the same as the user just logging in from a computer they
> haven't used before, shouldn't it?

I strongly share Jonas' concern that we'd tell web applications that  
we're storing there data when we already know we're going to dump it  
later.  For 3 and 4 both, we're basically lying to the application and  
therefore the user.  Imagine a scenario where a user has no network  
connection and unknowingly left their browser in private browsing  
mode.  Email, documents, financial transactions, etc could all be  
"saved" locally then later thrown away before they've had a chance to  
sync to a server.

> I don't think 1, 2, or 5 are good ideas, since they make localStorage
> semi-usable at best when privacy mode is enabled.

Apparently Firefox plans to implement #2, and so far I'm standing by  
WebKit choosing #5 for now.  Options 1, 2, and 5 all avoid the problem  
that 3 and 4 have which is that we're lying about saving data we have  
no intention to save.

~Brady
Received on Tuesday, 7 April 2009 18:07:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:11 UTC