Hacker News Reader

Comment by h4x0rr | Hacker News Reader

Can anyone explain why the results are different to begin with? E.g. why is this audio fingerprinting even possible in the first place?

View on HN

The essence seems to be that the web audio API has a lot of algorithms that do a lot of math, and every browser has a slightly different implementation, and the exact results depend on the operating system and cpu too. So if you use the web audio API to generate a small signal all browsers will generate something that's really close, but the tiny differences can be used to help tell them apart.

that wouldn't help. you already know the browser and os through easier means

Like what? The voluntarily provided User-Agent? The browser is in control of that.

The browser in this adversarial scenario is also in control of the audio context too

Yet it is incredibly difficult to hide the underlying hardware or low level library differences. Not without slowing things down significantly.

Do you, as an end user, know how to change these settings compared to changing your user agent?

From the average user perspective those settings are equally impossible to change, as they neither know nor care that they even exist.

But why would it vary in ways that are consistent run to run on one machine, but not consistent with the same process executed on another similar machine?

Every datapoint reduces the number of people it could belong to. CPU + browser + browser version + OS + major OS version can narrow it down by a lot.

Then add resolution, IP address location (which VPN they use is also a datapoint), which time they are active at, etc. and you can get a good almost-unique identifier.

Maybe we should make the browser implementations consistent to the point they can't be told apart. Alternatively, we can reduce the precision of the results so that the tiny differences are deleted.

Browser vendors already copy the Audio API code from each other, you can see it in their public GitHub repositories. It doesn't help.

i think it comes from similar tricks that are played with webgl where there is a lot of entropy that comes from pc videocard drivers and the hardware itself.

it's a shame that browser people have to add noise to audio buffer handling to try and thwart it.

This was my first thought too, and they cover it in more detail here https://fingerprint.com/blog/audio-fingerprinting/#why-the-a...

TL;DR different codepaths even within the same codebase (e.g. SIMD variants) can result in subtly different floating point results (iiuc, likely related to to the fact that floating point math is unexpectedly sensitive to order of operations etc.)

Funny how when I posted more or less exactly this comment in another context recently a lot of people refused to take me seriously!

https://news.ycombinator.com/context?id=39633730

Floats are deterministic, though (if they weren't, this wouldn't be a workable fingerprinting vector). Reordering of operations (etc.) in a way that would actually change the results needs to be done by human edits, or with compiler options like ffast-math that explicitly allow the compiler to "break the rules" and make such changes. In either case, the concrete instructions emitted by the compiler will have deterministic behavior (and if they don't, that's a hardware bug)

What word would you use if sin(x) returns a different value on different platforms, or even different OS or librsry version? Sure smells like a fiction that depends on external state rather than simply its input.

The existence of platforms that do not conform to their own specifications does not make an operator non-deterministic.

Edit: I found this pretty great article on the subject https://randomascii.wordpress.com/2013/07/16/floating-point-...

We're both right, depending on how you frame the question.

sin(x) is platform-dependent.

Probably implementation details and compiler optimizations, float addition is not commutative for example. Implementing the same algorithm with the same formulas correctly can still lead to slightly different results

Floating point addition is not commutative, but it is still consistent. Getting different results is usually the result of using alternative algorithms or relaxing standards (that may, for example, reorder terms).

I don’t think the web spec implemented by the browser specifies the order of every operation, only the algorithm. If safari and chrome devs implement the audio api based on the spec, there can still be minor floating point differences because of the way they implemented the same calculations. That’s why they can fingerprint your browser versions with this.

I would have thought it might have yielded a machine and OS identifier - but more user specific than that?

That’s what it does, users on the same browser and same hardware should have identical fingerprints. It’s just one way of multiple to narrow down your fingerprint.

Thanks for the clarification - much appreciated

Reply on news.ycombinator.com