Opened 4 years ago

Closed 4 years ago

#8987 closed defect (fixed)

OS X Saved Application State contains some TBB website window titles

Reported by: runa Owned by: erinn
Priority: High Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: tbb-disk-leak, MikePerry201306
Cc: runa Actual Points: 0.5
Parent ID: Points:
Reviewer: Sponsor:


A forensic analysis of the Tor Browser Bundle (version 2.3.25-6, 64-bit) on OS X 10.8 showed that the Saved Application State files contain traces of the Tor Browser Bundle.

Resume is one of the new features in OS X 10.7 and 10.8. The feature allows applications to save their last known state when they are closed, and then return to this state when they are later reopened.

While the Tor Browser does not use this feature, it does leak information in the files which are written to the /Users/runa/Library/Saved Application State/ directory:

  • /Users/runa/Library/Saved Application State/org.mozilla.torbrowser.savedState/
  • /Users/runa/Library/Saved Application State/org.mozilla.torbrowser.savedState/
  • /Users/runa/Library/Saved Application State/org.mozilla.torbrowser.savedState/windows.plist

The windows.plist file contains the HTML title tag of the last active tab in the Tor Browser (or currently active tab, if the browser is still open). If the last active tab was, then the following string will be present in the file:

  • <string>Tor Project: Anonymity Online</string>

Child Tickets

Change History (11)

comment:1 Changed 4 years ago by mikeperry

Priority: normalmajor
Summary: OS X Saved Application State files contain traces of the Tor Browser BundleOS X Saved Application State contains some TBB website window titles

Runa: In general, if you find any direct reproducible disk leaks that leak browsing history, those should be bumped to major or higher.

The one exception is swap files, but perhaps even in that case TBB could recommend using swap encryption or disabling swap.

comment:2 Changed 4 years ago by naif

I reported this issue on #8825

comment:3 Changed 4 years ago by mikeperry

Does the latest Mozilla Firefox still leak the window titles in the same way in its Private Browsing Mode? How about Google Chrome's Incognito Windows? Safari?

Bringing this to the attention of an org that Apple might actually listen to will probably get this fixed faster. We likely need a special Apple API to opt out of this (and maybe that API already exists and is used by one of those browsers).

Otherwise without some muscle and an API, there's likely little we can do here.

comment:4 Changed 4 years ago by runa

Google Chrome (version 27.0.1453.93) does not leak the window titles in private or non-private browsing mode. Safari (version 6.0.4 (8536.29.13)) does not leak the window title in private browsing mode. I can not seem to find a savedState directory for Firefox (version 16.0.2) in /Users/runa/Library/Saved Application State/.

comment:5 Changed 4 years ago by mikeperry

Runa: Thanks.

Can you/naif/others try this Firefox release when you get a chance: It is closest to what we use.

(My 10.6 mac does not have a Saved Application State dir).

comment:6 Changed 4 years ago by freshwaterstrawberry

One possible API to use is on every new NSWindow, call [NSWindow setRestorable:NO] (

This does leave some traces in the org.mozilla.torbrowser.savedState directory, which consists of state for the menu bar and the application itself. I do not believe it discloses browsing history:


<key>MenuBar AvailableSpace</key>
<key>MenuBar FilterInfo</key>






I could not figure out how to get rid of that state using any Apple API, documented or undocumented (as of 10.8.3). It appears to be only possible using some hacks like method swizzling.

comment:7 Changed 4 years ago by freshwaterstrawberry

Sorry for the quick updates, but I decided to try out

As runa noted, it does not have any directory in Saved Application State whatsoever. Investigating, I found that Apple in AppKit specifically blacklists certain application versions from having persistence enabled, hilariously. Specifically, it checks (among other applications), that _CFAppVersionCheckLessThan(CFSTR("org.mozilla.firefox"), -1.0) is true. If this occurs, [NSPersistentUIManager sharedManager], which is the class that many other classes call into to save their states, actually returns nil. I didn't check for this earlier as I've never seen a feature disabled in such a fashion before.

However, reading that function, I've discovered a much cleaner and easier, albeit undocumented way, to entirely turn off any traces of the org.mozilla.torbrowser.savedState directory (as is the case for Firefox).

Merely add <key>NSDisablePersistence</key><true/> to /Applications/ is sufficient to trigger this behavior.

comment:8 Changed 4 years ago by mikeperry

Keywords: MikePerry201306 added

comment:9 Changed 4 years ago by mikeperry

Actual Points: 0.5
Resolution: fixed
Status: newclosed

I set the plist value mentioned by freshwaterstrawberry (thanks a lot!) in 3.0a2.

Can someone with OSX 10.7+ confirm the 'Saved Application State' is no longer written to by 3.0a2 (and if it still is, reopen this ticket)?

comment:10 Changed 4 years ago by runa

Resolution: fixed
Status: closedreopened

I downloaded 3.0a2 and the 'Saved Application State' is *still* written to by TBB.

comment:11 Changed 4 years ago by runa

Resolution: fixed
Status: reopenedclosed

Actually, I take that back. It seems 3.0a2 fixes the issue.

Note: See TracTickets for help on using tickets.