User:Jminta

Private Browsing

Goals:

• 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.

Implementation:

• 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

Notes

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.