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

51–60 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#51

Post by shuckles »

jwells89 wrote: post #48
ninkendo wrote: post #43

Earlier quoted context omitted.

There’s a push to make every single last thing a normal application can do, available to web apps through some half-standardized JavaScript API or another. Generally google comes up with use cases, implements it in chrome, and tries to call it a standard. Then everyone complains when Apple doesn’t implement these standards fast enough, and that Safari is “holding back the web” or “the new IE” because it’s not keeping…

Things like this seem niche enough to safely put behind a permission dialog. 99.9% of sites/web apps have no legitimate need for this functionality.

Permissions dialogs solve for a problem product creators have and create more problems for users.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#52

Post by ninkendo »

jwells89 wrote: post #48
ninkendo wrote: post #43

Earlier quoted context omitted.

There’s a push to make every single last thing a normal application can do, available to web apps through some half-standardized JavaScript API or another. Generally google comes up with use cases, implements it in chrome, and tries to call it a standard. Then everyone complains when Apple doesn’t implement these standards fast enough, and that Safari is “holding back the web” or “the new IE” because it’s not keeping…

Things like this seem niche enough to safely put behind a permission dialog. 99.9% of sites/web apps have no legitimate need for this functionality.

That’s how location services and notifications work today, and all it means is that websites just constantly nag me to enable them.

Things like this make for a more annoying web all around, because now it’s just one more tool sites can use to track me and increase engagement. (Edit: sibling poster chuckles said it way better than I can.)

If I had my way, JavaScript on the web would be limited to XMLHttpRequest and basic DOM manipulation and couldn’t do anything else. A totally separate “rich” JavaScript engine could be opted into by the user for any website that presents itself as an “application” like ones that legitimately want audio API’s like these. All these half-baked web app “standards” that google is forcing down our throats can be confined to that leper colony.

Then the most important bit: browsers could let me completely disable the “rich” engine, and I can go back to having a sane web experience again.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#53

Post by rpdillon »

pdntspa wrote: post #29
echoangle wrote: post #26

Earlier quoted context omitted.

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.

It's about variations in the implementation of the digital pipeline that are traceable to the output. It has nothing to do with analog processing or interference.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#54

Post by mindslight »

jwells89 wrote: post #48
ninkendo wrote: post #43

Earlier quoted context omitted.

There’s a push to make every single last thing a normal application can do, available to web apps through some half-standardized JavaScript API or another. Generally google comes up with use cases, implements it in chrome, and tries to call it a standard. Then everyone complains when Apple doesn’t implement these standards fast enough, and that Safari is “holding back the web” or “the new IE” because it’s not keeping…

Things like this seem niche enough to safely put behind a permission dialog. 99.9% of sites/web apps have no legitimate need for this functionality.

When a surveillance company (in this case Google) is leading the push, security against surveillance isn't on their list of requirements. In fact it's more of an anti-requirement, which escapes human judgement via design by committee or other anti-scrutiny technique. So then we end up with yet another insecure API that we've got to suffer for years as the browser makers who actually care about security painstakingly figure out how to mitigate the vulnerabilities in the original standard.

And I'm all for focusing on technical security, but it's worth mentioning that the biggest most concentrated win would be making commercial digital surveillance illegal (ie the path the GDPR tries to head in). Imagine if large public companies had to make their revenue by honest means instead of working as advanced persistent threats.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#55

Post by latexr »

ninkendo wrote: post #52
jwells89 wrote: post #48

Earlier quoted context omitted.

Things like this seem niche enough to safely put behind a permission dialog. 99.9% of sites/web apps have no legitimate need for this functionality.

That’s how location services and notifications work today, and all it means is that websites just constantly nag me to enable them. Things like this make for a more annoying web all around, because now it’s just one more tool sites can use to track me and increase engagement. (Edit: sibling poster chuckles said it way better than I can.) If I had my way, JavaScript on the web would be limited to XMLHttpRequest and ba…

> That’s how location services and notifications work today, and all it means is that websites just constantly nag me to enable them.

It also means you can tell the browser to outright deny every request, thus avoiding even getting prompted. If a website detects the request was denied and still prompts you any other way, that’s an undeniable signal to close the tab and never return.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#56

Post by a-dub »

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?

i think it comes from similar tricks that are played with webgl where there is a lot of entropy that comes from pc videocard drivers and the hardware itself.

it's a shame that browser people have to add noise to audio buffer handling to try and thwart it.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#57

Post by austinpena »

neilv wrote: post #45

> Fingerprinting is used to identify bad actors when they want to remain anonymous. For example, when they want to sign in to your account or use stolen credit card credentials. Fingerprinting can identify repeat bad actors, allowing you to prevent them from committing fraud. However, many people see it as a privacy violation and therefore don’t like it. This doesn't seem to acknowledge the use of fingerprinting in i…

Their tool is priced too expensive to be used for marketing purposes in most cases.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#59

Post by jwells89 »

ninkendo wrote: post #52
jwells89 wrote: post #48

Earlier quoted context omitted.

Things like this seem niche enough to safely put behind a permission dialog. 99.9% of sites/web apps have no legitimate need for this functionality.

That’s how location services and notifications work today, and all it means is that websites just constantly nag me to enable them. Things like this make for a more annoying web all around, because now it’s just one more tool sites can use to track me and increase engagement. (Edit: sibling poster chuckles said it way better than I can.) If I had my way, JavaScript on the web would be limited to XMLHttpRequest and ba…

I’m kinda surprised that no fork of Firefox has added both global and domain-scoped toggles for web feature support. I know there’s flags in about:config but that only covers some things and isn’t very user friendly.

That’d let users turn support for all the fancy bits off by default and enable them in the tiny handful of cases that they’re actually desired. This way as far as sites are concerned your browser simply doesn’t support those features and thus can’t nag you.

Post reply on HN