Closed Bug 967809 Opened 12 years ago Closed 12 years ago

Content Pref Service writes to disk in Private Browsing Mode

Categories

(Firefox :: Private Browsing, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mikeperry, Unassigned)

Details

(Whiteboard: [tor])

Attachments

(1 file)

In Tor Browser, we had to patch the content preferences service to make it memory only, to avoid leaking site information to disk. Our patch is simple, because we did not need to support non-private browsing modes. A final version will need some code to hook into the existing private browsing mode notification and window handling code in Firefox. This patch is against FF24ESR.
Whiteboard: [tor]
The content prefs service uses an in-memory database for load contexts that are in private browsing mode already, see <http://mxr.mozilla.org/mozilla-central/source/toolkit/components/contentprefs/nsContentPrefService.js#242> for example. I'm not sure why you needed this patch in addition to the existing protection. Can you please clarify? Thanks!
Component: General → Private Browsing
Flags: needinfo?(mikeperry)
Ah, this patch was originally written 2 years ago (against either Firefox 4 or FF10esr), before per-window private browsing. It is likely we just didn't notice it was now redundant to the new per-window private browsing mode. However, just so I'm clear, are you sure that the private browsing context is properly set for this pref service call if the user has enabled "Permanent Private Browsing Mode" (browser.privatebrowsing.autostart)? IIRC, we have noticed some differences between permanent and per-window behavior, but I don't think we actually tested this particular case (since this patch just sat in the tree, happily still applying).
Flags: needinfo?(mikeperry)
(In reply to Mike Perry from comment #2) > Ah, this patch was originally written 2 years ago (against either Firefox 4 > or FF10esr), before per-window private browsing. It is likely we just didn't > notice it was now redundant to the new per-window private browsing mode. I see, that's quite possible. > However, just so I'm clear, are you sure that the private browsing context > is properly set for this pref service call if the user has enabled > "Permanent Private Browsing Mode" (browser.privatebrowsing.autostart)? IIRC, > we have noticed some differences between permanent and per-window behavior, > but I don't think we actually tested this particular case (since this patch > just sat in the tree, happily still applying). Right now the way that private browsing is implemented is by storing a boolean flag on each docshell object (which derives from nsILoadContext) to keep track of whether it's in private browsing mode or not. The permanent private browsing mode is implemented by basically setting the default value of that flag to true if the autostart pref is set. So, almost all of the code paths for per-window private browsing work the exact same way in permanent private browsing mode. And we took great care when porting the content prefs service to this new model (see bug 723002.) If you're aware of any cases where we fail to pass the correct load context, please file bugs. But I guess I can close this one out.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: