Live data from Hacker News

Bypassing Safari 17's advanced audio fingerprinting protection

fingerprint.com

131–140 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#131
post #127
post #28

Earlier quoted context omitted.

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)

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#132
post #126
post #110

Earlier quoted context omitted.

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.

Do you have any concept of how many gigawatts per day that would waste?

[deleted]

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#133
post #126
post #110

Earlier quoted context omitted.

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.

Do you have any concept of how many gigawatts per day that would waste?

I’m not following. Why would disabling the GPU use more power? If anything, I would think it would reduce power consumption.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#134
post #126

Earlier quoted context omitted.

Do you have any concept of how many gigawatts per day that would waste?

I’m not following. Why would disabling the GPU use more power? If anything, I would think it would reduce power consumption.

Hardware implantations of things like graphics routines can be hundreds of time more efficient than software implementations running on general purpose CPUs.

Try to decode mpeg video at HD resolution in software sometime.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

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

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

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#137
post #134

Earlier quoted context omitted.

I’m not following. Why would disabling the GPU use more power? If anything, I would think it would reduce power consumption.

Hardware implantations of things like graphics routines can be hundreds of time more efficient than software implementations running on general purpose CPUs. Try to decode mpeg video at HD resolution in software sometime.

surely, the user will be taught to enable the hardware for video if they start seeing stutter. Or the browser can prompt the user to switch to "high-end graphics" if it detects prolonged video decoding.

If a website that has no obvious case for using the GPU, but is instead using it to fingerprint, then the user won't experience any slow downs from a software renderer (as it is usually done relatively quickly).

If a website needs the GPU for their videos/graphics, but also incidentally wants to fingerprint you, you're shit out of luck in that case. But this is no worse than what we have current day.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

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

[deleted]

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#139
I really don’t see how this can come up with more than a few thousand unique combinations. Browser type x browser version x os version x accelerator version x … what else? That doesn’t seem like enough variation to create anything remotely unique. I don’t get it.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#140
post #113

Earlier quoted context omitted.

> Why did Safari add this? A lot of Apple's "privacy" features nowadays are marketing. It's privacy theater. What matters is whether they can tell a plausible story to the public, not whether is technically effective.

Is iCloud Private Relay theatre? 3rd party cookie blocking? What specific features do you allege exist just to mislead the general public?

[deleted]
Post reply on HN