Firefox3.1/PrivateBrowsing/SecurityReview

Overview

Private Browsing is a new browsing mode in which no data which can be used to track down the visited websites is ever written to disk. This includes only data not saved explicitly by the user (such as history, cache, cookies), while explicitly stored data (such as bookmarks) is allowed.

Background links

• Tracking bug 248970
• Functional specification
• Unit test plan

Security and Privacy

• Is this feature a security feature? If it is, what security issues is it intended to resolve?
  • No.

• What potential security issues in your feature have you already considered and addressed?
  • Not leaking data which can connect user's private and non-private browsing habits.
    • There is a limit to what we can practically achieve here. Some simple cases have been considered:
      • Not use non-private cookies in private browsing mode, and vice-versa.
      • Not use non-private cache entries in private browsing mode, and vice-versa.
      • Turn off automatic coloring of visited links in private browsing mode.
  • Block access of web content to the about:privatebrowsing page.

• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • No.

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • Assumptions:
    • None.
  • Capabilities:
    • Being able to connect private and non-private browsing modes by websites (blocked to some extent). This is more of a privacy concern than a security concern.
    • Accessing about:privatebrowsing by web content in hopes of determining the current status of the private browsing mode (blocked).
  • Potential risks:
    • The private browsing mode touches a large amount of code base, and hence is prone to mistakes which can potentially lead to security exploits. I have tried to minimize this by an extensive automated test suite, which tests nearly all aspects of the implementation (the exceptions being things which can't be tested with our current testing frameworks -- such as closing the browser window in a browser chrome test). This may not be considered adequate though.
    • Extensions can simulate the private browsing mode transitions by sending private browsing notifications themselves (see the answer of the next question). This can have undefined results.
    • Extensions can react on transitions from and to the private browsing mode. Therefore, extensions can have security bugs which get activated as a result of (de)activating the private browsing mode.

• How are transitions in/out of Private Browsing mode handled?
  • The Private Browsing service acts as a central point to manage the transitions to and from the private browsing mode. Once a caller requests a change in the private browsing mode, this service sends a series of notifications. Each module which is aware of the private browsing mode has the responsibility of updating its own status upon receiving this notification.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • nsIPrivateBrowsingService interface.
  • Tools > Private Browsing menu item (UI).
  • Two notifications: private-browsing and private-browsing-cancel-vote.

• Does it interoperate with a web service? How will it do so?
  • No.

• Explain the significant file formats, names, syntax, and semantics.
  • No file formats used.

• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
  • Yes: documentation for the interface, my blog post explaining how an extension or theme can support the private browsing mode in detail, an MDC article based on my post

• Does it change any existing interfaces?
  • No.

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)?
  • The implementation uses/changes the following modules:
    • cache
    • cookie
    • downloads
    • passwordmgr
    • contentprefs
    • places
    • satchel
    • sessionstore
    • browser (for UI, front-end changes)
    • toolkit (for front-end changes)
    • DOM storage
    • http auth cache
    • pippki

Data

• What data is read or parsed by this feature?
  • None.

• What is the output of this feature?
  • The output is behavioral (no data capable of exposing the visited websites is written to disk). The result of the work of this feature is that some parts of the output of other modules get disabled.

• What storage formats are used?
  • None.

Reliability

• What failure modes or decision points are presented to the user?
  • The user can decide whether or not to enter a private browsing session.
  • The user can decide whether to turns private browsing on/off if a non-resumable download is active.

• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
  • No files are used by this feature.
  • If the browser crashes during a private browsing session, the restored session after restarting it doesn't contain any evidence of the previous private session.

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
  • Via UI:
    • The user can choose not to get prompted when starting the private browsing mode.
  • Via about:config:
    • browser.privatebrowsing.dont_prompt_on_enter: the pref exposed in the UI (see above)
    • browser.privatebrowsing.autostart [hidden]: setting it to true causes Firefox to start in private browsing mode by default, and makes this permanent throughout the whole session.
    • browser.privatebrowsing.keep_current_session [hidden, undocumented]: prevent the existing session to be closed when entering the private browsing mode. This pref is only used for unit tests where the test framework can't handle closing of the session. This pref does not appear in about:config unless explicitly set by the user.

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]
  • No.

• What ranges for the tunable are appropriate? How are they determined?
  • All the three prefs are boolean.

• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
  • None.

Relationships to other projects

Are there related projects in the community?

• • No.

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
  • No.

• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?
  • No.

Review comments

• primary thrust is shared-machine privacy (engagement-ring privacy)
• Not telling user we protect against site tracking, but we do minimize some things such as cookies
• Not Tor-level anonymity, we need to be clear.
• Network router knows where you've been, not a way to hide unauthorized access from work.
• Not protecting against flash cookies.
  • plugin vendors (e.g. Adobe) want private mode exposed through NPAPI so they can take appropriate action. Need to spec this ASAP through plugin-futures, but not for 3.1
    • bug 468877 filed: "Expose the private browsing mode's current status and transitions through NPAPI"
  • A user-visible pref to say "no plugins in private mode" would be good to have for some users, but probably not a good default.
    • bug 468879 filed : "Add a preference to disable plugins inside the private browsing mode"
• Addons can be notified about private mode, at their discretion
• We allow users to take actions to save info (bookmarks, site prefs), and will remember saved info (including passwords).
• The added bookmark will show a visit count of zero.
• We don't autofill forms/passwords, but autocomplete will work
• HTTP Auth prompts autofill remembered passwords. The site can't get the info unless you submit, but Ehsan worries this might lure people to give up their privacy too easily.
• about:privatebrowsing is a privileged page, blocked from sites. Has a button to clear recent history.
• Private Browsing is hard to enter (menu item only). It may not be common enough to warrant a reserved hot-key, but it seems like users who use it will use it a lot. Should there be a custom toolbar button these folks could add?
  • An extension already available to do this...
• temporary SSL cert exceptions might be visible in the UI after exiting private browsing mode.
  • They're not -- the list shown in the UI seems to be filled based on permanent exceptions only. The only leak here is if someone tries to check if a temporary exception has been added for a particular site with an invalid certificate by typing its URL and trying to see if the error page shows up or not. This leak should be fairly minor. Do we want to protect against this?
• DOMStorage still in the air. Probably should degrade globalStorage to sessionStorage (as we do when cookies are set to be only session cookies), and then flush the sessionstorage entering and leaving private mode.