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 <[email protected]>
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
