Re: [tor-bugs] #13017 [Applications/Tor Browser]: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

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

#13017: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:
     Type:  task                                 |  arthuredelstein
 Priority:  Very High                            |         Status:
Component:  Applications/Tor Browser             |  assigned
 Severity:  Critical                             |      Milestone:
 Keywords:  tbb-fingerprinting-os, tbb-easy,     |        Version:
  TorBrowserTeam201605                           |     Resolution:
Parent ID:                                       |  Actual Points:
 Reviewer:                                       |         Points:
                                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by arthuredelstein):

 I've done some investigation of the fingerprinting via the Web Audio API.
 As far as I can tell, the source code for the Web Audio audio processing
 alogrithms, in mozilla-central's dom/media/webaudio/ directory, is doing
 computations that run on the cpu/fpu only. That is, I don't see any
 evidence for acceleration of these algorithms on audio hardware, gpus, or
 other special platform-specific tricks.

 I also specifically examined the API calls used for fingerprinting in
 view-source:https://audiofingerprint.openwpm.com/, and tracked down their
 C/C++ implementations and the helper libraries they depend on (primarily
 Kiss FFT and libav/FFT) in the Firefox codebase . There's nothing I found
 that indicates OS- or hardware-specific algorithms.

 So that suggests to me that we shouldn't expect radically more
 fingerprinting than is already observed via the JS Math API (as we discuss
 in #13018). And, if we are able to find partial defenses for Math-based
 fingerprinting, such as bundling our own math libraries or setting certain
 compiler flags, then I would expect these would help to defend against Web
 Audio fingerprinting attacks as well.

 It is possible, however, that the Web Audio API provides an efficient way
 to sample the space of floating point arithmetic operations to find
 differences between platforms that would be difficult to find manually.
 It's also possible that extensive use of somewhat complex numerical
 algorithms in the Web Audio source code and helper libraries provide more
 possibilities for floating point discrepancies than can be observed in the
 relatively simple JS Math interface. So in that sense this API might be a
 little extra dangerous.

 The Web Audio API looks to me like something that would only have
 occasional legitimate uses. Most sites using audio do not need to do any
 sound processing on the fly. Many games need only to play sound samples,
 which can be done with <audio> elements and don't require Web Audio. Uses
 for Web Audio I can think of include 3D games or other immersive content,
 music sequencers or audio/video editing apps. So, because these are fairly
 unusual, I think one efficient defense would be to prompt the user before
 allowing content to instantiate an AudioContext object, very similar to
 how we prompt before HTML5 Canvas image extraction (#6253).

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