Live data from Hacker News

Bypassing Safari 17's advanced audio fingerprinting protection

fingerprint.com

101–110 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#102
post #94

Earlier quoted context omitted.

Wasn't Mozilla's proposed audio API simpler? AFAIK it was beaten out by Google's because people wanted a richer API and lower latencies. https://web.archive.org/web/20120505042746/https://developer...

IIRC it turned out that way in large part because realtime audio is very sensitive to performance hitches, and idiomatic JS is hitchy by nature due to relying on garbage collection, so they wanted to hoist as much as possible up into native code provided by the browser. If WASM had existed at the time it would have been easier to make the case for just exposing a simple raw audio interface instead.

Well... Mozilla had ASM.js at the time. In part to showcase their superior performance with certain portions of JS compared to V8 - at the time I remember the things like console emulators preferring Mozilla's JS engine due to it offering more reliable performance than V8 on the tight loops and large switches. Mozilla was also demonstrating how their engine could offer comparable performance to Google NaCl in an image processing demo which was conceived to show how NaCL could cover limitations in V8 at the time.

I wonder if we might well have had more traction with Mozilla's approach and ASM.js if V8 had had similar features.

Oh well. Is what it is, and Mozilla (and Microsoft and Apple) did at least manage to get WASM which has been super useful even outside of browsers.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#103

Earlier quoted context omitted.

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.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#105
I feel like these days (especially given the recent focus on side channel attacks) it is basically a given that adding uniform noise to something that leaks data does not work, because you can always take more samples and remove the noise. Why did Safari add this? I understand that needing more samples is definitely an annoyance to fingerprinting efforts, but as this post shows it's basically always surmountable in some form or the other.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#106
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

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

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#107

But all iPhones of the same model have the same processor. Every iPhone 15 Pro Max, of which Apple sells hundreds of millions, all have the same processor. Why do they have different results?

They have different performance at different heat and battery levels.

(This would of course require a different technique to uncover.)

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#109

Earlier quoted context omitted.

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

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

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#110
post #87

Another interesting technique to fingerprint users online is called GPU Fingerprinting [1] (2022). Codenamed 'DrawnApart', the technique relies on WebGL to count the number and speed of the execution units in the GPU, measure the time needed to complete vertex renders, handle stall functions, and more stuff ________________ 1. https://www.bleepingcomputer.com/news/security/researchers-u...

browsers should come with a default software renderer, and behave like the mic and camera where the site will require user permission to release the hardware GPU render path.
Post reply on HN