Most modern Web browsers have implemented a browsing mode that is meant to keep others, who may have access to the machine, from discovering a user’s browsing history (searches, sites visited, etc.). This capability goes by various names: Google’s Chrome calls it “Incognito Mode”, Firefox and Safari call it “Private Browsing”, and Internet Explorer calls it “InPrivate Browsing”. Regardless of the name, the idea is that the browser either does not record, or erases on exit, things like the history list of URLs accessed.
An article at Ars Technica describes some experiments on private browsing carried out by a team of researchers from Stanford and Carnegie-Mellon, who presented a paper [abstract PDF] at the USENIX 2010 Security Symposium. The authors begin by trying to specify a bit more precisely what the objective of private browsing is: to avoid any persistent state changes on the browser machine that would reveal the user’s past behavior. (As the authors correctly point out, none of this matters if the attacker can have access to the machine during the browsing session, since in that case there are many ways in which the user’s actions can be tracked.) They distinguish among four types of state information:
- Changes initiated by a Web site without user interaction, such as adding an entry to the URL history list, or setting a cookie.
- Changes initiated by a Web site with user interaction, such as setting a password that is saved.
- Changes initiated by the user, such as setting a bookmark, or downloading a file.
- Changes that are not user-specific, such as updating the browser or add-ons, or updates to a “no phishing” list.
The existing implementations focus on trying to remove traces of changes in the first category; changes in the other categories fall into something of a gray area, and are often treated inconsistently, even though they may provide an attacker with a good deal of information.
The team found a variety of weaknesses in the existing implementation of private browsing modes. Some of these are direct consequences of how certain features are implemented; for example:
- There is an HTML 5 feature called custom protocol handlers, which allows a Web site to define custom protocols via the use of a URL like
xyz://foo.bar.com/path/, to define the ‘xyz’ protocol. In the Firefox implementation, these definitions persist after exiting private mode, thus potentially leaking part of the browsing history.
- Internet Explorer, Firefox, and Safari support SSL client certificates. A Web site can request the browser to generate an SSL client public/private key pair. The keys are retained when the private mode is exited, potentially leaking the site’s identity. Internet Explorer and Safari also retain self-signed SSL certificates encountered during a private browsing session.
There is also potential information leakage from facilities in the machine environment that are not directly controlled by the browser. The operating system can, for example, swap pages of virtual memory to disk; if these pages happen to contain private browsing data, they potentially can be recovered later. Preventing this would require the browser to make all these data pages “unswappable”. This can get messy, and might well adversely affect the performance of the system.
The authors go on to examine the example of Firefox in more detail, first by using a manual code review of how changes to persistent state were implemented, and second by using an automated tool to check for state changes. They found a number of areas where information could “leak” from private browsing mode.
The problem becomes even more complicated when browser add-ons are taken into account, since the exact function of an extension is typically not controlled by the browser developer. The browsers themselves have different default policies with respect to add-ons in private mode: Chrome disables most extensions (but not plugins) by default, Firefox allows them by default, and Internet Explorer disables extensions but allows ActiveX controls (cf. “swallow a camel but strain at a gnat”).
There is much more in the paper of interest to security-minded browser users. To the basic question of whether private browsing is secure, the answer is it depends: it’s probably enough to discourage your nosy kid brother , but it probably wouldn’t be wise to count on it for anything very important. But then, you’d never do that anyway, would you?