FYI: Your browser can pick up ultrasonic signals you can't hear, and that sounds like a privacy nightmare to some
- Reference: 1588886661
- News link: https://www.theregister.co.uk/2020/05/07/web_audio_api_ultrasonic_leaks/
- Source link:
People can generally hear audio frequencies ranging from 20 Hz and 20,000 Hz, though individual hearing ranges vary. Audio frequencies below and above the threshold of human hearing are known as infrasound and ultrasound, respectively.
A few years ago, digital ad companies began using ultrasonic signals to [1]track people's interests across devices: if a TV advert, for example, emits a sneaky inaudible signal, a nearby smartphone could pick it up and pass it to an app, which updates the owner's ad-targeting profile with details of what they were watching and when. Now you know when someone's into cooking shows on the telly, or is a news junkie, or likes crime documentaries, and so on.
A [2]warning from America's trade watchdog, the FTC, in 2016 and research published the following year identifying [3]234 Android apps listening covertly for ultrasound beacons, helped discourage inaudible tracking.
Several of the companies called out for these privacy-invading practices, such as [4]SilverPush , have moved on to other sorts of services. But the ability to craft code that communicates silently with mobile devices through inaudible sound remains a possibility, both for native apps and web apps. Computer security researchers continue to find [5]novel ways to use inaudible audio for data exfiltration. And ultrasound is still used for legitimate operations – Google's Cast app, for example, relies on an [6]ultrasonic token when pairing with a nearby Chromecast.
Samuel Weiler, a web security engineer with MIT CSAIL and a member of the W3C's Privacy Interest Group (PING), recently [7]pushed to re-open a discussion about limiting the Web Audio API so that it cannot be used to generate or listen for ultrasonic signals without permission.
Your phone wakes up. Its assistant starts reading out your text messages. To everyone around. You panic. How? Ultrasonic waves [8]READ MORE
Weiler suggested that internet users might be explicitly prompted to enable Web Audio API usage to process sound that can't be heard. His concern is that undetectable audio transmissions could be used for device fingerprinting, for identifying when two different devices are in proximity of each other, and for violating context boundaries that prevent different apps on the same device from talking secretly to one another.
He also asked about masked sounds within the audible spectrum that might be abused for covert communication, though that's a separate technical challenge.
Weiler [9]raised the subject three weeks ago – one element in a larger debate about reducing the fingerprinting surface of the Web Audio API. And last week, the discussion thread was closed by Raymond Toy, a Google software engineer and co-chair of the W3C's Audio Working Group.
Toy argued that if a developer is allowed to use a specific audio sampling rate, no additional permission should be required – few users enjoy dealing with permission prompts, after all. And other web developers participating in the debate expressed concern that limiting available frequency ranges could introduce phase shifting or latency and that there's no sensible lower or upper threshold suitable for everyone.
In an email to The Register , Peter E. Snyder, privacy researcher at Brave software and co-chair of the PING, said he shared Weiler's concerns about the privacy implications of inaudible sound.
"[With regard] to Web Audio and super-audible sounds, we're concerned because audio beyond human perception can be used for a variety of privacy harming purposes," said Snyder. "Companies like SilverPush have commercialized such techniques, and others have documented them being used in the wild.
"Such techniques could also be used to do cross-domain tracking; sites could transmit super-audible sounds that other open pages could listen for, allowing for the kind of cross-site tracking Brave (and other privacy-focused browsers) try to protect users against."
On a related note, the [10]Brave browser [11]recently added a small amount of randomization to various Web Audio APIs to reduce their utility for browser fingerprinting.
Whether or not the Web Audio Working Group decides to revisit the possibility of audio frequency-based permissions, those involved will have their hands full dealing with all other other [12]unaddressed browser privacy worries . ®
Sponsored: [13]How to Build Your Digital Experience Portfolio
[1] https://www.theregister.co.uk/2015/11/20/silverpush_soundwave_ad_tracker/
[2] https://www.ftc.gov/news-events/press-releases/2016/03/ftc-issues-warning-letters-app-developers-using-silverpush-code
[3] http://christian.wressnegger.info/content/projects/sidechannels/2017-eurosp.pdf
[4] https://search.theregister.co.uk/?q=silverpush&site=
[5] https://www.theregister.co.uk/2020/05/04/power_supply_attack/
[6] https://developers.google.com/cast/docs/guest_mode
[7] https://lists.w3.org/Archives/Public/public-audio/2020AprJun/0025.html
[8] https://www.theregister.co.uk/2020/02/28/smartphone_ultrasonic_hack/
[9] https://github.com/WebAudio/web-audio-api/issues/2191
[10] https://brave.com/
[11] https://github.com/brave/brave-browser/issues/9187
[12] https://w3c.github.io/horizontal-issue-tracker/?repo=w3cping/tracking-issues
[13] https://go.theregister.co.uk/tl/1936/-8578/how-to-build-your-digital-experience-portfolio?td=wptl1936
Re: It's the microphone, not the browser
I found an advertising SDK inside a pre-installed Android app that could:
Determine the users location
Access and read anything the user had copied or pasted to the clipboard
Access and record with the devices microphone
Access the devices text-to-speech functions to both record and vocalize and also access any custom words the user added.
What was even more disturbing is that the advertising SDK was found inside an app that millions of people have installed thinking it would protect themselves from things like this.
Chinny reckon
And last week, the discussion thread was closed by Raymond Toy, a Google software engineer and co-chair of the W3C's Audio Working Group.
Toy argued that if a developer is allowed to use a specific audio sampling rate, no additional permission should be required – few users enjoy dealing with permission prompts, after all.
Isn't it more like there's no way to phrase the permission prompt that doesn't sound creepy?
Never good to have someone working for Google on the chair of something. They'll push all manner of nonsense through in the name of their employer.
The more devices you have that are controlled by a smaller pool of companies the less chance you have of privacy.
The likes of Brave are fighting the good fight (all be it hopeless) but when you look at what Nation states can do in secret, you have to ask what the likes of Google et al can do hidden in plain sight with the ability to influence and control OS and core APIs when they have no commercial interest in limiting the exposure of user information or privacy.
The US government seem toothless in the face of these US based but global companies that are now financially bigger than many countries GDP and have user bases that are vastly bigger than all countries, are we looking at a geographical country trying to limit the power and control of a virtual country? Who is your money on?
It's the microphone, not the browser
The microphone is doing the conversion of sound waves to electrical signals, not the browser. It would be best to limit the microphone in Android or iOS, not mess with a spec. While there isn't a snowflake's chance of building a ski slope in hell of it happening, it's a better chance than changing a spec or API.