4 ms·

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

by h4x0rr 3y ago

echoangle 3y ago
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
- saagarjha 3y ago
  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).
  - echoangle 3y ago
    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.
- Angostura 3y ago
  I would have thought it might have yielded a machine and OS identifier - but more user specific than that?
  - echoangle 3y ago
    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.
    - Angostura 3y ago
      Thanks for the clarification - much appreciated
- deleted 3y ago
  [deleted]
Retr0id 3y ago
This was my first thought too, and they cover it in more detail here https://fingerprint.com/blog/audio-fingerprinting/#why-the-audio-fingerprint-varies-by-browser 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.)
- TylerE 3y ago
  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 https://news.ycombinator.com/context?id=39633730
  - Retr0id 3y ago
    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)
    - TylerE 3y ago
      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.
      - Retr0id 3y ago
        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-determinism/ https://randomascii.wordpress.com/2013/07/16/floating-point-... We're both right, depending on how you frame the question.
dmazzoni 3y ago
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.
- nox101 3y ago
  that wouldn't help. you already know the browser and os through easier means
  - unglaublich 3y ago
    Like what? The voluntarily provided User-Agent? The browser is in control of that.
    - meandmycode 3y ago
      The browser in this adversarial scenario is also in control of the audio context too
      - bdd8f1df777b 3y ago
        Yet it is incredibly difficult to hide the underlying hardware or low level library differences. Not without slowing things down significantly.
      - hiatus 3y ago
        Do you, as an end user, know how to change these settings compared to changing your user agent?
        c0pium 3y ago
        From the average user perspective those settings are equally impossible to change, as they neither know nor care that they even exist.
a-dub 3y ago
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.

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

by h4x0rr 3y ago

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

echoangle 3y ago

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

saagarjha 3y ago
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).
- echoangle 3y ago
  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.
Angostura 3y ago
I would have thought it might have yielded a machine and OS identifier - but more user specific than that?
- echoangle 3y ago
  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.
  - Angostura 3y ago
    Thanks for the clarification - much appreciated
deleted 3y ago
[deleted]

Retr0id 3y ago

This was my first thought too, and they cover it in more detail here https://fingerprint.com/blog/audio-fingerprinting/#why-the-audio-fingerprint-varies-by-browser 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.)

TylerE 3y ago
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 https://news.ycombinator.com/context?id=39633730
- Retr0id 3y ago
  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)
  - TylerE 3y ago
    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.
    - Retr0id 3y ago
      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-determinism/ https://randomascii.wordpress.com/2013/07/16/floating-point-... We're both right, depending on how you frame the question.

dmazzoni 3y ago

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.

nox101 3y ago
that wouldn't help. you already know the browser and os through easier means
- unglaublich 3y ago
  Like what? The voluntarily provided User-Agent? The browser is in control of that.
  - meandmycode 3y ago
    The browser in this adversarial scenario is also in control of the audio context too
    - bdd8f1df777b 3y ago
      Yet it is incredibly difficult to hide the underlying hardware or low level library differences. Not without slowing things down significantly.
    - hiatus 3y ago
      Do you, as an end user, know how to change these settings compared to changing your user agent?
      - c0pium 3y ago
        From the average user perspective those settings are equally impossible to change, as they neither know nor care that they even exist.

a-dub 3y ago

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.