I’m not sure if fingerprinting blocking is really working - please help?
When I go to https://panopticlick.eff.org using Brave on 3 different platforms, all with “Block All Fingerprinting” turned on, that fingerprinting web site sees info that Brave should be blocking.
Brave on MacOS, Windows, Android, I’m seeing tons of information that is unique on each platform - browser version, platform, screen size, touch points, memory, etc. When I use other browsers, I see the same info - so it looks like Brave is not fingerprinting.
Most specifically - as I connect and disconnect an external browser, the “resolution” changes each test - clearly transmitting that.
How do we know it’s actually really working? If I’ve made a mistake or missed something I’m sorry, just not understanding.
Machine:
VPN of course
Macbok Pro Retina Mid 2015, 16 GB mem w/Mac OS 10.14.6 (18G87)
Brave Version 1.9.76 Chromium: 81.0.4044.138 (Official Build) (64-bit)
Hi, my name is Pete and I’m the privacy researcher at Brave. The easiest way to see this working is to visit this blog post, scroll down to the “Solution: Prevent Fingerprinting By Randomizing” section, and follow steps 1-4 there.
Also, you may be interested in additional fingerprinting endpoints we’re working on. This blog post has a the full initial set of features we’ll modify for the first round.
I loaded two private windows in each browser side by side - two private tabs in the same window - loaded the page, hit “fingerprint me” and then flipped back and forth to carefully see what was different / changing.
So first off, tell me if that ISN’T a successful way to test - that page said private browsing was needed - I didn’t restart in between. I also tried a few different Windows to make sure that wasn’t it, the same results.
I’m not seeing the difference - here are the results:
Hi hi, thanks for the reply. yes, there is an error in your testing approach if you’re testing in Brave in two private tabs, in the same session, you will intentionally get the same fingerprint. Brave varies the fingerprint by session, and by eTLD+1. The most common way to cycle sessions is by restarting the browser.
Opening private browsing mode will also create a new session, but all private tabs will share the same session until you restart the browser again.
So, any of the below will get you different fingerprints in Brave, but will get you the same fingerprint in all other browsers.
one test in a “normal” tab, one test in a “private” tab
one test in a “normal” tab, restart browser and test again in “normal” tab
one test in a “private” tab, restart browser and test again in a “private” tab
copying the page to a new eTLD+1, and re-running the test in the same session, across two diff top level eTLD+1
Hope that helps!
(also, make sure you’re on recent version of Brave, 1.9 or later)
@pes OK, of course you were completely correct, thank you for correcting me. So I used option #1 you listed and went with one normal and one private tab at the same time. I got this result
So that is what you would expect to see? The first vidualization and audiocontext properties the same and the rest different?
And then my last question - I’ve done more research - and the basic answer I can come up with is this: browsers are fighting back against fingerprinting, and Brave my very well be the best one out there. But there are so many vectors of attack on a browser with fingerprinting, and if they are all blocked or randomized, many web sites just won’t work.
So @pes what is your opinion on this? Is the browser market there yet against fingerprinting? Partially there but not yet? Is there any way to really reduce this exposure? I can image a range of options from basic to extreme
Use Brave’s best efforts with full blocking
Create a linux VM and use that for max protection
Create a brand new linux VM every time you need max protection
Buy a brand new laptop every day
Any thoughts? Just trying to understand what the very safest option is… thank you for your time and efforts!
I dont fully follow your results; we don’t (currently) make any changes to font handling, so I can’t explain why you’re seeing different values there. Maybe you’re including the timing information?
But there are so many vectors of attack on a browser with fingerprinting, and if they are all blocked or randomized, many web sites just won’t work
This is mostly true with blocking; you break sites that expect a feautre to work, when you block it. Sites should break far, far less frequently with Brave’s randomization technique, which (in the default setting) adds enough noise to confuse fingerprinters, but not enough to be human detectable.
The goal of farbling / randomization, and what make’s Brave’s technique (imho) better than other approaches, is that in the vast majority of cases you get both functionality and protection.
what the very safest option is
I am very confident that if your goal is to have a browser thats protects your privacy online, Brave is the best option currently (even more so if you’re on nightly), bc of the layers of defense we include (blocking 3p storage, filter lists, fingerprint randomization, referrer policy changes, tracking-query-parameter-filtering, etc)
@pes outstanding, thank you very much for the clarification and details. I’m extremely impressed, this is an excellent result, and I’m very satisfied with the function from Brave on this.
Hi @Brave_user, that is interesting and surprising, and sounds like something odd / unexpected is happening. I just tried myself and see a new fingerprint generated, as expected.
Could you share which version and platform of the browser you’re using? You can find this in brave://version
If you’re on iOS fwiw, you will not see these protections, since i) they’re not as useful on iOS (there is dramatically less hardware diversity) and ii) the restrictions of the iOS platform make them difficult-to-impossible to correctly implement.
@pes
I’m using Brave 1.18.1 on an iOS 13.5.1 device. So I guess that would be the reason I don’t see the results you are seeing.
If I understand you correctly in the case of iOS this would be expected and not a glitch.
Thanks for explaining it. Maybe you would like to add this information to the Brave help or FAQ. Or it might even be a good idea to disable fingerprinting protection completely on iOS.
Thanks for following up @Brave_user. There are other (though weaker) fingerprinting protections we’re able to apply on iOS, so I don’t think we will want to remove that feature all together. However, we’re currently seeing if we can expand the strength and breath of fingerprinting protections on iOS though, with the new version of iOS coming out soon. Hopefully we’ll have more we can announce shortly.
if you’re testing in Brave in two private tabs, in the same session, you will intentionally get the same fingerprint. Brave varies the fingerprint by session, and by eTLD+1. The most common way to cycle sessions is by restarting the browser.
