Fingerprinting protection no longer as good?

Brave 1.65.132 x64
Windows 10

I was messing around with the filter lists in Shields trying to find the group that would result in the fewest number of them while still getting good protection. I was running comparisons using websites like https://adblock-tester.com/ and https://coveryourtracks.eff.org/. While testing my results I noticed Brave was no longer getting a passing grade from coveryourtracks, the fingerprint results went from randomized to unique.

Filter list changes are not going to impact fingerprinting, but in order to eliminate that as a possible factor I went back to the original group I had been using. As expected the outcome remained the same, unique rather than randomized.

Curious as to why the results went down I poked around the website and found this article. Is that possibly the reason behind what I’m seeing?

Those tests are more like examples how easy to track you. There are various methods to track you where even Brave won’t help.

https://lucb1e.com/randomprojects/cookielesscookies/

@theJman I just tested and can’t replicate your issue where you say they don’t show randomized. Let me show you my stats from just now:

And to be clear, Shields settings are as follows

For site:

Global:

image

The changes they made won’t have the big impacts you might be thinking. They just reduced things that were breaking websites. It still have the top tier tracking protection to stop websites from tracking you across sites.

I’m guessing this is just your settings. Make sure your Shields is up for the site and you have things set globally. Ideally I would suggest you imitate settings as I shared above.

Not really. The issue in a lot of the things people try to pull out of their butts, such as in your links, is that people misunderstand what’s being referenced and protected when fingerprinting is mentioned.

Brave does not stop websites from recognizing you’ve visited them before. This isn’t really what anyone means when they speak of fingerprinting. What it stops is their ability to fingerprint and track your activity as you go to other websites.

What some of these fake “tracking” sites do as you linked to are what is akin to party tricks. They track your IP address, store cookies/cache, etc. Then when you revisit, they try to put this together again and share some “code” that they say is your identifier. However, you’ll notice they never are able to tell you what websites you visited or any of your information. The ONLY things they can see is their made up code and that you’ve been to the site before.

A lot of times coming back with a VPN or proxy will give you a brand new identifier. Especially going a private window with Tor generates brand new identifiers because it’s opening with no cookies, a different IP, etc. Again, these only recognize if you’ve been to their site and never are able to track between websites or anything.

Also part of what they are referring to is 3p cookies. But Brave handles that, as you can read at https://brave.com/privacy-updates/7-ephemeral-storage/

NOTE:
But it is right that places can record IP and share with each other. This is part of why people say to use VPN or proxy if you’re too concerned. But Brave does greatly reduce information that can be seen and tracked.

2 Likes

Let’s say some google start those party tricks… Now they track you across Internet. Those “fake tracking” sites are demos, examples, that show it is possible. Brave does good job, but there are still things Brave could be improved, etc…, whatever those party tricks are.

@Saoiray Thank you for all the information, that was helpful. Here is what coveryourtracks is showing me…

Based upon your screen images it appears our configuration is almost identical, the only exception being I’m not forcing HTTPS…

Whether the connection is HTTP or HTTPS won’t affect the outcome of the fingerprinting results though, so that’s not it. For the sake of completeness, here are the filter lists I use…

  • Fanboy’s Social Blocking List
  • Fanboy’s Ultimate Adblock List (Combined list: EasyList, EasyPrivacy, Enhanced Trackers, Fanboy’s Annoyances)
  • uBlock Annoyances

Those won’t affect fingerprinting either. Give the similarities in our respective configurations, I’m stumped why our results vary.

@theJman do a favor. Test in a private window and/or in a new profile.

Part of me is wondering if it’s a cookie in your current profile or perhaps an extension that’s installed that could have an impact. Testing both options test that.

On new profile, don’t add extensions or change settings.

I have “Standard” tracker and ad blocking, two extensions; Google translate and Enpass, Express VPN and my results are as below:

1 Like

@Saoiray here is the update…

I ran https://coveryourtracks.eff.org in a private window and the result was the same, unique fingerprint. I then deleted the one eff.org cookie it left, cleared the cache, closed Brave, reloaded the browser and ran it again (non private window) and it still shows unique.

The extensions I use are:

  • Autoplay Stopper
  • Poper Blocker
  • Session Buddy

Those were installed and active when coveryourtracks was showing me a randomized fingerprint, I don’t imagine they have anything to do with this problem though.

Next I created a new profile, without any extensions or changing a single setting. I ran https://coveryourtracks.eff.org and it too shows unique.

