- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 20 Apr 2009 05:54:07 +0000 (UTC)
On Tue, 7 Apr 2009, Brady Eidson 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. Different "private browsing modes" have different philosophies and purposes, but yes, this feature does exist in different variations in different browsers. > Cookies, cache files, history, and other data that the browser would > normally store to disk are not updated during these private browsing > sessions. That is one implementation strategy, indeed. > 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. I think we can all agree that nothing should be written to disk, yes. > 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. Not implementing a feature is an option, though it would cause sites that use that feature to not work. > 2 - Disable LocalStorage mostly when private browsing is on. It exists > at window.localStorage, but is empty and has a 0-quota. This doesn't seem to offer any advantages over the previous option, though it is more likely to run into trouble (e.g. sites that detect its support will assume it is functional instead of falling back on another feature). > 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. That seems like a reasonable strategy; it would be equivalent to the browser being two user agents, one for the private mode and one for the regular mode. > 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. That is again a reasonable implementation strategy, similar to the previous one. > 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. This would be equivalent to the user agent having hardware limitations preventing it from complying with the specification, as with an out-of- memory condition or some such. User agents are explicitly allowed to make arbitrary implementation choices for such cases. Note though that this allows the sites to detect with some reliability when they are being visited in "private" mode. This can be a problem. > 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. If the private browsing mode is documented as being intended to act in a manner that does not comply with the specification, that seems fine (though it leaks to the site the information that the user is using private browsing mode, which could be a problem). It is the equivalent of "Small Screen Rendering" mode in browsers like Opera, where the CSS specifications are intentionally not implemented correctly in order to achieve particular results the author didn't intend. > 1 - What *should* the specified behavior be? Since the answer depends on the philosophy of the browser feature, which can vary from implementation to implementation, there is no single answer to this. I don't think this is something that can or should be described in a formal user-agent-independent specification. > 2 - If read-only ends up being the specified behavior, should we have a > mechanism for removeItem() and clear() to demonstrate that they failed? They can always fail with a user-agent-specific exception, as with "out of memory" conditions. On Tue, 7 Apr 2009, 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. This is a reasonable implementation strategy, equivalent, as you describe, to the browser pretending to be two different user agents, and the configuration or user data for one of these user agents being deleted before the user can use it again. On Tue, 7 Apr 2009, Jonas Sicking wrote: > > 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). This is no different to the normal case, where the hard disk might fail unexpectedly, or the user might wipe his profile, or uninstall the browser, or switch to another browser, or another computer. It's just that we know ahead of time (and theoretically, the user knows ahead of time) that the data will be lost. This could be addressed by some UI informing the user that the data is not permanently stored, e.g. an infobar when a change is detected that says: This site has attempted to store data locally. Because you are in Private Browsing Mode, this data will be lost when you close this window. (( More information )) There could even be some interface to force the information to be stored, though care would have to be taken to implement this in a way that doesn't clobber information set in the regular-mode browsing contexts. On Tue, 7 Apr 2009, Brady Eidson wrote: > > LocalStorage and Databases are expected to be persistent unless a script > or the user explicitly removes them. They're more like files, where > arbitrarily misplacing them is unacceptable. I think in practice they're more like files, where arbitrarily misplacing them is common. On Wed, 8 Apr 2009, timeless wrote: > > Is there any API in localStorage to enable the browser to tell the web > app that it wants to reduce the size of its cache, to e.g. 0? Not currently. > Because if we had an API which would let the browser tell an app "my > user has decided to reduce your available space to <x>" and the user > picks 0, then the app can choose to flush all of its pending data. Since this might happen even when the Web page in question isn't open, or when the user is visiting one app (e.g. Mail) when that domain stores data for multiple other apps (e.g. Calendar and Contacts), I don't really see how we can do this. On Tue, 7 Apr 2009, Jeremy Orlow wrote: > > Maybe something could be added to the spec with respect to App Cache. > For example, an app in app cache could define something to be run when > it's being evicted from storage? Of course, this could have some > interesting/negative security implications. In addition, if the user is > off line, they're completely screwed. I think this would also lead to sites depending on this, which they can't, for numerous reasons already listed (e.g. the user just moving to another computer without doing anything about his browser's local data). On Tue, 7 Apr 2009, Brady Eidson wrote: > > 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. I disagree that lying to the app is the same as lying to the user. Is blocking third-party cookies "lying to the user"? > Imagine a scenario where a user has no network connection and > unknowingly left their browser in private browsing mode. That would seem like a UI bug. Surely there should be no doubt in the user's mind as to which mode he is using. On Tue, 7 Apr 2009, Ian Fette (????????????????) wrote: > > FWIW, I think it would be helpful to expose via some manner that the > user is in an incognito/private/whatever mode, especially to plugins. > (Right now none of us can really control what plugins are doing). If we > exposed that fact, a page could check it and decide what it wants to do. > To me, that feels a lot better than just saying "No, sorry, you don't > get XYZ." Exposing this to plugins makes sense; I recommend raising this with the plugin-futures group working on the NPAPI. On Tue, 7 Apr 2009, Brady Eidson wrote: > > Another problem with the "reset to an empty storage area" case is this: > say the user starts using an application and it does some things with > LocalStorage. Then, without leaving the application, the user realizes > "Oh, I should be in private browsing mode" and activates it. In one > fell swoop, LocalStorage is reset to empty and the application is left > in an inconsistent state. Is that okay? From the specification's perspective, yes. Assuming you're implementing "private browsing mode" as a "pretend to be on a readonly filesystem" mode, then you've just enabled a mode in which the browser pretends to have a hardware limitation preventing it from writing to disk. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 19 April 2009 22:54:07 UTC