Are you protected against online tracking? The EFF's Cover Your Tracks site has the answer
Cover Your Tracks is an online test by the Electronic Frontier Foundation (EFF) to determine how well a browser is protecting user data against online tracking.
When you connect to a site using a browser, information is revealed to the site automatically. Sites may run scripts to gather additional information about the device that is used, and all of that may be used to track users across the Internet.
Cover Your Tracks is based on EFF's Panopticlick tool that the organization launched in 2010 and updated in 2015. Panopticlick redirects users to the new Cover Your Tracks tool automatically.
A click on the "test your browser" button on the site runs a quick check that determines the following:
- Is the browser blocking advertisement?
- Is the browser blocking trackers.
- Is the browser unblocking third-parties that honor Do Not Track?
- Has the browser a unique fingerprint?
The test results are displayed on a single page right after the test.
While the information that the test provides may be revealing on its own, it is the explanation of the results that may be most useful to Internet users.
One of the main differences between Panopticlick and Cover Your Tracks is that the latter's aim is to go a step further than the former. Panopticlick displayed whether a browser's fingerprint was unique, and Cover Your Tracks lifts the curtain by revealing all the bits of data that the browser reveals that contribute to the fingerprint.
Based on the findings, users may change browser settings or install browser extensions to limit online tracking. The EFF recommends using the organization's own Privacy Badger application to combat online trackers, and to use a browser, e.g. Brave, that has fingerprint-protection built-in and enabled.
Third-party extensions such as NoScript, uBlock Origin, or Canvas Blocker may also be used to limit online tracking.
It is a good idea to re-run the test after modifying browser settings or installing extensions to see how the changes affect online tracking and the fingerprint of the browser.
The EFF notes that its test does not cover all tracking and fingerprinting techniques that sites may use for online tracking.
Now You: do you use online tests to determine if you can be tracked online? What do you use to combat tracking?
Site crashes with a “request too large” error. Pale Moon wins :-)
Works perfectly in my Vivaldi.
Works fine with Firefox for me
Do you understand that this is not the _site_ crashing?
I get “Bad Request
Request Line is too large (7056 > 4094)”
when I try to do that test on Basilisk on Windows 10 Pro 2004.
It works in my other browsers. However, EFF needs to fix the poor display. ONLY classic Edge displays the site correctly.
I really liked Panopticlick. This test needs refining as the screen convulses several times, before and during the test, on every browser I tried as well as all browsers, except classic Edge, mess with the display that is seen when you first visit the site (display after the test is finished is ok).
Bad Request
Request Line is too large (8192 > 4094)
I had the same using Pale Moon but it worked OK on Firefox.
Tell us how to block fingerprinting in Chrome to get the green check there.
@Mele: you said
I did not experience any of that. AFAIAC, the site works fine.
So Klaus,
You saw all the green leaves on the right side of the site? All my browsers, save Classic Edge, the right side of the page was blank and I wondered why EFF would make such a poor looking page…until I tried Classic Edge and saw how it is supposed to look.
I really liked Panopticlick but I hadn’t used it it in a year or more (finally forgot about it until I read this article). I recall now that my gecko based browsers had a lot of problems with Panopticlick page too.
My gecko browsers have trouble with Martin’s site too. This site never remembers my name or email and I have been reading the excellent articles here (and commenting some times) for many years. I always check the box to consent to store my data but I don’t think that has ever worked with Firefox, Basilisk, SeaMonkey, etc.
I noticed that Brave was my ONLY browser that gave me an anon fingerprint. That is great….now if I just liked Brave more….
@Mele20
If Brave Rewards is the issue, then you can turn that off. You don’t have to use it. I use Brave without Brave Rewards and it’s just fine.
@Jeff
Adblockers like uBlock Origin already block most fingerprinting scripts, lists like the EasyList or EasyPrivacy list are especially relevant here.
Otherwise, Chrome doesn’t do much to actively fool fingerprinting scripts. You’d have to resort to browsers like Brave…
https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
…or Bromite…
https://github.com/bromite/bromite#features
If you are thoroughly paranoid, use Tor.
Cheers.
Blocking tracking ads? Yes
Blocking invisible trackers? Yes
Unblocking 3rd parties that honor Do Not Track? No
Protecting you from fingerprinting? Your browser has a nearly-unique fingerprint
—
I’ve always been fingerprinted, story of my life, too good, honest or simply naive. The sort of guy who attends a masked ball without the mask (“I knew I had forgotten something!”).
So, again, I’m spotted. Darn. Well, not really. They still don’t know if the user is myself or my alter ego, my true twin that is (and we both hit the keyboard at the same speed, making the same mistakes. Oh, and yes : I happen to lie.
Yup, from what I’ve seen, the fingerprinting tech is way ahead of the game, regardless to what we do or think. With machine learning algorithms, they have fingerprinting techniques that we can’t even imagine.
I guess the best way to not be fingerprinted is to use a VM OS that changes your specs each time you use it?
I’ve tried various anti-fingerprinting add-ons, but they always lack in some way, hence I’ve given up.
Stupid test.
With javascript completely blocked you need to allow trackers taken from the AdGuard Tracking Protection list.
No wonder perfectly in tune with EFF.
Hi.
I try on firefox 84.0.1 + CanvasBlocker, ublock and privacy badger.
Blocking tracking ads? Yes
Blocking invisible trackers? Yes
Unblocking 3rd parties that honor Do Not Track? No
Protecting you from fingerprinting? Your browser has a unique fingerprint
How i get randomized fingerprint?
@KamiOh
> How i get randomized fingerprint?
By using Brave. Well, more or less. Brave’s fingerprinting protections often rely on randomization while most of Firefox’s fingerprinting protections aim at making everyone look the same.
That being said, Firefox does randomize some values and not every fingerprinting vector is tackled by randomization in Brave, because randomization is not the best solution for every vector. My above reply is just the expression of a general theme / approach.
This answer assumes that “You have a randomized fingerprint!” is the result desired by you for the EFF test.
When I run Cover Your Tracks I get wrong or incomplete results compared to what I expect re Ad Blocker Used, System Fonts, Screen Size, and Platform.
“Is the browser unblocking third-parties that honor Do Not Track?”
FFS, don’t unblock those !
Look ma, no extensions: https://i.imgur.com/lhFG8xp.png
32-bit Chrome Dev v85 running off 64-bit LTSC 1809. Nobody runs this Chrome version anymore, hence the unique fingerprint. Probably almost nobody runs any 32-bit Chrome on a 64-bit OS anymore.
Your browser has a unique fingerprint. Any suggestions on how to prevent users from getting fingered?
Use Brave browser since Brave have a mechanism to prevent Fingerprinting.
A unique fingerprint is only bad if your browser always generates the same fingerprint, enabling it to be tracked.
I’m using Pale Moon with ‘canvas.poisondata’ enabled, which generates a new unique fingerprint on every page – so tracking using fingerprinting is impossible.
You may be able to download an extension that can do that in your browser. Or you could switch to Pale Moon and enable it there.
Thanks for the information. Will give both Pale Moon and Brave a try. I don’t want to be fingered anymore.
@Anonymous
Can’t help you for Pale Moon but this is how I have set up Brave:
https://www.ghacks.net/2020/11/17/brave-browser-gets-cname-based-adblocking-support/#comment-4480402
Hope this helps.
Martin!
ghacks.net has not been loading in firefox since few days. FF gets Paralysis. 😄 Now I am typing this comment in vivaldi.
Thanks for the report, I have forwarded this to my rep. Lets hope it gets fixed quickly.
What you guys think about this one: https://browserleaks.com
?
I still find that stealing any data a persons life brings with it is a criminal act. All that miss use and theft needs to be heavily regulated and controlled.
After all, this systematic stealing of data is not that old, something like 20 years perhaps and is as of today almost unregulated.
Everyone is unique. If someone really wanted to put all the pieces together, they could. There is no way to stop fingerprinting since they are always inventing new techniques to identify users. You could either block 3rd party scripts and ads, use multiple browsers for seperate things, use Tor browser, or if you don’t want to use Tor, an alternative would be to set privacy.resistFingerprinting to true in Firefox ‘about:config’ page as well as firstparty.isolate
Aside from that, fingerprinting is a bitch bro. Don’t even try to beat it. Just do what you can
I’ve had privacy.resistFingerprinting and firstparty.isolate settings both set to true in Firefox and the EFF test still said browser has unique fingerprint.
Is there no way to prevent fingerprinting in Firefox?
Q: How to get a randomized fingerprint?
A: Use Brave Browser, it does it out of the box, no extensions needed
Brave’s randomizing can be rendered static: it’s “ultimately” no better than just returning the same value for everyone. Even on cover your tracks it’s doing exactly that: by returning a value such as “randomized”. That said, randomizing is the only effective solution for some metrics: such as canvas. Randomizing is not bad, but it only fools naive scripts.
Other than that, Brave’s anti-FPing is extremely immature: for example canvas randomizing can be COMPLETELY BYPASSED and has been since they introduced it about eight or nine months ago (I’m not entirely sure of the timeline and can’t be assed looking up the exact date). Even if canvas didn’t leak in iframes, it can still be bypassed in other ways because the randomizing is weak. The user agent randomizing is simply bypassed by stripping leading trailing and multiple spaces (note: that’s just the random part: the userAgent is standardized in other ways in Brave to reduce FPing). And so on. Not to mention that it lacks coverage in many areas such as fonts, screen metrics, timezone, formatting, languages, timing attacks, and so much more.
This is just a fact, as it will take them years to catch up due to the nature of the beast: and that’s even assuming that they can: at the moment they are trying to bolt fixes on top of chromium and relying on “fragile / delicate” process – rather than getting into the engine and engineering it properly. But, hey, they can only get better, and good luck to them .. cuz fuck fingerprinting
If you want a real, proper, tested, vetted and superior solution (also comes with comprehensive first party isolation, and no need for a VPN to mask your networking digital tracks), then use Tor Browser – which is perfectly acceptable to use for anything you like, and is used by all sorts of people – you don’t have to be “paranoid” as some idiots claim
– https://www.torproject.org/about/torusers.html.en
@Random
Do not listen to idiots who tell you that Brave’s randomized fingerprints can be rendered “static”. Because I am tired of Pants’ “I am a pseudo-expert while you are not” theater, I just let an actual expert (M.C. Straver) speak for me here:
“By all means, be unique in your fingerprints, and be unique every time — it works much better than trying to erase your fingerprints to “blend in”.
Think of it this way: most browsers try to evade fingerprinting by “putting on the same clothes as others”, trying to make one blend in to the masses. The problem is, the people recognizing you as an individual will just ignore the clothes and look for other distinguishing marks instead, like a hat. Which becomes pretty easy if the rest is all the same.
Now compare this with changing your fingerprint every time, meaning you put on different clothes each time (and so do others). Looking over a crowd of people, how easy will it be to spot that unique individual now, even if they wear the same hat as last time? (…)
So yes, ultimately, making yourself unique, and making yourself unique every time is going to be the best way to fool trackers. How exactly you do that without crippling yourself is a different question, of course, but not in any way more difficult to answer than the question how to blend in without crippling yourself (because using nothing but default settings is crippling too).”
source: https://forum.palemoon.org/viewtopic.php?f=4&t=14813&p=106585#p106585
——
M.C. Straver about Tor and the breakage it causes:
“TOR browser may have additional anti-fingerprinting measures, but the inevitable drawback of it at the same time is that it will cripple the web by disabling features that are in use by websites for good reason.”
source: https://forum.palemoon.org/viewtopic.php?f=13&t=17211&p=126017#p126017
“We won’t be adopting overzealous blocking patches from the TOR project because they destroy more than they “fix”.
Also, FYI, we already have canvas poisoning which is a non-destructive mitigation of fingerprinting.”
source: https://forum.palemoon.org/viewtopic.php?f=62&t=18287&p=135846#p135846
——
Randomizing destroys the canonical fingerprint, and will feed trackers / advertisers with lots and lots of useless data, you can’t just put all “randomized” in one bucket if you appear to be someone else each time, because the tracker / advertiser can’t say it was the same person each time, but differentiating between the different visits would be what has to be done to identify with any certainty one person as, well, one person, instead of many. If you do put all “randomized” in one bucket, that bucket will be very big with lots of useless data in it, unsuitable to find out whether you were actually the same person all along or someone else each time. Assuming that it even matters, because you can be identified at the network level anyway (timing attacks and correlation, or the IP address at a more basic level). Neither Pants’ arkengem nor what I propose protect you from identification at the network level. Tor, as an anonymity tool, covers both the browser fingerprint and protection at the network level (though timing correlations are still possible there, just harder – nothing a three letter agency couldn’t solve) – there is a reason why it does both because one is more or less useless without the other if anonymity is the goal. The goal here is rather privacy.
Tor is a special purpose browser and should be used by people having a strong need for anonymity, such as dissidents. It is NOT a general purpose browser and it is breaking websites because as far as Tor is concerned, anonymity trumps web compatibility if a choice were to be made. People like Pants do not understand that people should not be using this as their everyday browsing tool.
Back to the topic at hand: Brave has had its fingerprinting protections for less than one year now, so incompleteness and bugs are kind of expected. Firefox and Tor tried for years and years to get it right. My advice would be to stick with it because it is in fact improving on a continual basis. What Pants also fails to see because it is not strictly privacy-related is that there are other good reasons not to use Firefox, for example its rather weak exploit mitigations:
https://madaidans-insecurities.github.io/firefox-chromium.html
Switching from a Chromium-based browser to Firefox brings you a questionable privacy gain (“questionable” because most fingerprinting scripts get blocked by an adblocker anyway no matter the browser and a significant portion of the rest are being fooled by what Brave does already), while you are sacrificing stability, performance, and, horribly enough, security.
> Tor is a special purpose browser and should be used by people having a strong need for anonymity, such as dissidents
Tor Browser is a browser and should be used by anyone for anything
– https://www.torproject.org/about/torusers.html.en
—
> Do not listen to idiots who tell you that Brave’s randomized fingerprints can be rendered “staticâ€
Stop lying dude. The PROOF is right there in the cover your tracks results: it is detecting the randomness and returning a static result. It’s so easy. There’s a reason why RFP/Tor Browser didn’t bother randomizing everything – it’s a waste of time, effort, resources, it carries additional risk, and it is easily detected and thus any benefit of randomizing is lost. You also don’t need a dozen poison pills, you only need one.
—
> The rest
Straver’s is not a fingerprinting expert (that I know of) and his analogy is kinda mixed up, but I know what he’s getting at. It also has absolutely nothing to do with the fact that randomizing can be easily detected and returned as a static value: and thus is ultimately no better than lowering entropy. So if you’re claiming that lowering entropy is flawed, then well .. news for you .. then all of Brave’s anti-FPing is flawed .. which is clearly a loaf of shit. Lowering entropy works and is ultimately all you have.
FPing gets metrics, it gets all the metrics it can or thinks it needs: it gets the clothes _and_ the hat _and_ the walking stick _and_ your underwear color etc. Just because some clothes were spoofed and the hat wasn’t, doesn’t mean the hat sticks out more: it sticks out the SAME as it always did. Straver is just pointing out is that in order to defeat FPing, you need to cover/consider all metrics. Combined those metrics create a FP. How a script (or backend) decides to use those metrics (e.g. to create stability) is also important.
Just because e.g. plugins is useless for FPing (see below), that doesn’t change the other metrics: i.e the entropy of the “hat” DOES NOT CHANGE. What does change is that the pool of useful metric resources for the script is shrinking and thus the hat becomes more significant within that one particular FP
If a script knows a metric is tampered with, it becomes the same value for all users who tamper with it = a static value. e.g. plugins
– Brave: returns two random strings of gibberish which the script can easily detect as fake and returns “fake” for all Brave users
– Tor Browser: is always empty, the script returns “empty” for all TB users
If you’re trying to argue that randomizing is better than lowering entropy: I say that it ONLY fools naive scripts (this is not a bad thing) and is ultimately no better than lowering entropy. ALL of brave’s randomizing can be detected (without cross-domain checking) – even though they seed it per session + per eTLD+1 – i.e you can detect it as one party only.
As the anti-FPing gets more comprehensive, the uniqueness will fall. So when Brave adds font protection, and timezone protection .. and so on .. Brave users will have less and less metrics that can be used against them. But they’ll still be the same: e.g.
– TB: all users are timezone UTC (and all methods and equivalency covered)
– Brave: all users are timezone “fake” (assuming they can properly cover all the methods/equivalency)
– The timezone is rendered useless in each set. You cannot hide you are Brave or TB. You cannot hide the randomizing
> Randomizing destroys the canonical fingerprint, and will feed trackers / advertisers with lots and lots of useless data
> … you can’t just put all “randomized†in one bucket if you appear to be someone else each time
Only if it’s a naive script. Otherwise it is no better than lowering entropy. Detecting randomizing and returning a static value, users won’t appear to be someone else each time. Randomizing is not some fucking holy grail. Scripts will (and have) simply evolved to bypass it. The only extra benefit (and there are downsides and risks too) is to fool naive scripts: big deal. And if it’s not a naive script, then the end result is the SAME as lowering entropy
—
The network/IP digital footprint is not what I consider in scope: it is an assumption that this is being hidden (VPN, Tor etc)
You’ve already shown your complete ignorance in how entropy, fingerprinting and linkability work [1]
– as evidenced by your previous claims that a site can correctly, 100% guaranteed, correlate or linkify traffic on their site to a single user just because, **unknown** to them, there was only ever one person with that FP who repeatedly visits them
e.g. there are a million (potentially tens/hundreds of millions) of Tor Browser users with fingerprint X. User with fingerprint X visits site Y several times a month. Site Y sees 10 visits from fingerprint X and claims it is the same user. That’s not how it works.
If, as you claim, this is flawed: then Brave is in the shit because it can also be reduced to a static FP.
[1] Readers can wade thru https://www.ghacks.net/2020/10/06/mozilla-adds-two-firefox-add-on-badges-verified-and-by-firefox/#comments as just one source of IH’s ignorance and wild claims
> My advice would be to stick with it [Brave] because it is in fact improving on a continual basis
lulz … so just like everything else .. keep promoting an inferior solution .. be happy with your 90% (you claimed this figure) while the rest of us aim for 100 and real solutions
@Pants
My my… So much nonsense in just one post. Hey, first day in 2021, another day, another case of Pants’ willful ignorance.
> The PROOF is right there in the cover your tracks results: it is detecting the randomness and returning a static result.
It can detect the “randomness” because the randomness is everything but “natural”, so to speak. There is no way a browser would come up with the result it produces if it were a “real” fingerprint. But that does not lower its effectiveness. Of course it is returning a result, because even an altered result is a result, but the result “changes” across sessions. That the change is being detected as not being a real fingerprint has nothing to with it.
> There’s a reason why RFP/Tor Browser didn’t bother randomizing everything – it’s a waste of time, effort, resources, it carries additional risk, and it is easily detected and thus any benefit of randomizing is lost.
Instead they come up with “solutions” that are not workable in the real world. They disable features websites sometimes need to operate correctly (As Straver pointed out), while e.g. Brave keeps those intact and just alters the results / outcome.
> You also don’t need a dozen poison pills, you only need one.
Uhm, no. One randomized result out of many results that are combined into the fingerprint is not enough for anonymity. When Brave randomizes e.g. Canvas but reports the real results for screen resolution, web audio API etc. pp., the certainty that the same person is in fact the same person perhaps gets lowered from 100% to 95% or something. Only when you lie about all values you can confuse them.
> Straver is just pointing out is that in order to defeat FPing, you need to cover/consider all metrics. Combined those metrics create a FP.
Thanks for explaining the basics, of course you need to cover all values in the end.
> It also has absolutely nothing to do with the fact that randomizing can be easily detected and returned as a static value: and thus is ultimately no better than lowering entropy.
Randomizing can be detected but it does not matter in the way you think it matters. When you detect that someone lies you are still not able to find out the real values just because you know that he or she lied. And the point is that the values are NOT static, but changes per session. “Randomized” in itself is not static, that just means that it can be detected that you lie ≠finding out your real fingerprint.
– Brave: returns two random strings of gibberish which the script can easily detect as fake and returns “fake†for all Brave users
That still doesn’t mean that you can say with any certainty that it was the same user. It just means all Brave users produce fake values, quelle surprise.
> Tor Browser: is always empty, the script returns “empty†for all TB users
I hope you are aware of the web compatibility implications here. Returning gibberish is the only non-breaking solution.
> You’ve already shown your complete ignorance in how entropy, fingerprinting and linkability work
You’re ignorant enough not to understand that randomness being detected is not in itself an identification criterion. Again: If I know that someone lies, that doesn’t have any influence on the viability of the fake results I get. I still need the real ones for a canonical fingerprint and whatever Brave puts out is completely worthless for that. The fact that websites know that the values are randomized because no browser would produce such values naturally does not help them one bit.
> The network/IP digital footprint is not what I consider in scope: it is an assumption that this is being hidden (VPN, Tor etc)
Then perhaps you should add this info to the arkengem wiki (unless it’s already there in some footnote) because you are giving users a fake sense of privacy. Your setup aims to tackle fingerprinting while the IP address is still being revealed, haha.
> as evidenced by your previous claims that a site can correctly, 100% guaranteed, correlate or linkify traffic on their site to a single user just because, **unknown** to them, there was only ever one person with that FP who repeatedly visits them
Read again what I wrote there. If there is only ever one person with e.g. your setup visiting a website, then the website can 100% it is the same user, if not at the network level (which is something your setup doesn’t cover) then by other methods. Since your setup is bad for web compatibility, users will wish to reverse some of your anti-fingerprinting measures, returning the real values for some vector. The “everyone looks the same” approach relies on nothing being changed – but this is unlikely, because of the breakage it causes. Returning gibberish at least still allows the website to detect that a feature is being supported and in the vast majority of cases work correctly. Tor uses a stone age approach which gives birth to all associated website breakage people complain about. The solution to fingerprinting is NOT taking features websites need away.
> there are a million (potentially tens/hundreds of millions) of Tor Browser users with fingerprint X.
Again, Tor is a general purpose browser. They are happy with breaking websites if only they can make everyone look the same. This behavior should STAY in a special purpose browser where it belongs. Your arkengem best effort-whatever user.js aims to copy & paste whatever Tor does and applies it to Firefox – where this stone age approach is less acceptable (you also destroy all of your anti-FP efforts by recommending to install extensions – which is something the Tor project explicitly warns against).
> then Brave is in the shit because it can also be reduced to a static FP
Detecting that something was randomized does not help you one bit in creating a canonical fingerprint. Fingerprinting relies on canonical fingerprints.
> Readers can wade thru (…) as just one source of IH’s ignorance and wild claims
After reading that, readers will know that I am not willing to sacrifice the usability of a general use browser like Brave or even Firefox at the altar of a stone age approach. Happy reading. There is no way an ordinary user will not destroy Tor’s fingerprinting because of the breakage it causes. No way. As I said, what is acceptable in a special purpose browser can’t just be transferred to a general purpose browser. This is why I said: “People like Pants do not understand that people should not be using this as their everyday browsing tool.” – Thanks for proving it again.
> keep promoting an inferior solution .. be happy with your 90% (you claimed this figure) while the rest of us aim for 100 and real solutions
Your “real solutions” should stay in a special purpose browser where they belong. I always find it funny how your setup tries to imitate Tor while being completely ignorant of the fact that Tor is actually PATCHING Firefox in significant ways, which is why it can’t be 100% recreated by just modifying Firefox. But I do not expect the non-coder that you are to understand that.
I said my solutions are enough for 90% (or whatever, I don’t intend to ride that number to death) of use cases and this is true. The 10% rest is a sack of problems better left to special purpose browsers. I find it funny how you literally give zero consideration to things like web compatibility.
I also know that you do not care about e.g. security because otherwise you would understand that Brave is the only browser with modern security features that tries to tackle fingerprinting issue. You know how most Tor users are being de-anonymized in the wild? Three letter agencies just drop viruses on their sorry asses, which is easy enough because Tor inherits Firefox’s laughable security precautions. No need to do all that deanonymization when you can just infiltrate the device at the OS level – it’s easy enough.
So who is right? I know who I’d trust
– Tor Browser/Mozilla devs, thousands of researchers + papers + phDs, tens/hundreds of thousands of tests, thoroughly vetted etc: including real world tests
– Iron Heart
—
THIS ONE IS A REAL DOZEY!!! READ IT PEOPLE
> IH: When you detect that someone lies you are still not able to find out the real values … And the point is that the values are NOT static, but changes per session. “Randomized†in itself is not static
read that again … “Randomized” (in quotes) in itself is not static Again, Tor is [NOT] a general purpose browser
Dude, it’s totally sweeeeeet as F for 90% of web surfing. You know … that 90% figure you love so much
The makers of Tor Browser also beg to differ with your assessment
– see https://www.torproject.org/about/torusers.html.en
> breakage
The vast bulk of RFP protected items (about 100) cause ZERO breakage. “Returning gibberish is the only non-breaking solution” you said about plugins: Firefox has returned none since FF52 by default: it doesn’t break anything.
About two, maybe three depending on OS, items “break” some things, canvas being the main one and that can be given an exception if you trust the site. Could they re-think this down the track to be more compat, sure. Another two maybe cause some side effects (but do not break anything). This is the nature of the beast when you don’t follow standards. The few things TB disables are web audio and webgl (RFP doesn’t cover audio or webgl rendering yet). Would it be nice to have, sure, but it’s not high priority. Of course TB care about compat cost – but it’s always a trade off between risk and payoff, and resources to do it.
Take for example OfflineAudioContext: the entropy comes from math floating points. It has nothing to do with hardware, it never even touches the hardware. The solution is upstream with the standards body to include a basic math library for the few math functions and limited ranges used, and this discussion has been under way for some time: hence Mozilla/TB aren’t wasting time on it, especially since the web audio API is not even used much (WebRTC would be the main one) and the entropy is actually very low – hence TB choose to disable it
Oh, and good luck randomizing languages and timezones: people will be getting weird date formats and times in emails, and pages served in gibberish. Feel free to drivel when you’ve sorted out the fonts, screen, window, timing and the 80+ other things Brave lacks parity in
> It can detect the randomness because the randomness is everything but natural
Randomness (and lowering entropy) can be plausible: spoof hardwareConcurrency as 2; that is a real “natural” value. Spoof plugins as empty; that is a real “natural” value in Firefox since FF52. Subtle canvas randomizing in Brave is totally plausible. So how do the scripts know a value is random (or fake or unreliable)? I know, do you? And yes, every single one can be detected as random via a one-party only script.
> Uhm, no. One randomized result out of many results … is not enough
Sheeshus. Pay attention. We’re talking about randomized vs spoofed/lowered. A NAIVE script only needs to swallow one poison pill to ruin the overall FP. Canvas is high entropy and in almost every FP script: that’s a good start. A second poison pill may prove useful. You certainly don’t need to randomize everything
Randomizing is only good for naive scripts: naive scripts are already easily fooled (with canvas) and smarter scripts **should** already be covered as well (you know, that 100% thing like Tor Browser .. not that 90% that you love)
> Thanks for explaining the basics
I have to because your knowledge is so inept. You quote a so-called “expert” and his quote isn’t even useful or meaningful in this discussion. I explained what he meant, you agreed and said it was “doh! the basics” – so in other words, you’re kicking yourself for bringing nothing to the discussion
You are literally so incompetent in this area of linkability and fingerprinting and entropy, that I shall in future just always link back to this post when you decide to spout nonsense on FPing, entropy and Tor Browser
formatting truncated a large section which shows IH has no idea what he is talking about
—
THIS ONE IS A REAL DOZEY!!! READ IT PEOPLE
> IH: When you detect that someone lies you are still not able to find out the real values … And the point is that the values are NOT static, but changes per session. “Randomized†in itself is not static
read that again … “Randomized” (in quotes) in itself is not static
Everything can be fingerprinted, including the fact that you randomize per session, or randomize each pass. Even the randomizing can have a fingerprint: such as Brave only alters one rgb channel (among other unique characteristics). All those values are STATIC. “Randomized” or “random” or “fake” or “gibberish” etc are all values that can be returned as a result and used in the fingerprint
also, LEARN TO READ: I said detecting randomness and returning a static value is “NO BETTER THAN” and “THE SAME AS” lowering entropy. No-one said anything about real values leaking
Here is a basic example
All Tor users
– is this tor browser: true
– timezone: “UTC 0”
– devicePixelRatio: “1”
– plugins: “none”
– canvas: “random each pass”
– the fingerprint of those is STATIC: e.g the hash of “true, UTC 0, 1, none, random each pass”
– call it fingerprint T
All Brave users (we can always tell if something is randomized)
– is this brave: true
– canvas: “stealth random”
– plugins: “fake”
– web audio: “stealth random”
– the fingerprint of those is STATIC: e.g. the hash of “true, stealth random, fake, stealth random”
– call it fingerprint B
site X: ten Brave users with fingerprint B visit once each
site X: one Tor Browser user with fingerprint T visits ten times
What does the site see?: it sees 10 visits each from fingerprints B and T. It cannot tell any other differences between them. Flip it: one Brave user makes 10 visits, ten Tor Browser users makes one visit each. So you’re saying now saying the Brave user can be tracked. That’s what you claimed. That’s NOT HOW IT WORKS
—
@Pants
Again, I never said that randomness can’t be detected. That would be a stupid thing to say. Randomization can be rather easily detected because sometimes (not always) it returns implausible values.
> “Randomized†or “random†or “fake†or “gibberish†etc are all values that can be returned as a result and used in the fingerprint
Yeah, but you can’t make sure that it is the same person, it lacks differentiation. Of course the browser returns SOME value but you can’t say with certainty that it is the SAME user.
> No-one said anything about real values leaking
Yeah but you’d need the real values for any kind of certainty re. whether or not it is the same user.
Imagine me speaking very slowly to you:
Your answer assumes that Tor browser do not change default settings. That is not always the case. Sometimes you have to relax settings in order to restore web compatibility. Doing this in Tor destroys your anonymity. Which is why it actually shouldn’t be done there. Tor is a special purpose browser. Firefox is not a special purpose browser, but a general purpose one – Firefox also lacks any kind of protection at the network level by default. Ergo: What Tor does can’t be applied to Firefox 1:1, because expectations are different (one example: user use extensions in general purpose browsers and have high web compatibility expectations). Tor’s and Firefox’s approach has weaknesses to it that randomizing doesn’t have, weaknesses that might lead to de-anonymization if users opt to relax settings in response.
Besides, let’s say your irrelevant user.js offers 100% fingerprinting protection, which it doesn’t, you still think it’s a good idea to introduce new fingerprinting vectors, destroying what you’ve built. Anyway, not my job to fix it. You should accept that a Tor setup can’t be easily translated into a Firefox setup.
Please listen to what I say, and not to what you imagine I say. Listen to M.C. Straver. Listen to the Tor team. Listen for once to virtually anybody.
> Yeah, but you can’t make sure that it is the same person … but you can’t say with certainty that it is the SAME user … Yeah but you’d need the real values for any kind of certainty re. whether or not it is the same user
Which is EXACTLY my point (in showing your ignorance/lies/BS yet again), and exactly what you argued against
You have repeatedly claimed that lowering entropy doesn’t work: see example of user(s) on a single site; 10 users or 1 vs 1 visit or 10 visits etc. When shown that Brave can be reduced to a static FP, you then claim it’s working and Brave is protected. But wait a minute, Tor Browser isn’t protected. Of course they BOTH are because lowering entropy has ALWAYS worked.
Once again: this has nothing to do with real values: read this for the twentieth time: randomizing is ultimately no better than lowering entropy
You have no idea of what you’re talking about and you ignorance is abundantly clear
> Listen to M.C. Straver
Straver is not a fingerprinting expert/researcher (certainly no bodies of work that I can find) and his quote has zero relevance to do with the fact that all randomizing can be detected and returned as a static value. The fact that randomizing can confuse naive scripts is not debated
@Pants
Man, you still don’t get it. Tor’s approach (making everyone look the same) fails because it has web compatibility implications that returning gibberish most of the time wouldn’t have. That is WHY Tor offers several modes – strict, medium, etc. They KNOW – contrary to you apparently – that users would sometimes have to relax the settings because otherwise websites just wouldn’t work. But the point of Tor is anonymously visiting websites first and foremost, so websites need to be able to render at least…
Tor’s common fingerprint can’t be kept easily, the approach is therefore doomed to fail, at least in a general purpose browser like Firefox or Brave. It might work in a special purpose browser where such breakage is expected, but you insist on comparing it with the general purpose browsers Brave, Firefox etc. – this is misguided.
M.C. Straver’s quote clearly shows you that Tor’s approach is not workable from a web compatibility point of view, and is therefore hardly workable from an anonymity point of view. If I can’t render websites, there is no point to anonymity, if I relax the settings, anonymity is weakened / destroyed, but at least the websites render.
>You have no idea of what you’re talking about and you ignorance is abundantly clear
So is your ignorance regarding fingerprinting vectors, for you are creating new ones:
https://www.ghacks.net/2020/12/28/are-you-protected-against-online-tracking-the-effs-cover-your-tracks-site-has-the-answer/#comment-4481987
You were naive enough in a prior discussion to think that extension fingerprinting mainly has to rely on exposed WARs… I mean, how stupid is that? You also claimed that unique extension IDs leaking is non-trivial to achieve when it’s not, even after I showed you that Mozilla devs acknowledge the problem. She who sits in the glass house…
> That is WHY Tor offers several modes – strict, medium, etc
Man, you don’t have a clue how things work. You’re making shit up
The slider is a “SECURITY” slider (that’s it’s name), not a fingerprinting slider. It has nothing to do with fingerprinting. There are a handful of changes as you move between levels: for the record, they are called standard, safer, safest since you clearly don’t know what they are. The fingerprint will change slightly from standard to safer (because a few extra items are disabled). At safest, JS is disabled
So, since you’re such a genius: tell me how (since the default level is standard) the slider RELAXES fingerprinting. Answer, it can’t.
—
> Tor’s approach (making everyone look the same) fails because it has web compatibility implications that returning gibberish most of the time wouldn’t have
When you break standards, there is a potential compat cost
Returning gibberish for user agent causes breakage
Returning gibberish for inner window sizes causes breakage
Returning gibberish for languages causes breakage
Returning gibberish for timezone causes breakage
… and I could go on.
Returning gibberish causes breakage in ALMOST ALL cases
Each metric/API needs to be looked at on it’s own. Brave doesn’t return gibberish for the user agent (because it would break everything), instead it adds a few spaces so parsers don’t have a hernia. Brave has done so little so far there’s fuck all to compare here: but yeah .. you’re talking a load of GIBBERISH
Here’s a fact for you. Tor Browser returns gibberish for canvas and this breaks shit (it’s full on 100% random). Brave does not return gibberish for canvas, instead it is totally plausible (and usable) since they only change a few pixels and only one rgb channel and by one value: i.e perceptibly no change. This is the EXACT opposite of what you’re saying.
You don’t even know what Brave is doing. Show me the list of everything where Brave returns gibberish – come on.
If anything, plausible or common spoofs actually reduce possible breakage. The only gibberish here is the rubbish coming from you.
—
> compat
You’re fixated by one metric: Canvas. Tor Browser **deliberately** chose (years ago when canvas was used less) to not expose canvas to the risk that Brave has: i.e having to protect the random seed because of the “subtlety” of change, and thus needs to be per eTLD+1 and per session. So yes, canvas breaks in Tor Browser: exactly! bingo! Would you like a medal? That’s by design (for now). If the end user needs to, they can allow canvas for that session for that site. I agree this is not ideal, and that subtle randomizing here solves THIS (canvas) compat issue.
But please, list everything else that RFP does that BREAKS websites. Of the other 100 things besides canvas that RFP protects, please name those that break websites. Go on. You keep claiming that Tor Browser/RFP breaks everything.
I’m waiting. Also please show for the 100 things RFP protects, how many spoof plausible values instead of gibberish
@Pants
> The slider is a “SECURITY†slider (that’s it’s name), not a fingerprinting slider.
Naming is totally irrelevant because…
> The fingerprint will change slightly from standard to safer (because a few extra items are disabled).
…the fingerprint does indeed change whether it’s named “fingerprinting slider” or not.
> tell me how (since the default level is standard) the slider RELAXES fingerprinting. Answer, it can’t.
I can relax settings without the slider, in about:config. If someone needs strict anonymity, things break. Hence “standard” being, well the standard setting, to avoid exactly that. My point was that you are trying to apply this to Firefox, which is stupid in its own right, because Firefox isn’t meant to be Tor. Brave isn’t meant to be Tor. What you propose as a good solution is only applicable to Tor. No idea how often I have to repeat that.
> Each metric/API needs to be looked at on it’s own.
Brave doesn’t randomize everything. Randomization is not the best solution for everything, but for some values, randomization does indeed compete with static solutions. Only those are worthy of discussion, unless one is a complete idiot and lists things where randomization was never an option to begin with.
Most of the stuff you listed (user agent, timezone, most languages) is NOT highly unique. Inner window size was literally the only interesting vector here.
> This is the EXACT opposite of what you’re saying.
No, it’s not. They randomize only slightly because if they went all out, this would be the Tor scenario all over again. But there is a “Standard” and an “Aggressive” setting for Brave’s fingerprinting protections and “Aggressive” randomizes more heavily with more web compatibility loss associated.
> You don’t even know what Brave is doing. Show me the list of everything where Brave returns gibberish – come on.
Again, there are two different settings at play here. The default setting does not return total gibberish because of web compatibility concerns, even “Aggressive” can only do so much because of WEB COMPATIBILITY CONCERNS. Brave is a general purpose browser and can only do so much, Tor level breakage is not acceptable here. Firefox is a general use browser and Tor level breakage is not acceptable there, either, unless you are an idiot who doesn’t care about web compatibility and only focuses on privacy, I guess.
Privacy at all costs is for Tor, not for browsers like Brave and Firefox. Please understand that.
> The only gibberish here is the rubbish coming from you.
What you come up with is not exactly high quality, either.
> exactly! bingo! Would you like a medal?
So I was right for once, basically. Cool. Can do without the snark, though.
> But please, list everything else that RFP does that BREAKS websites. Of the other 100 things besides canvas that RFP protects, please name those that break websites.
You are literally asking me to go through 100 RFP protections one by one, listing what they break, provide sources etc. in a gHacks comment? LOL, nope. Certainly not. You don’t put that much effort into your own comments (or into your whole project, for that matter) either, so why should I? I won’t do any more than you do here. I don’t need to prove that every single FP protection breaks stuff, because a) I never claimed that to begin with and b) a few items breaking things would already be enough to prove my point.
Since you are asking, some stuff that is bound to break websites:
– Canvas.
– WebGL being turned off.
– Font fingerprinting mitigations.
– Timezone.
– Language.
Those are enough to break a sizable amount of websites already.
> You keep claiming that Tor Browser/RFP breaks everything.
I didn’t say “everything”, don’t be foolish. I said that many things break, but not every website uses the associated features.
> I’m waiting.
I’m waiting for you saying something of value here. All you do is bickering about Brave’s protections, how they are inadequate (by comparing a general purpose browser like Brave to Tor, haha, because no way there could be different expectations at play here), how Brave’s FP protections are incomplete (because they are about a year old, but whatever) and so on and so forth. Combine all this with not caring about web compatibility implications and a failure to understand that Tor is not the same as Firefox and that Tor’s settings can’t be applied to general purpose browsers like Brave / Firefox, and what you get is Pants.
Pants, go back to your copy & paste project (as an aside, if I wanted to use arkengem, I’d just use the Tor browser without connecting it to the Tor network – amounts to roughly the same thing, provided that I ignore your stupid advice to introduce new fingerprinting vectors via extensions), it needs your attention. I did never ask for your attention nor does it provide any additional value here. It’s just annoying, what is your purpose here even? You attempt to prove me wrong by coming up with wrong assumptions and stupid premises (that you claim come from me somehow, while it’s actually you who crafts them), but it’s only tiresome and ineffective, give it a rest.
@Pants
> Tor Browser/Mozilla devs, thousands of researchers + papers + phDs, tens/hundreds of thousands of tests, thoroughly vetted etc: including real world tests
> Iron Heart
I know that you like to craft this type of either-or question in order to make me look stupid, but there is one major problem: The very premise is wrong (perhaps deliberately so).
Tor, Mozilla, and other “authorities” do not deny that Tor causes breakage. Quite the contrary. For your “either – or” question to make sense, they’d have to state something different from what I say. They are also agreeing with me when I state that changing Tor’s default settings will destroy anonymity. What can be inferred from that is that Tor’s approach won’t work at all if you rely on web compatibility (as you should, at least in general purpose browsers), because to restore such web compatibility, users sometimes have to relax the settings. Brave’s approach does not destroy web compatibility as much as Tor’s, it’s a FACT that is not contested by Tor or you or anyone else so far. The Tor approach costs them web compatibility more heavily, but again, Tor is a special purpose browser and it’s more or less expected there – “nature of the beast”, as you would put it.
> Dude, it’s totally sweeeeeet as F for 90% of web surfing.
Highly doubtful. Ask the Tor subreddit if they think that it’s a general purpose browser. Or even the Tor creators and devs. They’ll all tell you that it’s not a general purpose browser for more than just one reason.
> “Returning gibberish is the only non-breaking solution†you said about plugins:
I didn’t mean plug-ins specifically which are a dying technology (so you can safely report that they are not present to websites without repercussions, lol), I meant this as a general assessment. Disabling features websites actually use causes more breakage than returning gibberish while keeping the features enabled. Again, Tor is NOT a general purpose browser. They’ll more or less prioritize privacy over web compatibility each time. You are dumb enough to try and apply whatever they do to the general purpose browser Firefox (which also lacks some vital patches Tor applies in addition to modifying settings. sometimes they are the very reason WHY they modify settings), which is being used with totally different expectations, just think about that. One of the main reasons why you shouldn’t be taken seriously.
> Feel free to drivel when you’ve sorted out the fonts, screen, window, timing and the 80+ other things Brave lacks parity in.
Uh, oh. Brave lacks behind, it comes years after Tor started working on their protections and after Mozilla copied Tor, even you acknowledged it before:
“This is just a fact, as it will take them [Brave Software] years to catch up due to the nature of the beast: and that’s even assuming that they can (…)”
Now, when it’s convenient to you. it’s suddenly a problem / proof of the supposed ineptitude of Brave’s devs. Make up your mind. A solution that is less than one year old is not expected to be perfect, Tor needed more than one year for their stuff, too. I assume you are applying one rule for Firefox and Tor and another for Brave, as always…
> A second poison pill may prove useful. You certainly don’t need to randomize everything
You need to randomize all values that have a realistic potential to be highly unique at least.
> I have to because your knowledge is so inept.
Ah, and your “knowledge” is apt when you are so concerned about fingerprinting in your irrelevant script, trying to cover all possible vectors, only to go ahead and introduce new ones:
https://www.ndss-symposium.org/wp-content/uploads/2020/02/24383-paper.pdf
I can fingerprint extensions based on their behavior even if they don’t expose WARs (web accessible resources). In one of your former rather dumb comments, you went on and on about WARs and how extensions like uBlock Origin take their precautions against that, when I can still reliably fingerprint them just by exploiting their behavioral patterns, by trying to trigger those patterns. The combination of extensions is rather unique for most people and would be a strong identifier. Now look at this:
https://github.com/arkenfox/user.js/wiki/4.1-Extensions
That’s you rather stupidly introducing a highly unique fingerprinting vector. Now, let’s take a look at what the Tor browser team, i.e. your demi-god experts, have to say about that:
“It’s strongly discouraged to install new add-ons in Tor Browser, because they can compromise your privacy and security.
Installing new add-ons may affect Tor Browser in unforeseen ways and potentially make your Tor Browser fingerprint unique. If your copy of Tor Browser has a unique fingerprint, your browsing activities can be deanonymized and tracked even though you are using Tor Browser.”
source: https://support.torproject.org/tbb/tbb-14/
If people use your poor man’s Tor imitation, thinking they’ll be safe from fingerprinting, a highly unique fingerprint will be the actual result. And remember, it’s not only about WARs, and Tor knows that, while you obviously don’t.
So, guess who is right?
– Tor Browser/Mozilla devs, thousands of researchers + papers + phDs, tens/hundreds of thousands of tests, thoroughly vetted etc: including real world tests
– Pants
> You quote a so-called “expert†and his quote isn’t even useful or meaningful in this discussion.
You shouldn’t put “expert” in quotation marks unless it applies directly to you, lol. You do not understand how these protections work at a deeper level, all you do is looking at test suite results not telling you the whole story.
Straver knows that the “make all people look the same” method will fail because of the web compatibility implications, forcing users to ease some of the default settings, quoting him again:
“TOR browser may have additional anti-fingerprinting measures, but the inevitable drawback of it at the same time is that it will cripple the web by disabling features that are in use by websites for good reason.â€
source: https://forum.palemoon.org/viewtopic.php?f=13&t=17211&p=126017#p126017
…which is why:
“(…) ultimately, making yourself unique, and making yourself unique every time is going to be the best way to fool trackers. How exactly you do that without crippling yourself is a different question, of course, but not in any way more difficult to answer than the question how to blend in without crippling yourself (because using nothing but default settings is crippling too).”
source: https://forum.palemoon.org/viewtopic.php?f=4&t=14813&p=106585#p106585
What Tor does is only workable in a special purpose browser where privacy always trumps web compatibility (and where users hopefully do not change the default settings or install extensions). It is not applicable to Firefox even though you try exactly that in your wannabe Tor-alike setup (while at times ignoring explicit advice the Tor team gives, funnily enough).
> you agreed
I can’t remember agreeing with you!? Point me to where I supposedly agreed with you.
> You are literally so incompetent in this area of linkability and fingerprinting and entropy, that I shall in future just always link back to this post when you decide to spout nonsense on FPing, entropy and Tor Browser
Yeah, do that (I know that you have a complete protocol of every post I have written here so far, which in itself says a ton about your obsessions and control freak nature – help, I am under total surveillance by the privacy advocate!), people can then also read about the highly stupid ideas you come up with re. fingerprinting just below it. It’s not the only stupid suggestion you come up with in your arkengem setup, but that’s another story entirely. Presumably you don’t know the difference between privacy and anonymity. I am trying to come up with privacy setups, you aim at anonymity apparently, but still end up with a privacy setup in the end. When you are so concerned about fingerprinting (which is related to anonymity), then why are you introducing new fingerprinting vectors? An advanced script that checks for more than Canvas will overcome your foolishly crafted setup, I tell you that.
*Tor is NOT a general use browser of course. Damn, too early in the morning for bullshit discussion to be had…
The one that gives me the most uniqueness is Platform with Win64 (One in x browsers have this value: 227.38). Is everyone using that site still using Win32 or something? :)
Using Brave, all is secure.
Using Chrome. For ideal results I would need an anti-fingerprinting extension. Otherwise OK.
Using IE InPrivate, the test fails to complete but I have a mental image of a lapdog lying on its back exposing its belly to a wolf pack.
EFF isn’t the only one to offer this type of service. They’re probably of some value to those unfamiliar with all the ways you can be identified but results have to be taken in context. The more you block trackers, etc, the more unique you become but you get better privacy. As you let more trackers function you become more generic. The more extensions you have, the more unique you become. Your browser and OS have advertising ID’s. And so on.
If you use anything but Chrome, you’re in a subset of 1/3 of users automatically. Use Tor Browser (Tor is the relay system) and you have great privacy but are in a very small pool, a private pool but Tor Browser is awful for general browsing and your provider knows you’re using it.
If your IP is visible, none of this matters, you are identifiable. And have to be for your requests to be answered. Use a VPN and your real IP is hidden but you’re unique to the pool using the VPN’s IP’s although it takes a ton of effort to ID through a good VPN.
You really have to determine what your threat model is to be and act accordingly. Ads dramatically slow browsing so we block them along with trackers, web RTC (except on laptops that use video calling) etc. with a system level blocker outside our browsers. My real IP is visible (my provider’s actually) unless I turn on a VPN. Malware and phishing are taken care of by our AV (NOT Defender, btw.)
We are probably very unique but browsing is fast, streaming is smooth and no ads anywhere. On Android, the spread your info around approach is fantastic, no ads in apps or anywhere else, makes using a phone almost enjoyable and everything still works. With webRTC enabled (all Chromium browsers), you are easily identifiable no matter what you do.
I wouldn’t get too hung up on getting a great value on any of these tests, makes more sense to use your results to develop your particular scheme.
:)
do not be afraid of hacking if your account is in a decentralized eco-family utopia
Because Canvas is no longer spoofed as ‘Tor Browser’ fingerprint (blank white image) @privacy.resistFingerprinting. Canvas is now randomized simular to the extension CanvasBlocker except that RFP (resist.Fingerprinting) covers way more. These test sites will show that you are unique but you’re still blended into the
RFP crowd. CanvasBlocker covers DomRect, webgl, and audio but these can be disabled in about:config also which will raise your entropy and change your fingerprint slightly but again, we’re all unique anyway
This article would have been acceptable to me if the title was:
Are you concerned online tracking? The EFF’s Cover Your Tracks site addresses this issue
Brave browser with recommended settings of Iron Heart w/NoScript:
Passes all three
Brave browser with Cookie AutoDelete installed:
Passes the first two, but only partial protection for fingerprinting.
It would be nice if Brave could delete session cookies on tab closing.
Abrowser:
https://i.ibb.co/Yf9d4bc/firefox.png