[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 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?

 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.

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