User:Jminta/Private Browsing
From MozillaWiki
Contents
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.