Closed maureenferreira closed 6 months ago
what makes you think your fingerprint is "extremely unique" (is there such a thing, literally impossible)
just because some tainted data set on a test site with very limited tests says so?
also
And unique does only matter if stable.
what makes you think your fingerprint is "extremely unique" (is there such a thing, literally impossible)
just because some tainted data set on a test site with very limited tests says so?
Because the tests are recommended in the wiki. Did I misunderstand something?
And unique does only matter if stable.
What do you mean by this?
also
* read the wiki about how fingerprinting works and what you can expect in Firefox (i.e not Tor Browser, not Mullvad Browser) * also see [Firefox, with slightly modified Arkenfox, fingerprinting with latest 124.0.1 64 bit update breaks, now "unique" #1821](https://github.com/arkenfox/user.js/issues/1821)
I'm not sure which wiki entry you're referring to.
And unique does only matter if stable.
What do you mean by this?
It means unique is ok as long as your fingerprint changes over time, e.g. everytime you restart firefox.
One of questions you have to ask is what is being tested and how is it being tested. So for example amiunique doesn't detect random canvas, but coveryourtracks does. RFP randomizes canvas every read - so amiunique will always report that your fingerprint is unique (as in no-one has ever seen it before). But coveryourtracks does (via third party testing) and will always report that canvas is "randomized", so since RFP doesn't change anything else (all things considered, e.g. don't zoom or change settings), then it will produce a "stable" result
So just because a site says unique or x in y doesn't mean anything unless you understand what and how something is tested.
On the same vein of thought ... coveryourtracks can report fonts as "randomized" due to async font fallback - which is entirely BS - i.e firefox caches font fallback info per firefox session .. so on the 1st party if the fonts haven't fallen back yet in the session they are not detected, but on the 3rd party they have (because the 1st party forced it)
So that's the third point - do you know the tests are reliable
and then there's points 4 to 93 which one day I might explain
So just because a site says unique or x in y doesn't mean anything unless you understand what and how something is tested.
On the same vein of thought ... coveryourtracks can report fonts as "randomized" due to async font fallback - which is entirely BS - i.e firefox caches font fallback info per firefox session .. so on the 1st party if the fonts haven't fallen back yet in the session they are not detected, but on the 3rd party they have (because the 1st party forced it)
So, if my understanding is correct, you're saying that, while certain tests can produce valuable information, it doesn't mean they always will, as sometimes the information they produce is based off unrealistic data points which wouldn't necessarily be measured or tracked the same (or at all) in the real world?
So that's the third point - do you know the tests are reliable I assumed, possibly somewhat naively, the tests listed in the wiki are reliable.
So I revamped the wiki a few years ago but haven't gotten around to adding something here in the Foreword
see this old wiki page .. the second paragraph starts with If you don't use RFP, then you're on your own. And don't rely on entropy figures from test sites.
The whole point is that I haven't have gotten sick and tired of explaining fingerprinting over and over and over (that's not anyone's fault for asking), so in the wiki revamp I laid out some basic rules on what FP protection basically entails and above that is what RFP does and what you should expect. And I split that old wiki data above - the FPing extension stuff stayed, and the rest was to go in the foreword on the FPing tests page
But I've never gotten around to it. Part of it is because I just want to link to an article. And that article would be a arkenfox/blog repo .. while in the meantime I am deep in the weeds with Tor Project and for the last year we are meant to be re-writing the tor browser design doc. And I am meant to be doing the fingerprinting part - and at the same time Mullvad Browser keep getting questioned by users (and I'm on tap to them 24/7 to help) .. and long story short .. I have a plan to come up with a series of articles (or one long "interactive" one [1]) that outlays it all, in simple terms with subsections for each "rule" or premise that you can dive deeper into. And the simple parts make the Tor Browser design doc (which is a fucking mess and lots wrong with it - the FPing bits that is, the rest I am not qualified to comment on)
but time is valuable, and I hate writing shit - and it's not that easy to write when you think about what I know would fill books .. indeed, books have been written. That said, I need to get a wriggle on and do it
🟥 https://github.com/arkenfox/user.js/wiki/5.2-Troubleshooting
maywill be closed as invalid (this doesn't really apply to my issue)🟪 REQUIRED INFO