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

[whatwg] Private browsing vs. Storage and Databases

From: Michael Nordman <michaeln@google.com>
Date: Tue, 7 Apr 2009 18:11:56 -0700
Message-ID: <fa2eab050904071811v6fc07a11g2a2180abf5f7d516@mail.gmail.com>
I think a user agent has to harmonize across all manner of shared
resources being introduced to ensure a reasonable behavior is
provided.
* localstorage (and the breadth of the associated events)
* databases
* appcaches
* named shared workers

Starting with nothing, keeping it all walled-off from the 'real'
peristent data, and scrapping it all at the end of the ingocnito
session seems reasonable.

Throwing exceptions when these facilities are used would mean those
sites just couldn't be visited incognito.

Actually storing the data seems contrary to the point of incognito.


2009/4/7 Jonas Sicking <jonas at sicking.cc>:
> 2009/4/7 Ian Fette (????????) <ifette at google.com>:
>> 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.)
>
> I do agree that there's still need for storing data while in private
> browsing mode. So I do think it makes a lot of sense for
> .sessionStorage to keep working.
>
> But I do have concerned about essentially telling a website that we'll
> store the requested data, only to drop it on the floor as soon as the
> user exits private browsing mode (or crashes).
>
> / Jonas
>
Received on Tuesday, 7 April 2009 18:11:56 UTC

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