[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #9308 [Firefox Patch Issues]: JavaScript's BrowserFeedWriter() leaks installation paths on OS X and Windows

#9308: JavaScript's BrowserFeedWriter() leaks installation paths on OS X and
Windows
-------------------------------------+-------------------------------------
     Reporter:  cypherpunks          |      Owner:  mikeperry
         Type:  defect               |     Status:  needs_review
     Priority:  critical             |  Milestone:
    Component:  Firefox Patch        |    Version:
  Issues                             |   Keywords:  tbb-fingerprinting,
   Resolution:                       |  tbb-easy, interview,
Actual Points:                       |  GeorgKoppen201404R
       Points:                       |  Parent ID:
-------------------------------------+-------------------------------------

Comment (by arthuredelstein):

 I've investigated the `precompile startup cache` mechanism a little more.
 I ran two builds, one with `precompile_cache.js` turned off, and one with
 it turned on.

 The zip file `TorBrowser.app/Contents/MacOS/browser/omni.ja` contains two
 extra directories, `jsloader` and `jssubloader` that are present only if
 `precompile_cache.js` has been run. Inside the directory
 `jsloader/resource/app/components/' are a number of .js files, which are
 (contrary to convention) binary files. These binary .js files are
 apparently compiled versions of JavaScript sources with the same name. One
 such compiled file is
 `omni.ja!jsloader/resource/app/components/FeedWriter.js`.

 If these compiled .js files are removed from `omni.ja`, then
 TorBrowser.app reverts to leaking the file location of an uncompiled
 version of FeedWriter.js as an absolute `file://` URI. Conversely, if we
 don't precompile the cache, but add a compiled version of `FeedWriter.js`
 to the same location in omni.ja, then TorBrowser.app displays the
 `resource://` URI that does not leak the install path.

 So one way to stop the leakage would be to take compiled versions of
 `FeedWriter.js` and similar files, and supplement the omni.ja file.
 Unfortunately, we need xpcshell to produce these compiled versions, and a
 linux-native xpcshell is not available in a cross-compiled version of the
 tor-browser.git. We could borrow the compiled .js files from the linux
 build, but then building the Mac or Windows build would require anyone
 building to run a full linux build, essentially doubling the build time. I
 don't see any other way to produce the compiled versions of
 `FeedWriter.js`, however.

 An alternative would be to try to re-write the `file://` URIs to
 `resource://` URIs in the thrown exceptions. A class,
 nsResProtocolHandler, stores a mapping from `resource://` URIs to
 `file://` URIs, so we might be able to add some code that reverses this
 mapping so that we can do the re-writing. Such a patch is perhaps not too
 likely to be adopted by Mozilla. On the other hand, since the two known
 bugs (`BrowserFeedWriter` and `sidebar.addSearchEngine`) are not present
 in ESR31, we could simply create a temporary patch that can be discarded
 when rebasing of TBB to ESR31 happens.

 Any advice on which alternative to choose? Thanks!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9308#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs