Live data from Hacker News

Bypassing Safari 17's advanced audio fingerprinting protection

fingerprint.com

231–240 of 266 posts

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#231

Earlier quoted context omitted.

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.

I sometimes unironically say that JavaScript is a privilege that should only be granted to websites that actually need it. Most of the web is text and images. No Turing-complete client-side runtime environment is required to display that. But I would also accept all those multimedia APIs (canvas, WebGL, WebGPU, everything audio and video, including the tag ) and some others (e.g. service workers and everything else a…

You have noscript to block all that but it breaks the most simple sites these days. Part of it is legitimate like responsive design (though most can be done with css these days).

But most of it is bullshit tracking, anti-scraping and similar stuff.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#232
post #225
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.

What's the point? The capabilities of browsers are so vast they'll just find other ways to fingerprint. Privacy in browsers is a lost cause. It's a 30+ year old technology that has become ridiculously bloated in scope, with privacy and security only considered as an afterthought.

It's still possible to thwart it by random data into the fingerprint. Browsers should be capable of doing that without plugins ideally.

A bit like Ad Nauseam that loads ads in an invisible sandbox and clicks on all of them to mess up their reporting.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#233
post #128

I'm really ready to just be "that guy" that browses with JS disabled.

The problem is that that by being "that guy" you're probably giving them 10 bits or more of identification. If they can just scrape a few more bits from somewhere they'll have you uniquely identified. But, yeah, these guys can get on Golgafrinchan Ark B with the rest of the adtech industry as far as I am concerned.

I need to be more offline then.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#234

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.

Combinatorics is a harsh mistress

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#235
post #185

Earlier quoted context omitted.

there isn't a 'they' and an 'us' in this situation

"They" refers to web developers. "Us" refers to users. We are the owners of the machines where their code will run. They have complete freedom on their servers. On my computer, I make the rules. They are lucky if I allow their code to run at all.

this is of course the ideal, but it is somewhat not to the point; as vidar says, the 'they' who are fingerprinting you have only a limited intersection with the 'they' who are doing awesome things with webgl like shadertoy or https://mitxela.com/projects/model-viewer, which doesn't even have google analytics

a somewhat bigger problem is that to a very significant extent the actual owners of the machines are microsoft, google, and apple, not the users; they make the rules, and the users are lucky if the owners allow their code to run at all. under those circumstances, blocking fingerprinting is practically quite difficult, because the 'they' who want to fingerprint you and the 'they' who make the rules about what code run on your machine are the same people, not two opposing groups

an additional problem is that an increasing part of the web is run by criminal elements like harvey weinstein and the rest of the mpaa, who will block you if they can detect you attempting to protect your privacy from them by blocking fingerprinting, even if apple decides it would be a good idea; cloudflare and google are perhaps the most prominent enforcers here, perhaps somewhat reluctantly

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#236
post #123
post #118

I look forward to the day the EU makes fingerprinting illegal.

Defining fingerprinting in a legal terms is fairly difficult. Most regulators would also likely consider fingerprinting for certain use cases as acceptable. E.g., detecting abuse, fraud, CP, etc.

How is that difficult? Anything that is stored to recognise a user on two different devices/sites is fingerprinting.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#237
post #83

Earlier quoted context omitted.

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

A "sandbox" that can freely send anything it wants to any computer connected to the internet

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#238
post #221

Earlier quoted context omitted.

> Your logic is that any flaw in an implementation renders it useless. I didn't say that. It's a straw man.

You said that iCPR is privacy theatre because of a resolved security bug from 2 years ago. Please spell out the implication of that claim for me then.

> Please spell out the implication of that claim for me then.

I'll spell out my views below, but I want to start by noting that I don't agree with the way you've characterized them. Going all the way back to your initial reply, I don't like the way this leading question was phrased:

> What specific features do you allege exist just to mislead the general public?

I think Hanlon's razor is a false dilemma. With a big company like Apple, there's typically a combination of bureaucratic incompetence and marketing exaggeration. Clearly, Apple leadership has decided to make privacy a consumer differentiator for their products, so they have a financial incentive to hype privacy features as much as possible. As a consequence, Apple management would be eager to be pitched any and all privacy features from engineering; these may even lead to bonuses and promotions, though that's purely speculation on my part. Regardless of the personal motivations of employees, the company is pursuing privacy features in earnest and isn't intending for them to be fake. Nonetheless, the company also has the unfortunate habit of shipping half-baked features and implementations. This is driven largely by the artificial, forced march of the annual release schedule, which demands that great new features be continually announced at a certain time, whether they're ready or not. The situation is not unique to privacy features either; Apple's entire software product line is suffering in quality. Engineering simply doesn't have enough time to do things right, which results in new features that are superficial and/or flawed. You could say it's marketing-driven incompetence.

Several commenters have mentioned that all software has bugs, as if that were somehow profound, or as if I were somehow ignorant of software development as a software developer. (I actually had to spend some time fixing a bug before I wrote this reply.) But not all bugs are created equal. From my perspective, a bug that's discovered relatively quickly by someone else is worse than a bug that's discovered only years later, in the sense that it suggests insufficient QA on the part of the developers, who themselves should have noticed the bug before it shipped. And a bug in the primary functionality of a product or feature is worse than a bug in a more obscure part of the software. This is why I'm not impressed by the length of time since a bug was fixed; if a feature or product was shipped with an obvious, fundamental flaw in its main functionality, that's a stain on the reputation of the developers. And if they keep making such mistakes, why should you ever trust them to be competent? No bug fix can fix the bug writers.

I don't want to focus too much on iCloud Private Relay, though. It wasn't what I had in mind when I was writing my original comment, and I don't even use iCloud Private Relay myself. I mostly don't use a VPN, except on rare occasions. I've discussed iCloud Private Relay here only because you asked me about it.

It's been a busy afternoon/evening for me, so I've kind of run out of steam now on this comment, but I promised I would reply.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#239

Earlier quoted context omitted.

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.

Browser vendors already copy the Audio API code from each other, you can see it in their public GitHub repositories. It doesn't help.

Re: Bypassing Safari 17's advanced audio fingerprinting protection

#240

I'm really ready to just be "that guy" that browses with JS disabled.

It won't save from fingerprinting: https://fingerprint.com/blog/disabling-javascript-wont-stop-.... Though I don't think it's used in practice, because disabled JS is a red flag on its own in situations where fingerprinting is used for security.
Post reply on HN