The WHATWG Blog

This Week in HTML 5 – Episode 30

April 13th, 2009 by Mark Pilgrim, Google in Weekly Review

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

There has been very little spec-related activity this week, so I will briefly repeat Ian Hickson's request to Help us review HTML5 and then turn to a fascinating debate happening right now on the WHATWG mailing list.

The debate revolves around perceptions and expectations of privacy. Brady Eidson (Apple/WebKit) kicks off the discussion with Private browsing vs. Storage and Databases:

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. Sur[e]ly 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. ...

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.

Ian Fette (Google/Chrome) explains how Google Chrome handles LocalStorage in "incognito" mode:

[W]hilst the [incognito] session is active, pages can still use a database / local storage / ... / and at the end of the session, when that [temporary] 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.

Darin Fisher (Google/Chrome) follows up to clarify Google Chrome's behavior:

Chrome's "incognito mode" means -- is defined as -- starting from a clean slate (as if you started browsing for the first time on a new computer), and when you exit incognito mode, the accumulated data is discarded. That's all there is to it. The behavior of LocalStorage and Database in this mode is deduced easily from that definition.

Jonas Sicking (Mozilla/Firefox) explains his opposition to option 5:

My concern with this is the same as the reason we in firefox clear all cookies when entering private browsing mode. The concern is as follows:

• A search engine stores a user-id token in a cookie. They then use this token to server side store the users 10 last searches.
• A user uses this search engine to search for various items. Doing this causes the user-id token to be stored in a cookie.
• The user then switches to private browsing mode.
• The user makes a search for a present for his wife.
• The user switches back into normal browsing mode.

At this point it is still possible to see the search for the wifes present in the websites store of recent searches.

Something very similar could happen for localStorage I would imagine, where the user-identifing information is stored in the localStorage rather than a cookie.

Josh "timeless" Soref (core Firefox developer) explores the privacy implications of different options:

[Option 1: Disabling LocalStorage won't work because] Many sites will just assume that they know a given useragent supports localstorage, so they'll be surprised and break. This will mean that a user can't use certain sites.

[Option 2: Enabling LocalStorage with 0 quota] will enable sites to know that the user is browsing in private, which is probably also a violation of the user's trust model. If I were to be browsing in private, I wouldn't want most sites to know that I'm doing this.

[Option 4 or 5: Starting with existing LocalStorage data] means the site will know who you are (on average), and is almost certainly never what the user wants.

Jonas Sicking (Mozilla/Firefox) tentatively states

For what it's worth, I believe we're currently planning on doing 2 in firefox.

Brady Eidson concludes:

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.

... So far I'm standing by WebKit choosing #5 for now.

Drew Wilson summarizes his thoughts on the matter:

I think the #1 goal for incognito mode has to be "maximum compatibility" -- let sites continue to work, which kills options #1 & 2. A secondary goal for incognito mode would be "don't let sites know the user is in incognito mode" -- this kills approach #1 and #5, and possibly #2 (depending on whether there are significant non-incognito use cases that also have 0 local storage quota).

For my part, I agree with Drew, and I would add this: I use Google Chrome's "incognito mode" quite frequently when I'm developing websites. It's an easy way to test from a "blank slate" with no cookies and no cache, and it's much easier than juggling multiple profiles. If data in my LocalStorage "bleeds" into incognito mode, this use case would become unreliable and web development would be harder for me. (Bil Corry makes this point too.)

On a more philosophical level, it's nobody's business that I'm in private browsing mode. (Scott Hess makes this point too.) If authors can detect it, I consider that a serious bug. (Imagine the ha.ckers.org headline: "Safari Hole Allows Sites To Detect 'Private' Browsing, Punish Users.") Even worse, if LocalStorage could be used as a "super-cookie" for less-than-honorable sites to track me from normal usage to incognito usage, then it's not really "private browsing" in any sense of the word that matters.

In the early days of Greasemonkey, there were discussions of whether Greasemonkey should send or provide some detectable signal to page authors that Greasemonkey was running and the user had active scripts modifying the current page. To which I replied:

If Greasemonkey makes any overtures towards allowing web publishers to "opt out" or override my browsing experience in any way, I will immediately fork it and make it my life's mission to maintain the fork as long as possible.

Tune in next week for another exciting episode of "This Week in HTML 5."

This Week in HTML 5 – Episode 29 ↔ The Road to HTML 5: Link Relations