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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mikeperry, Unassigned)
Details
(Whiteboard: [tor])
Attachments
(1 file)
2.26 KB,
patch
|
Details | Diff | Splinter Review |
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.
Updated•12 years ago
|
Whiteboard: [tor]
Comment 1•12 years ago
|
||
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)
Reporter | ||
Comment 2•12 years ago
|
||
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)
Comment 3•12 years ago
|
||
(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.
Description
•