[tor-bugs] #19417 [Applications/Tor Browser]: asm.js files should not be cached to disk in Tor Browser and no linkability risk

[Tor Bug Tracker & Wiki]

#19417: asm.js files should not be cached to disk in Tor Browser and no linkability
risk
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
     Type:  defect                               |  team
 Priority:  High                                 |         Status:
Component:  Applications/Tor Browser             |  assigned
 Severity:  Major                                |      Milestone:
 Keywords:  tbb-disk-leak, tbb-linkability,      |        Version:
  GeorgKoppen201606, TorBrowserTeam201606        |     Resolution:
Parent ID:                                       |  Actual Points:
 Reviewer:                                       |         Points:
                                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by gk):

 Replying to [comment:12 mcs]:
 > Replying to [comment:11 gk]:
 > > After thinking about it more it seems to me there is the additional
 risk that this mechanism could be used to embed supercookies. Like,
 deliver JS to a user that contains an identifier -> get that into the
 asmjscache -> once this is loaded anywhere ping the identifier back.
 > >
 > > Looking at https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-
 compilation-and-startup-performance/ does not rule that scenario out:
 > > {{{
 > > The cache entry is keyed on: the origin of the script, the source
 characters of the asm.js module, the type of CPU and its features, the
 Firefox build-id (which changes on every major or minor release).
 > > }}}
 > > Note this would be especially problematic for Tor Browser users as we
 are currently not changing the build-id.
 > >
 > > Not sure what "the origin of the script" means but I doubt "URL bar
 domain". It could mean as well that the asmjs cache is not caring about
 starting SOP either.
 >
 > They do use principals in the asmjscache code, so maybe there is some
 protection (not enough for us though).
 >
 > Are you now thinking that we should unconditionally disable the
 asmjscache?

 Well, doing so with `javascript.options.parallel_parsing` set to `false`
 does not work at least. :) What to do depends on how serious the issue is.
 If there are no linkability issues then making it just obey PBM is fine
 with me. If it can get used to track users across sites then we might want
 to disable it first and then enable it successively as soon as this is
 fixed.

 I actually tried to find proper sites that could be loaded in an iframe
 AND would exhibit asmjscaching but I failed so far. Seeing what is
 happening on the user's disk in this case might actually be revealing. Who
 knows what "origin if the script" boils down to given that nobody was
 caring about user privacy much in this case anyway.

 > I spent a little time trying to figure out how to cleanly disable the
 cache when in private browsing mode (I was hoping progress would be
 reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1047105 but that
 has not happened so far).
 >
 > For web workers, it might work to avoid calling JS::SetAsmJSCacheOps()
 inside dom/workers/RuntimeService.cpp when in private browsing mode.
 >
 > For content windows, I think we could make changes inside
 dom/base/nsJSEnvironment.cpp to ensure that AsmJSCacheOpenEntryForRead()
 and AsmJSCacheOpenEntryForWrite() do nothing when operating inside a
 private browsing mode window.

 Seems to be worth a try to me.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19417#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online