User:Jminta/Private Browsing

From MozillaWiki
Jump to: navigation, search

Private Browsing


  • Implement "private browsing sessions"
  • Unify private sessions with clear private data requests
  • Allow for extensions that manage private data to easily integrate with privacy settings.


  • relies on nsIObserverService and nsIObservers
  • supplements current privacy methods in nsIBrowserGlue

Private Browsing session

  • Each component with private data should add observers for the privacy-status-changed topic
  • The observer service will fire this topic when the privacy status changes
    • The subject for this topic will either be "private" or "normal", corresponding to the new privacy status beginning.
    • Components with private data will likely want to cache the current privacy status
  • We need some sort of XPCOM service broadcasting the current privacy status (with a boolean isPrivateSession attribute)
    • We can stick with nsIBrowserGlue (which has sanitize()) or move to a real privacy service

Clearing Private Data

  • Each element in the privacy preferences should be associated with a privacy-subject. (via a privacysubject attribute)
    • Extensions should overlay this window and listen for their subject
  • When "clear private data" is called via any method (prefs or main browser chrome), an nsIObserverService notification will go out with the clear-private-data topic for each privacy-subject to be cleared.
    • The subject of each of these notifications will be the associated privacy topic.
    • This will obsolete the browser:purge-session-history topic.

Private data collections

The following places keep private data that should be ignored during private sessions:

  • History
  • Cookies
  • Cache
  • SessionStore
  • ErrorConsole
  • AutoComplete (forms)
  • Download Manager
  • Password Manager?
  • Popup-blocker
  • Image-blocker
  • Certificates


I'm not entirely convinced about the idea of using nsIObserverService. If we're going to go to the length of making a real privacy interface, we might as well allow interested components to register nsIObservers directly with that service. I think this would help performance a bit, as we avoid adding more weight to nsIObserverService, but I could be wrong.