Main goals

• Ensure that users can't be tracked when doing "private" things. There should be a clear line drawn between your "public" and "private" browsing sessions. It is acceptable to let things touch magnetic storage, as long as the cleanup mechanism is robust enough to clean up.

• It is also acceptable to retain data that users explicitly save (per-site permissions via prefs, bookmarks, etc)

• Non-goal for 3.1: Separate process sharing (some) data. When we get process-per-tab we can make it more IE-like, but doing this also means that we have to have something like their "hey, you're in private browsing mode" banner on the URL bar for all the world to see. Which, to me, is fail.

Specifics

Cookies

• On entry:
  • Write cookies to disk, drop the in-memory hashtable.
• During:
  • All cookies are only stored in memory.
• Exit:
  • Drop the hashtable, reload from disk.

History

• On entry:
  • Record timestamp of the last visit recorded.
• During:
  • IsVisited always returns false (no link coloring spying)
  • AddVisit silently fails.
• Exit:
  • Ensure any visits recorded after the timestamp are purged (shouldn't be needed, but might be useful as a sanity check).

Cache

• On entry:
  • Disable disk cache, clear memory cache
• During:
  • use memory cache only
• Exit:
  • Clear memory cache, re-enable disk cache

Site Permissions

• Will not prevent users from explicitly adding exceptions via Prefs or Page Info

Site Specific Prefs

• Nothing special for enter/exit
• During, we will not remember new entries, but will update existing ones. In current known usage (only used for zoom in Firefox) this is not a data leak. It is possible for extension uses to leak some data here, but there's a lot of things extension authors can do wrong.
  • This effectively means that setPref() will fail if hasPref() is false. This will likely be a silent failure so as to not throw for existing callers.

Passwords

• Do not prompt to save passwords.
• Passwords will not autofill to content, but will be available for autocomplete.
• HTTP Auth passwords will still autofill, as there is no autocomplete, and unless the user hits OK the site cannot access the credentials.

Downloads

• On entry:
  • Existing downloads will be paused.
  • If a download cannot be paused, the user will need to choose whether to enter private browsing mode or finish the download.
  • Write all download info to disk, and switch to using an in-memory table (sdwilsh to provide explicit details on the dlmgr changes needed)
• During:
  • Previous downloads will not be available from the download manager.
  • PB downloads will be available for the length of the PB session
• On exit:
  • Cancel any in-progress downloads (prompt, do not exit PB)
  • In-memory DB should be deleted.
  • Re-init download list from disk

Other

• Autocomplete will be available, but will not remember data entered.
• DOMStorage will not allow reading or writing of data (need JST/Enn feeedback on how to do this cleanly)
• All authenticated sessions will be logged out entering and leaving private mode.
• Downloads will be removed from dlmgr on completion.
• Content prefs will not be saved.

Session Store

• On entry:
  • Save session, close all tabs, open a blank tab.
• During:
  • Do not save any session data to disk, keep undo close tab data in memory.
• On exit:
  • Clear all session data in memory, load saved session from disk.

APIs for Extensions

You can view a draft of the APIs that the extensions will be able to use in order to interact with the private browsing mode here. This page also includes a number of code samples for common tasks.