Brave anti-fingerprint fails against fingerprint.js

[debsidian]

1. Go to https://fingerprintjs.com/demo/
2. Open new tabs, new profiles. Try again. Make sure your shields are on and all turned on to strict/aggressive.
3. Delete your cookies, history, etc. and try again.

Actual result:

Screenshot attached

Reproduces how often:

Easily reproduced.

Desktop Brave version:

Brave 1.19.92 Chromium: 88.0.4324.152 (Official Build) (x86_64)
Revision 6579930fc53b4dc589c042bec9d0a3778326974d-refs/branch-heads/4324@{#2106}
OS macOS Version 11.2 (Build 20D64)
JavaScript V8 8.8.278.15
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.152 Safari/537.36
Command Line /Applications/Brave Browser.app/Contents/MacOS/Brave Browser --enable-dom-distiller --disable-domain-reliability --no-pings --extension-content-verification=enforce_strict --extensions-install-verification=enforce --origin-trial-public-key=bYUKPJoPnCxeNvu72j4EmPuK7tr1PAC7SHh8ld9Mw3E=,fMS4mpO6buLQ/QMd+zJmxzty/VQ6B1EUZqoCU04zoRU= --sync-url=https://sync-v2.brave.com/v2 --lso-url=https://no-thanks.invalid --variations-server-url=https://variations.brave.com/seed --enable-features=AutoupgradeMixedContent,WebUIDarkMode,LegacyTLSEnforced,PrefetchPrivacyChanges,PasswordImport,ReducedReferrerGranularity --disable-features=AutofillEnableAccountWalletStorage,TextFragmentAnchor,NotificationTriggers,WebOTP,PrivacySettingsRedesign,PasswordCheck,NetworkTimeServiceQuerying,TabHoverCards,AutofillServerCommunication,IdleDetection,SignedExchangeSubresourcePrefetch,SafeBrowsingEnhancedProtection --flag-switches-begin --load-media-router-component-extension=1 --enable-features=AutoupgradeMixedContent,WebUIDarkMode,LegacyTLSEnforced,PrefetchPrivacyChanges,PasswordImport,ReducedReferrerGranularity,DnsOverHttps,LazyImageLoading:automatic-lazy-load-images-enabled/true/restrict-lazy-load-images-to-data-saver-only/false,ParallelDownloading,WebRtcUseMinMaxVEADimensions --flag-switches-end
Executable Path /Applications/Brave Browser.app/Contents/MacOS/Brave Browser
Profile Path /Users/redacted/Library/Application Support/BraveSoftware/Brave-Browser/Default
Variations 2729b628-70ea8f25

Version/Channel Information:

Stable

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? No
• Does the issue resolve itself when disabling Brave Rewards? No
• Is the issue reproducible on the latest version of Chrome? Yes

Miscellaneous Information:

[g-30]

I can confirm. The fingerprint ID remains the same even if you change your IP address. With Brave's "strict protection" mode on there is still some unique data they are able to record.
Also, the bizarre thing is – they somehow distinguish Brave from other browsers. I have a fake User Agent set in both navigator & the HTTP header, and yet they are able to tell that I'm on Brave.

[pes10k]

Thank you for the report @Smagold and @devingoodman , i will take a look and report back!

[iam-cult]

I have this problem as well, although this seems to affect all browsers, even Tor (although it did change after I reset my identity)

[iam-cult]

It seems (through my own testing) that the website additionally uses the cache to identify users (or maybe favicons? From my understanding Brave now includes the favicon cache when clearing browser cache, and using an extension to clear the cache does nothing), as whenever I clear my cache the ID resets.

Also, the bizarre thing is – they somehow distinguish Brave from other browsers.

My best guess for how it would identify Brave as the browser is that it might be able to pick out Brave Shields because of how it tries to block fingerprinting, but I am nowhere near qualified enough to come to any concrete conclusions.

[bsclifton]

@Smagold we do have a custom property available called navigator.brave.isBrave which is present to help partners identify this. @pes10k helped define the approach taken and can share more details (I did the implementation on Desktop/Android). We don't have a way to turn this off

[g-30]

we do have a custom property available called navigator.brave.isBrave which is present to help partners identify this.

@bsclifton I have a script that, among other things, does this on every page:

if (navigator.brave) {
  delete Navigator.prototype.brave;
}

And yet, FingerprintJS demo page is able to tell that I'm on Brave: Brave on Windows (10).

My User Agent, Platform, and some other navigator properties are faked and FingerprintJS seems to trust the faked values no problem. That makes me think that it's possible they detect Brave based on some other non-navigator properties that are leaking out.

There isn't as many Brave users as we all wish there was, and seeing a script being able to tell us apart in the crowd of other browsers makes it possible to target us with some more aggressive & precise fingerprinting tactics. I think it's an issue worth investigating.

[pes10k]

Hmm, i think the fact that the site caches responses in storage, and uses that to look like its fingerprinting you is making folks think this thing is more clever than it is :P

I just tested now, once in my main profile, and once in a tor tab (to get a new profile, new window and a new IP), and, as expected, the site wasn't able to link the two

Are folks seeing otherwise if they repeat the above?

I dug into this a while ago, and at least then, the site was doing the following:

1. looking at storage to "fingerprint" you (i.e. not fingerprinting at all)
2. using IP + useragent (again, not fingerprinting)
3. if still no match, use fingerprint2.js signals, and send them server side. And for brave users, drop the inputs we randomize (i.e., a good thing for brave users). If there is a match, report a match, otherwise they give up

Anyway, TL;DR; the site is mostly smoke and mirrors trying to sell a commercial service. They're one of the sites we use when deciding what to randomize next for fingerprinting protections, but they're better at looking good at fingerprinting than actually being good at fingerprinting (as best i can tell).

That being said, if folks are seeing otherwise, please let me know. We're not trying to get complacent here :)

[iam-cult]

I don't think that they're just simply using the cache, as my cache clearing extensions (cookie autodelete) do nothing, only when I manually clear the browser cache via settings does my ID reset. I'm suspicious it might be favicons, as Firefox lacks this problem, and brave now clears favicons as well as the cache when you clear the cache. My extensions would not be able to clear the favicon cache, and would do nothing to reset the ID when set to clear the cache.

[pes10k]

Right, i think we're agreeing. What i'm saying is that the site uses a whole bunch of ways of trying to reidentify you that aren't fingerprinting (DOM storage, cache probes, etc). But when those fail and they have to actually do fingerprinting, Brave's defenses are successful.

A 1p site being able to re-identify you when you revisit in the same profile isn't the kind of privacy harm Brave is most concerned about (currently you can use private browsing for this, and we plan for future features like #15097 and #15018 to give easier defenses).

Brave is primarily concerned about a single party being able to reidentify or learn about you when browsing across different sites. Brave already has very good protections here (see https://brave.com/privacy-updates-7/ for example, and the network isolation work from upstream we will be enabling very shortly), and so a fingerprinting attack that would circumvent these defenses would be very concerning.

Anyway, all that is to say, we're primarily concerned with sites that can re-identify you across 1p, or across profiles (Tor mode, private browsing). Making it easier for a 1p site to forget you w/in a single profile is also an appealing feature we have planned (again, see above issues), but its a lower priority for us, given the range of privacy risks on the Web now that are scarier.

But, TL;DR; if this issue is important to you, please watch the issues I mentioned above. I expect we'll have some fun / exciting stuff to share shortly ;)

[pes10k]

I'm closing this issue since I think we're all resolved that its a mix of cache probe attacks (which should be fixed shortly, with the NetworkIsolationKey work from upstream), the site being clever and trying to claim boring old 1p storage based reidentification is actually fingerprinting prowess, and an agreement that #15018 would be a good feature for this issue, and many others.

If folks still have concerns that there are popular scripts successfully reidentifying Brave users through browser fingerprinting, and believes those methods wouldn't be addressed by the further defenses planned in #11770, please reopen the issue.

Thanks to everyone who participated in the helpful discussion!