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

81–90 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#81

Post by 14 »

FragmentShader wrote: post #80

I think web browsers should implement already an API that allows developers to track any user in a "private" way, by generating a unique hash using your computer specs or something, and make it different for each website. So, if you visit Google, your hash would be something like "h38kflak". If you're visiting twitter, the API would generate something different, so you won't be tracked across websites. That way, even…

Because users do not want to be tracked or fingerprinted. I don't care about fraud detection and I am not a fraudster so why do I have to be tracked? There is no way that a feature like that would not get abused in one way or the other.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#82

Post by kmlx »

Thorrez wrote: post #68
dmazzoni wrote: post #35

Earlier quoted context omitted.

Yeah, it doesn't tell a website who you are. Instead, it allows them to recognize you again when you come back to visit again, even if you clear cookies. This is particularly a problem with big advertiser networks because they can track you across many sites you visit, even if you disable third-party cookies. It has positive uses too, like preventing click fraud and concert ticket arbitrage.

>Instead, it allows them to recognize you again when you come back to visit again, even if you clear cookies. I don't think that's what stockhorn said. stockhorn said it can only identify a what browser and OS and laptop model you're using. Someone else with the same browser, OS, and laptop model would have the same fingerprint. So audio fingerprinting couldn't precisely recognize you again when you come back again.

> Someone else with the same browser, OS, and laptop model would have the same fingerprint.

the collision rate of their ids is stated to be 0.05%

what they do is basically collect a lot of signals from the browser (audio processing stuff being only a part of it) and then compute an id on the server.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#83

Post by nox101 »

omnicognate wrote: post #50
nox101 wrote: post #39

Earlier quoted context omitted.

https://wavacity.com/ ?

Audacity's an awesome piece of software that I've used many times. Never once have I thought "by golly this thing should be a website, and my web browser should be made to expose an audio graph API to every website I visit to that it can be so!"

I'm the opposite. I think website = sanboxed, native = pownage so whenever I can use a website version I often prefer it over a native app.

I use photopea all the time now. it's available on every machine, even machines I don't have permission to install software on

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#85

Post by kmlx »

balls187 wrote: post #2

Fingerprint states that this service is for fraud detection, but they are actively discussing how they are circumventing browser privacy protections. So as a user my preference not to be fingerprinted or tracked takes a back seat in the name of fraud detection? So we should allow police to wiretap in the name of crime prevention?

> So as a user my preference not to be fingerprinted or tracked takes a back seat in the name of fraud detection?

the issue is murky for certain use cases. take payments for example. fingerprinting is used at scale in that field, and for good measure. you want to be able to know the risk associated with a user (chargebacks, fraud, etc).

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#86

Post by meandmycode »

unglaublich wrote: post #46
nox101 wrote: post #44

Earlier quoted context omitted.

that wouldn't help. you already know the browser and os through easier means

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

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#87

Post by redbell »

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

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#89

Post by spookie »

Thorrez wrote: post #68
dmazzoni wrote: post #35

Earlier quoted context omitted.

Yeah, it doesn't tell a website who you are. Instead, it allows them to recognize you again when you come back to visit again, even if you clear cookies. This is particularly a problem with big advertiser networks because they can track you across many sites you visit, even if you disable third-party cookies. It has positive uses too, like preventing click fraud and concert ticket arbitrage.

>Instead, it allows them to recognize you again when you come back to visit again, even if you clear cookies. I don't think that's what stockhorn said. stockhorn said it can only identify a what browser and OS and laptop model you're using. Someone else with the same browser, OS, and laptop model would have the same fingerprint. So audio fingerprinting couldn't precisely recognize you again when you come back again.

Still, parent does state a pretty big concern when looking at this from a higher vantage point.

These practices and their repercussions aren't self contained.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#90

Post by spookie »

capitainenemo wrote: post #18
modeless wrote: post #7

Putting a node graph audio API in the browser was silly. It should have been just audio worklets.

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

Did people want lower latencies though? It seems a bit absurd given other compounding factors that have a play on that.
Post reply on HN