[tor-bugs] #20214 [Applications/Tor Browser]: Ultrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

[Tor Bug Tracker & Wiki]

#20214: Ultrasound Cross Device Tracking techniques could be used to launch
deanonymization attacks against some users
--------------------------------------+----------------------------------
 Reporter:  VasiliosMavroudis         |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:  Tor: unspecified
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+----------------------------------

Comment (by VasiliosMavroudis):

 > Why wouldn't this work with audible sound? Audible sound ranges have
 been shown to be able to covertly issue voice commands to nearby mobile
 devices
 (​!https://www.georgetown.edu/sites/www/files/Hidden%20Voice%20Commands%20full%20paper.pdf).
 The core issue is not addressed by filtering out non-audible sound.



 It can absolutely work in the audible spectrum, and indeed there is one
 framework doing so already.

 However, our argument is not that ultrasounds are a plausible convert
 channel. Instead, we argue that the audio channel is already being used by
 frameworks embedded in apps, and that they are gaining traction in the
 market.

 Two examples of such frameworks:

 Inaudible: Silverpush
 (!http://www.forbes.com/sites/thomasbrewster/2015/11/16/silverpush-
 ultrasonic-tracking/#7b5f70824024)

 Audible: Intrasonics (http://www.intrasonics.com/technology-faqs/)


 > If a user is presented with a choice to play the media file or not and
 if they *believe* that they want to play it, they will play it. The prompt
 would only serve as an annoyance that the user would learn to ignore. If
 your attack involves tricking a user to visit a website, tricking a user
 to view or allow the media on the website to play would not be
 significantly more difficult.



 Absolutely. There are many possible ways to go about it. A prompt/popup
 comes with the advantage of actually educating the user, but indeed the
 user may get "blind" after a while. Same holds for all major browsers that
 use prompts to ask the user if access to a given resource should be
 permitted.

 > The security slider at 'High' already makes video/audio content click-
 to-play, with the current exception of !MediaSource video (see: !#19200).


 We totally agree with this choice. I'm not very familiar with the
 rationale behind each setting on the security slider. However, our
 suggestion would be to extend this feature to the low-default security
 setting (this may not be technically straightforward though, if you want
 to keep JS). Of course, from a usability perspective this is not very good
 for the user, but with such frameworks gaining traction it seems a
 reasonable reaction.

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