289
edits
User:Jminta: Difference between revisions
Jump to navigation
Jump to search
private browsing sketch
(initial stab at gfxcontext migration list) |
(private browsing sketch) |
||
| Line 1: | Line 1: | ||
== | == 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 <code>privacy-status-changed</code> 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 <code>clear-private-data</code> 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 <code>browser:purge-session-history</code> 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. | |||