1. How consistent the output is on a given device (is it 100% deterministic and will always produce the same fingerprint?)
2. How big is the variance across devices (how good of a fingerprint it is).
The article doesn't really do much at digging into that, which really is the most important thing if you want to use it as a fingerprint.
I'm not quite sure why different devices would generate different output, other than differences in floating point computation.
https://developer.mozilla.org/en-US/docs/Web/API/AudioContex...
Everything is different for every version of firmware, hardware, driver revision, etc. it’s like enumerating fonts, it combined with other fingerprinting techniques provides a very unique snapshot of you.
Eff’s panapticlick provides an audio fingerprinting example. There exist plugins which will provide some entropy to your fingerprint which also changes over time. That helps a little, but any changes you make really makes you stick out like a sore thumb (your audioprofile becomes even more unique)
As a major side benefit, websites will stop randomly playing audio without permission.
In other words, make it more declarative and less verbose.
The browser could always increase the apparent audio latency by buffering, but that reduces the ability of music apps to perform well.
Move responsibility for the syncing to the browser and then the app doesn't need to know anything. In short, I can put it together and send it to you, or I can send you the bits and tell you how they should be put together.
A graphics frame appears on the screen at a specific time. (For VR, it is a definite time, and this is critical. For normal video or games, a little bit of slop, maybe a few ms, is probably okay.)
For audio, humans are sensitive to 10 ms deviations or even less.
Any API that works decently will need to synchronize audio and video, so there needs to be a way for a program to say “this audio sample should play are the same time as this video frame is shown”. But an API should also allow programs to react as quickly as possible to user input. And Bluetooth headphones, in particular, have very, very high latency.
So designing an API that performs well without revealing the latency is hard.
I do think it would be good to cleanly separate normal web pages and games, though. For pure content, none of this matters except that video needs to maintain synchronization. But normal content does not need clicks to translate quickly to video changes.
The browser is the presentation layer, it needs to know the latency of your headphones (or the system does). Why does the content provider need it? What's wrong with "here is frame A, please play audio A at the same time (while taking into account the latency that only you know about)" as a request?
That's ok. Then I have the option to weigh whether the risk is worth it or rather not. 9 out of 10 times it is not, in rare cases I will allow the js to execute.
How do you explain to one of these "I'm not good with computers haha" types what a CDN is and why Taboola CDN shouldn't be allowed but Akamai should be otherwise things Won't Work Right. Even if they're capable of learning [1] why should they care, when all these security measures actively make their life harder?
Blocking audio and other fingerprintable surfaces by default, with a "click here to enable audio / video" and a "remember my choice on this site in future" is the only way it can possibly work, because 99% of users will only ever go for the laziest option. We need to have protections for them that work regardless of (or in spite of) their skill level.
But hey some of us still run around with MS-DOS 5.22 on that new Spectre-ridden, rowhammer-ready i7 because DOS/4GW is hella stable.
True if we stopped thinking at 1996. I don't know how to tell you but browsers become application platforms not document delivery vehicles in the last 20 years.
This is a pain - on the one hand, the browser vendors and w3c are locking down API capabilities to prevent fingerprinting and timing based security hacks, but these are interfering with genuine needs to provide audio functionality. For example, you can't determine whether the user has 3 audio devices connected and prompt them to select one for output. So you really can't build desktop quality audio systems with webaudio and siblings.
I really hate the user-action restriction as a security measure, because it's ridiculously easy to bypass[0], particularly on Chrome. It's privacy theater -- annoying for legitimate developers, but easy for malicious actors to get around.
Putting this stuff behind a permission or sandboxing it somehow would be better for both end-users and developers. As it stands, we just get fewer webaudio applications online from legitimate developers, and they all move to native platforms where it's even easier to fingerprint users. And the malicious sites that don't move to native just fingerprint anyway because we're using bad, opaque metrics for consent.
Frankly, this really should be handled by the browser. JavaScript really shouldn't have any business messing with that.
will give you that list, allowing you to have a menu for a user to choose one and then the client code must use setSinkId to assign the chosen device id. https://developer.mozilla.org/en-US/docs
I never knew the device ids were randomized like that, thanks for the info.
“This process doesn't require access to the device permissions like microphone or speakers. No audio is recorded, collected or played by any means. It gathers the audio signature of a user's device and uses it to create an identifier to track that user. It simply relies on the difference in the way these generated signals are processed on each device.”