Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing Safari 17's advanced audio fingerprinting protection

fingerprint.com

Post reply on HN
Print view View original

21–30 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#22

Post by Crespyl »

fbdab103 wrote: post #17
stockhorn wrote: post #14

Did I read this correctly and audio fingerprinting is mainly about identifiying the used browser version and OS or laptop, but it cant identify end-users in a stable way?

I think that is correct, but it still seems like an amount of leakage that could be further correlated with other another trick. There was previously a site which could indicate how globally unique your environment was (some combination of screen size, user-agent, fonts?, etc). Locking down to a specific hardware+browser configuration probably does a lot to remove anonymity.

You may be thinking of https://www.amiunique.org/fingerprint

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#26

Post by echoangle »

pdntspa wrote: post #19
marcellus23 wrote: post #15

Earlier quoted context omitted.

This has nothing to do with the microphone...

Then where are these audio samples coming from?

This is using differences in the audio processing pipeline of the browser, they just use some input sound which could be taken from a file. The fingerprint is the slightly different output signal when applying filters to the input signal.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#27

Post by echoangle »

h4x0rr wrote: post #11

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

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

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#28

Post by Retr0id »

h4x0rr wrote: post #11

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

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.)

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#29

Post by pdntspa »

echoangle wrote: post #26
pdntspa wrote: post #19

Earlier quoted context omitted.

Then where are these audio samples coming from?

This is using differences in the audio processing pipeline of the browser, they just use some input sound which could be taken from a file. The fingerprint is the slightly different output signal when applying filters to the input signal.

How is it possible that this produces enough variations to be usable without sampling some sort of audio source? The entire pipeline is digital, there is not any room for interference.
Post reply on HN