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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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

Comment (by arthuredelstein):

 Replying to [comment:26 gk]:

 > And what happens if we don't precompile the cache but add an
 *uncompiled* version to resource/app/components? If the Tor Browser is not
 complaining then we probably have the easiest solution to our problem.


 I tried that. It doesn't complain, but it still leaks the install path. TB
 must not be recognizing an uncompiled version in that location as valid,
 and falling back on the uncompiled version stored in another location.

 > What about Mike's idea of doing a python stub that is doing the pre-
 compilation?

 Maybe I'm not understanding this suggestion. I don't see how python can
 compile JavaScript, unless we write our own JS compiler ;). I'm not an
 expert on this startup cache, but from my googlings, it seems these files
 are SpiderMonkey-compatible bytecode.

 > And what about compiling those .js files once and ship them as resources
 via the gitian versions files?

 Yes, I think that absolutely can work, but don't we then need a way to
 verify the integrity of those binary files on the build machine? Is there
 currently a mechanism for doing that? Would checking the binaries into
 tor-browser.git or tor-brower-bundle.git and relying on git's hashing
 strategy be acceptable?

 > > 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.
 >
 > Sounds complicated but if it works why not (I have not looked at the
 code to estimate how large that patch would have to be, so it might
 instead be quite easy to provide one). BTW: Are we sure there are no other
 components exposed to the website that could cause similar issues?

 This approach would cover exceptions thrown through a similar code path,
 but not necessarily other unknown path leaks. I'm not sure how tricky it
 is yet...

 > Given that this is obsolete with ESR 31 choosing the fastest way to
 solve this ticket seems to be a good approach. :)

 I agree wholeheartedly! :P

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9308#comment:28>
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