(post deleted by author)
Thanks fria. So your take is that Safari has better fingerprint protection than Brave?
I think just from the sheer difference in the size of the user base and the uniformity of the hardware and OS, it’s got a big advantage right out of the gate, and they implement a lot of similar anti-fingerprinting protections as Brave.
Configuration also matters. The only Safari setting you really need to change is disabling Privacy Preserving Ad Measurement. Other than that, the defaults are good, and there honestly aren’t many things to tweak anyway.
Now compare that to Brave, with its hundreds of settings and even Privacy Guides recommending that you change around 20 of them.
Of course, some people will deviate from the defaults or from Privacy Guides’ recommendations, which makes configuration another variable you have to account for when it comes to fingerprinting.
What’s your opinion though on it not being open source? To what extent can we trust proprietary software?
Proprietary doesn’t mean completely opaque, especially in the LLM era, where the bar of entry for security research is pretty much on the floor.
Also, WebKit is open source.
I mean more for privacy. I trust Apple products are secure but on privacy I’m not so sure.
I know WebKit is open source but that is little reassurance.
Everything is clearly written on the privacy policy, and Apple dare not violate it. Apple also had great records compared to other big tech companies.
You also need to add an ad blocking extension. Brave has ad blocking built in that is one toggle away without needing to go find and download an extension.
So out of the box, I think Brave is superior to Safari (or Firefox for that matter).
To be clear I think Safari is a fine choice. I just do not think there is a reason to add it to the PG recommendations.
You really don’t need to add an ad blocker extension. When you do that you make yourself stand out more from stock Safari users. Even in Brave, you can customize Shields so much that you can stand out a lot from most Brave users just from that. I think they should honestly consider locking everyone to the same blocklist on Brave or at least restricting it to a smaller subset like they have “aggressive” “standard” etc, which they do but they also let you add/remove individual blocklists. Real fingerprinting companies actively use ad blockers to track and fingerprint you.
Tor Browser was against shipping an ad blocker for a long time for various reasons including this. They have a (now closed as completed?) issue on their Gitlab about adding UBO to Tor and they are adamant about trying to keep the blocklists uniform, which I agree with (they bring up how UBO updates lists in the background and I think that should be taken care of as well). Not sure if it’s shipped yet in Tor Browser, it doesn’t seem to be there yet.
But anyway that’s the kind of thing you’d want in an ad blocker: installed by default, using the same uniform blocklist across users on the same version of the browser etc. I see ad blocking as a convenience feature more than anything.
You really don’t need to add an ad blocker extension. When you do that you make yourself stand out more from stock Safari users
Is this true of the Content Blocker style extensions? Since they don’t inject anything on the page I thought they were fairly undetectable. This was just my personal assumption though.
Yes websites can detect when part of the site isn’t loading and use that to fingerprint you.
https://gitlab.torproject.org/tpo/applications/tor-browser/-/work_items/17569 is the current issue and it won’t ship with Tor Browser 16. There was also some talk about using the builtin one and not integrating uBO at all.
There is a fingerprinting risk, but that can be partially mitigated with common ad block settings (like you mentioned).
More importantly I think the fingerprinting risk is outweighed by the malvertising risk of ads. All the anti-fingerprinting in the world goes out the window if you are infected with malware delivered to you by a malicious ad.
Though that is a judgement call and reasonable people disagree. I’m posting this via Safari after all (with Wipr installed for ad block).
Fingerprinting by fingerprint.com (fingerprint pro) is binary. You either achieve anti - fingerprinting against it or you don’t. Brave doesn’t have effective mitigations against fingerprint pro ime, so adding extensions or customizing blocklists doesn’t seem like something that should be significantly avoided for fingerprinting risk.
As someone who only uses mobile devices (iPhone and iPad mini), I’m curious—does Safari on MacOS support letterboxing? Between Safari on iOS/iPadOS and MacOS, I’d imagine the biggest fingerprinting difference to be with MacOS’s version having a resizable canvas.
I disagree that ad blockers are going to be a significant help with blocking malware. They’re based around badness enumeration, so if anything isn’t on the blocklist, it’ll get through anyway. With how fast attackers can pump out malware and fake sites these days with the help of AI, you can’t really rely on that for security.
While Safari currently lacks important security like Site Isolation (it’s currently being worked on), you can mitigate a lot of security risk by turning on Lockdown Mode right now and whitelisting sites it breaks.
If you want to block malware then Safe Browsing is already built-in so you can just use that. Safe Browsing only sends a small hash of the URL and they now use OHTTP to protect your IP address, although I don’t know if Safari specifically uses this feature since it’s optional for now. Their privacy policy suggests not for now:
The actual website address is never shared with the safe browsing provider. Google (and, for users with China mainland or Hong Kong set as their region, Tencent) may also log your IP address when information is sent to them.
If you use a VPN it shouldn’t be an issue though.
It doesn’t, but they do try to reduce fingerprinting based on screen size metrics:
Lastly, for various web APIs that currently directly expose window and screen-related metrics, Safari takes a different approach: instead of the noise-injection-based mitigations described above, entropy is reduced by fixing the results to either hard-coded values, or values that match other APIs.