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

161–170 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#161

Post by actualwitch »

sph wrote: post #150
spookie wrote: post #88

These predatory practices are getting out of hand. Props for them to expose this, even though they're the "bad actors" from my point of view.

They're not exposing anything, they're advertising their services. It was also posted by one of their employees. Funny how no one seems to notice that, and they're all praising the article.

"Funniest" part is that this page also tries to establish a webrtc connection which i know because my firewall told me browser tried to connect via nat-stun port to some server. Webrtc is a common way to fingerprint vpn users because in some setups it leaks your real ip.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#162

Post by simondotau »

Borealid wrote: post #73
sshumaker wrote: post #70

It seems like rather than adding a random amount to each sample (which lets them compute a mean by recreating the same audio and extracting out the differences), Safari could instead add randomness that is based on a key that rotates every hour. (Function of audio sample and key, so the noise would be the same in a given session, but useless for tracking an hour later).

If you averaged together ten such samples, you'd get something that approaches the true values from the device. The more samples you have, the closer it would get. Fixing this would require removing the information leak entirely, not just masking it under a layer of random deviations.

The grandparent post accounted for exactly that criticism. By having the source of randomness fixed for a limited time period, a fingerprinting algorithm wouldn't be able to gather enough unique samples for averaging to be useful. And given the extremely fine differences in the floating point numbers, any injected noise would so overwhelm the data that you'd need hundreds, perhaps thousands of samples in order for averaging to be useful.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#163

Post by pietro72ohboy »

TylerE wrote: post #141
chii wrote: post #137

Earlier quoted context omitted.

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…

Oh expect users to understand this? The same people who have spent the past 40 years getting confused and worked up about cookies?

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

It would still be way less than what large companies are burning on training proprietary LLMs. Do you think the ChatGPT model you use daily was the success at first go? And in that same world, consumers should not even try to protect themselves from GPU fingerprinting?

> The same people who have spent the past 40 years getting confused and worked up about cookies?

Stop with the condescension. It's not about being confused; it's about mitigating genuine privacy concerns. We're not idiots, and dismissing genuine worries won't make the issues disappear.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#165

Post by pillusmany »

jancsika wrote: post #96

Someone definitely correct me if I'm wrong, but the success of the fingerprinting workarounds here seem to boil down to the following choice wrt handling oscillator anti-aliasing in the Web Audio API spec: "There are several practical approaches that an implementation may take to avoid this aliasing. Regardless of approach, the idealized discrete-time digital audio signal is well defined mathematically. The trade-off…

Quality anti-aliasing is expensive.

So you want to allow the implementation to decide how much to spend on it depending on available compute, battery and so on.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#166

Post by matheusmoreira »

sweetjuly wrote: post #147
chii wrote: 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.

but nobody wants to use software rendering, that's the whole reason WebGL and WebGPU exist.

They should have thought of that before abusing these things to fingerprint us. Use of the GPU is a privilege and it can be revoked.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#167

Post by Etheryte »

Faaak wrote: post #145
avoid3d wrote: post #129

Earlier quoted context omitted.

Very pedantic but I’d want to know. A watt is a unit of power, which means gigawatts per day is a rate of change of power. If you want a unit of energy you need power multiplied by time not divided, so “gigawatt days” not “gigawatts per day”.

Maybe they meant "gigawatt-hours per day"

Gigawatt hours per day is just gigawatt hours per 24 hours, so just gigawatts but divided.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#168

Post by matheusmoreira »

dmazzoni wrote: post #33
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?

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.

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.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#169

Post by matheusmoreira »

IceHegel wrote: post #158
chrisbrandow wrote: post #100

This is gross.

It raises the question of whether the current networking stack is the one we want to have for the next 100 years. The internet in its current form has ruined a lot of the dream of personal computing because companies (and the state) are so asymmetrically powerful versus individuals. Should it be possible for my technology to send data to a server without my explicit approval?

> Should it be possible for my technology to send data to a server without my explicit approval?

Of course not. We should be able to intercept every request, filter them, even modify them to send fake data instead if we wish it.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#170

Post by pcdoodle »

dannyw wrote: post #119
spookie wrote: post #97

Earlier quoted context omitted.

You can sandbox native apps too. Hell, even run them in an airgapped virtual machine. I wouldn't trust a browser sandbox all that much given the high interest in subverting it.

What’s an easy way to sandbox apps on Windows? Sorry, I’d prefer to stick with my operating system, not install QubesOS.

sandboxie was neat last time i tried it.
Post reply on HN