Out of desperation I started poking around brave://flags to see if something bizarre had been set. While searching for “fingerprinting” I stumbled upon “Show Strict Fingerprinting Mode”. It was disabled, which makes sense given the recent change in philosophy. I enabled it, restarted Brave and then ran the test again. This time it came back as randomized!

It seems in my case, when they downgraded the algorithm it stopped Brave from passing the coveryourtracks test. Unfortunately if that flag goes away at some point so too will my ability to get a randomized fingerprint.

FWIW, I’m using Version 1.65.132 Chromium: 124.0.6367.202 (Official Build) (64-bit) on a Windows 10 laptop.

@theJman do you have anything under Create custom filters at brave://settings/shields/filters? I’m asking as things there persist even across new profiles. I’m speaking about the box like you see below:

image

What gets me is I’m not able to replicate your issue and based on feedback I’ve seen on other posts/topics here and on places like Reddit, majority of other people aren’t having issues either.

Guess beyond the above, I’ll also ask, can you update everything at brave://components as well and advise if issue persists? (and it’s just a minor update, but Brave did go from 1.65.132 to 1.65.133, so may as well update that while you’re at it).

I don’t have any custom filters.

You may be on to something here. Every single component listed on that page says “up to date”, except for one…

Update Error

Unfortunately clicking Check for update returns the same error. It begins by saying “Updater started”, then “Component downloading” and finally “Update error”. All in about 1 second. It appears something is broken with the update function for that component.

Does Brave have anything like a log bundle I could create? I might be able to go through that and pinpoint why it’s failing.

@theJman so the info you’re sharing via components is something randomly occurring lately. Typically it’s due to OS or some security program blocking the call. In many cases it can be resolved by launching as an administrator and then it will update.

Please do advise if this works for you. If not, I’ll ask you to download Brave again. Do not uninstall or anything, but install on top of your existing so it will do a manual update. We’ll see if it resolves with that.

i am using linux if that helps

@Saoiray

I’m logged in using an account that’s in the local admin group so it already has elevated privileges. To make sure I left no stone unturned though I did try run as admin, as expected the results were the same. But something else interesting happened.

I was setting up to try your other suggestion, overwriting my current version with another install. While checking the icon to determine what folder it was in I noticed something; I had forgotten that some time ago I added --disable-reading-from-canvas to the command line. That was done to tighten the anti-fingerprinting even further. I started experimenting, enabling/disabling the command line option while switching the Shields fingerprinting level. Here’s what I found…

–disable-reading-from-canvas : enabled
Shields Fingerprinting : Standard
Cover Your Tracks results: Tracker ads, invisible trackers - blocked, unique fingerprint

–disable-reading-from-canvas : enabled
Shields Fingerprinting : Aggressive
Cover Your Tracks results: Tracker ads, invisible trackers - blocked, randomized fingerprint

–disable-reading-from-canvas : disabled
Shields Fingerprinting : Standard
Cover Your Tracks results: Tracker ads, invisible trackers - blocked, randomized fingerprint

–disable-reading-from-canvas : disabled
Shields Fingerprinting : Aggressive
Cover Your Tracks results: Tracker ads, invisible trackers - blocked, randomized fingerprint

To summarize, using --disable-reading-from-canvas and standard Shields fingerprinting causes coveryourtracks to return a status of unique fingerprint, whereas aggressive Shields fingerprinting makes it randomized. Not using --disable-reading-from-canvas with either standard or aggressive Shields fingerprinting returns randomized.

That doesn’t make sense from two perspectives though; how would enabling an additional layer of anti-fingerprinting cause the results to be worse, and how come this didn’t show up a long time ago? I’ve been using --disable-reading-from-canvas for quite some time, yet only recently did coveryourtracks start showing this problem. I wonder if when they modified the fingerprinting algorithm they did something that negatively impacted that command line option. I’m not sure, but something is definitely odd.

Thanks for sharing @theJman. I’m not quite sure what might be happening. I know in the past had been some weird setups where like having Dark Mode on in Brave and then toggling Dark Mode on a website would actually cause things to appear in Light Mode. I almost wonder if something similar might be going on under the hood that when you have two different toggles for it, somehow it gets canceled out or something?

Unfortunately I know nothing on code, so I wouldn’t be able to figure it out even if I chased it down through the Github and all. I will at least tag in @Mattches so he might be aware of your discovery though.