general discussion on FPing: have at it

[Thorin-Oakenpants]

@ilikenwf rather than spam PTIO's issue .. here is your own issue. Don't spam #350 , and please stick to the topic. I've unblocked you. The reason I blocked you was because you went OT and starting ranting about Mozilla etc. That's always a sign that the poster is waste of my time. However, if you are rational and don't go too OT, then I will explain all the points you don't seem to understand.

What you brought up was the ability for RFP to let extensions handle canvas (I assume behind a pref: default not to let extensions handle it, as Firefox doesn't come bundled with a canvas extension - but the implementation is not important). And I said that diverging from the RFP set of users was not a good move.

This has nothing to do with comparing methods for defeating FPing, or test sites like Panopticlick, but have at it.

[Thorin-Oakenpants]

@ilikenwf .. so .. no show then?

Don't you want to know why panopticlick is "wrong" (well, that was your word: to be more precise: why the entropy figures should edit: shouldn't be "relied on")?

Closing as invalid

PS: FYI RFP now randomizes canvas

[ilikenwf]

Actually yes, but I'm working on a backlog of work...

I want to know what is, at least according to your work and experience, the right way to go about things and why - the why being the big part because most of the places I read about this kind of thing, people are talking out their asses.

[Thorin-Oakenpants]

That's cool then. When you're ready, ask away (and give me examples of "most other places", because context is important). I don't blame people for not knowing: and it's an easy assumption given that sites like amiunique and panopticlick give an entropy figure, but more importantly that.they state x out of y browsers.

I'll fire some quick general points here

• a metric is what I refer to as a single data point
  • that could be a subset (e.g. all screen/window measurements) or an individual point (e.g. available screen)
• no-body knows (or is sharing) any good statistical real-world entropy figures (of any given metric), although I bet someone like google or fb or some other very large 3rd party could do it if not already: i.e super large sample size: one result per sample.
• when scientifically looking at a metric, you have to ignore all other metrics. It's pointless trying to combine them all, because no-body knows (see previous point)
• so when combating FPing (of which there are at least 8 possible slightly different methods) TB and RFP have an advantage (kinda): they are a closed set where the anti-fingerprinting is enforced. This means everybody should be the same, or be in one of a number of "buckets", or have the same behavior (e.g randomizing)
  • this is not hard to prove mathematically: so there is no need for a real-world assessment: or large scale RFP/TB assessment
  • e.g. all TB users return window.devicePixelRatio = 1, so that metric is rendered completely useless: entropy is 1
  • but if you looked at something like amiunique (not sure if they have devicePixelRatio) or did a real world study of all users: it would say otherwise: i.e devicePixelRatio has entropy and is contributing to your FP: this is true to a degree: but TB and RFP doesn't care about the rest of the world

So, what I'm kinda saying is that e.g TB users are already in a small set of say two million concurrent users: it's how FPing stacks up in that set that actually matters.

When a user breaks from the FP protections of RFP/TB (lets say they randomize canvas instead of spoofing [edit: as a white-canvas]), then that very small group of two million is now splintered into one group of 1,999,999 users and a single user for that one metric (I'm not looking at the rest of the world, TB users are already an easily distinguished group). When you combine the other metrics (e.g. are-you-TB: true/false): that single user is unique not just to TB users, but everywhere

If that still doesn't make sense: I'll put it this way. You cannot hide your browser (TB, FF, chrome, safari), so it only makes sense to tackle and understand FPing metrics per browser

• e.g. TB users make up 0.01% of all users [edit: that's a made up percentage for this example], all TB users report devicePixelRatio as 1, therefore on this metric worldwide, TB's is 1 in 10,000
• ^^ except in reality, worldwide, lots of other devices/browsers report the same: but no-one cares about outside the enforced set (you can never hide that your are TB, or FF etc)

The KEY here is simply numbers: when TB has enough numbers then the buckets become less important

• TB users report a different OS in navigator properties: 1 of 4. The spread isn't even: it might be 30% windows, 10% mac, 40% linux, 20% android (no-one knows but tor project downloads might have an idea)
• that means with 2 million concurrent users: there should be plenty of users the same on that metric
• now add in language: TB prompts for non en-US builds in they want to spoof as en-US (not the application language, but what they ask for from web sites etc). But not everyone will. So some users will be any one of 34 other languages. The spread will not be even
• now add in font FPing: there will be differences for windows users based on what flavor and version windows they installed (despite the font whitelisting) - lets say 5 different FPs, and lets say Linux is 20 groups
• now add in window size, some will be 1000x1000, some will 1000x900 etc - lets say the majority is in 4 groups

Every metric can overlap: so overall (from the above) something like 35 languages x 25 fonts (over all OSes) x 4 windows = 3,500 different possible FPing buckets. Not all will have someone in them, IDK for sure, but lets say they did - the distribution wouldn't be even - but hopefully, the user wouldn't be unique. As soon you stray (resize the window to be e.g. 1600x900) you drastically start to lose your "herd immunity", now randomize canvas instead of spoofing a white-canvas = bingo: you lose.

Note: I did not add the 4x for the 4 OSes: that's because the font fingerprinting already covers it. OS is not a good example: because you can't hide your OS anyway [windows, mac, android, linux]

Can you see now?

If you want, I can show you how the entropy etc figures on panopticlick etc can;t be relied on.

PS: soz for the long ass rambly post
[edited: to add note about the 4x buckets of OS]

[atomGit]

RFP now randomizes canvas

sorry to jump in pants, but i wanted to ask whether CB is still substantially beneficial in your opinion ???

[Thorin-Oakenpants]

RFP has stalled: some new features are being covered (e.g prefers motion, etc), and a few older tickets have been addressed (e.g LBing), and Mozilla devs are all very aware of FPing, but most outstanding issues haven't been tackled yet. RFP is incomplete, and there's only so much that can be done without wholesale breakage. Also the Tor Uplift team was discontinued - but that's not to say (see first sentence) that work isn't ongoing.

Looking at FF users only...

---

Everyone is in the shit on this one: font protection

there is 1. the whitelist, but 2. fonts aren't bundled and the whitelist is not used: this is due to:

• lack of data to make decisions: who has what fonts on what platforms, what languages are involved (even TB's whitelisting is very old and needs updating). TB has 35 languages, but FF supports way more than that.
• size constraints: when Moz devs are fighting to keep sizes down and having issues/arguments on how to save 300-500kb (not to be sneezed at, just saying) [see 1], no one wants to add MBs of fonts to packages or even deal with the bandwidth of getting them remotely. [1] 1612379
• "politics" or "point of view" for lack of a better word: not that it has ever arisen since the last step of whitelisting+bundling hasn't really gone anywhere: By that I mean that the font people are really picky about looks (fair enough) and it would be a bit of a battle to decide on things like CJK
• given all the above, it's not that important given that the TOR uplift is for TB, and TB does whitelist and bundle some fonts (it's not perfect but at least bucketizes)
• luckily us FF users can use the whitelist (I do, it hides my MS office and adobe photoshop fonts for example) ... and there's always blocking document fonts (and we're not TB, so we can do what we like)

fonts is a mess, and the only solid solution is to bundle everyone with the same fonts (same list, same versions) per platform (you can't hide the OS). Even then, Safari tried and found that had still had to provide different lists of system fonts based on user's languages.

• meanwhile, Mozilla are getting telemetry on system vs installed fonts etc and trying to build in a similar system to what Safari did: this is outside of RFP so all users can benefit.
• there are a bunch more tickets in about all this, and surprisingly, they are from the "font people"

---

first of all, RFP measures are way more solid since they're handled in code, e.g. workers (there's no web ext ability to spoof etc in workers: you leak in any metric workers have access to: such as navigator and soon offscreen canvas)

CB:

• canvas

  • at least if you allow a site exception, you can still fake
  • now RFP fakes, but I don't know the difference between CB fake and RFP fake and I don't know how this affects things like whatsapp (QR code showing, or being able to upload an image)

• screen (RFP has you covered)

  • not really all that important but kkapsner implemented what I think is a better solution
  • since most scripts only look at screen, you can spoof the results on a sliding scale of e.g. the 5 or 6 most common metrics. This would reduce screen metrics to e.g. 5 buckets, not the the 50 or so with LBing. This would also protect that metric for those who disable LBing.

• UA (RFP has you covered)

• audio

  • RFP does offer some protection, e.g for audioContext: outputLatency, sampleRate (CB doesn't AFAIK), and the rest of audioContext, I think is not much entropy (but we need some telemetry to confirm), e.g. it seems like smoothingTimeConstant is 0.8 for almost everyone (in which case we should always enforce it for outliers) - i.e. it needs more investigating and patches
  • CB spoofs the manipulation of using the API (getChannelData etc)
  • There is a bugzilla and PoC to randomize some/all(?) of what CB does: we just need to wait for Paul to pull the trigger
  • but of course, we can just block the web audio API

• history (length), window (opener, name)

  • i don't consider history to be an issue. Window - nice to have I guess if you use CB: saves using a script etc.

• domrect, textmetrics, webgl

  • RFP does protect some webgl data (e.g unmasked...) but that's it
  • we can of course disable webgl
  • it is these last three that I see CB offering something of REAL value

---

tl;dr: personally, I would only use CB for the domrect and textmetrics (and webgl and audio if I ever enabled them: so far I never have) and for the fallback canvas fake (but I've never had to allow canvas exceptions). But that's my usage and everyone will get different results.

Yes, I do get breakage, but it's only for one off sites: and I just use any one of multiple FF portables I have in my test suite (but usually my Nightly). All my test suites fully sanitize on close. I think people underrate compartmentalizing: no one makes me change my core FF which is tighter than a nun's ass :)

Personally, I don't use CB though, because FP scripts should never get to run: uBO is fairly tight with no 3rd party and uMatrix is in nightmare mode. There is always 1st party FPing and 3rd parties I allow per scope: but the risk is low - things like domrect and textmetrics are not used in boilerplate FPing scripts (and all those FPing parties just like to use drop-ins like fpjs2: they're almost all the same in what they target, and it hasn't changed much over the last 2 or 3 years - see this), and I have the rest covered. That linked list above is the fingerprinters list - but if you were to get all those scripts and de-minify and unobfuscate them, they're all fairly similar and limited. Also, CB messes with my testing :)

It really comes down to the user's threat model: but if I was to recommend one extension for anti-FPing, it would be CB - it covers some things no-one else does including RFP, you can enable/disable spoofing per API, and kkapsner is very accomplished, knowledgeable and thorough. It's a great extension, IMO

PS: soz for the massive rambly post (again)

[Thorin-Oakenpants]

re-opening since I haven't explained yet why sites like panopticlick's entropy can't be relied on

also ... on RFP canvas spoofing: there are differences with CB (I guess depending on CB settings: e.g stealth mode?).. RFP doesn't care about stealth: re-running tests (i.e not reloading the page) gives a new RFP randomizing, whereas CB doesn't. Also RFP doesn't randomize isPoint* (they still use the white-canvas) - I don't think that's important (certainly not as a leak), but it is a point of difference

edit: I need to double check that isPoint statement: so don't take it as gospel

Update: Yup. IsPoint still uses the white-canvas. If you have 78+ with privacy.resistFingerprinting.randomDataOnCanvasExtract in about:config, you can test it here at TZP and also at CD test

my test assumes you updated nightly 78 to the latest and that random pref exists: RFP is green if RFP is on (my sneaky 1ms check) and a second test hash differs - otherwise it's red cuz now you differ from the herd. Flip the random pref and test it again, you'll see :) Anything prior to 78 uses the white canvas hases to determine if RFP is working

[atomGit]

thanks for providing a comprehensive answer to my question

unfortunately there is no yes or no answer, but given the current state of RFP it seems that the need for CB has decreased even more than the last time i checked, just a few months ago

given the few (but interesting) advantages of RFP over CB, i'm quite inclined to drop CB from my config guide (at least as a 'required' ext.) despite the losses

not happy to hear that RFP has stalled and the uplift is dead, but it is what it is

thanks again - your knowledge is impressive

[Thorin-Oakenpants]

not happy to hear that RFP has stalled and the uplift is dead, but it is what it is

Uplifting is edit: isn't dead - , it's just internally, however these "teams" collaborate, the uplift one doesn't really exist anymore and devs who are in multiple teams anyway, simply move where they are needed - but there's still lots of little things that do still get put into FF code for tor project. It's just that there isn't much more to do in terms of upstreaming AFAIK (the more they do though the better). I saw a tor ticket about rebasing, and the list of patches wasn't that long: most of it is about tor protocol and their own UI changes. They might even shrink that more when they move to using stable instead of ESR.

[ilikenwf]

This is shaping up to be a really really valuable informational post. @Thorin-Oakenpants thank you so much for humoring us here.

I think it is a large problem that nobody is sharing any useful data, but it makes sense because of the monetary value of such a thing. Even if Mozilla were to share it's own data, it would be biased towards Firefox users...but maybe enough to let us see what can be done to standardize the browser footprint/fingerprint better between everyone without breaking features.

Perhaps we should come together and build a site that lets people voluntarily get fingerprinted, and we can, other than IP, share that data with whoever so that this fingerprinting problem can be better understood and mitigated? We could allow people to comment/note on their own fingerprints what user.js customizations, addons, settings they're using so that we can better grasp it all?

So far I've been attempting to blend my own browser in, mostly, with TB - and have mostly succeeded there, and while it plus an IP is enough to ruin privacy, it does make me unremarkable...for fonts, I've copied TBB's settings for Linux, for example, and added it to user-overrides.js...I can share some of the highlights of my customizations, if anyone is curious.

Since I also block ads that alone is another source of measurement.

I almost feel like some kind of new paradigm needs investigation to find the right balance between privacy and usability, that or we just need stronger privacy protection laws to prevent abusive measures by corporations. Governments do what they do but I fear big G more...

In regard to entropy I appreciate you description. It almost makes me feel that short of using basic measures and not purposefully standing out, that it's otherwise a lost cause to try and improve on defaults unless the improvement is in an update and applies to all users of Firefox and it's family...

For the uplift and RFP work, perhaps the community can pick up and help with patches to work on the roadmap? I mean...ghacksuserjs is probably the most aware group for such a thing.

[Thorin-Oakenpants]

Even if Mozilla were to share it's own data, it would be biased towards Firefox users

No body cares about other browsers: as in, it only matters how FPing is done within Firefox (for all users, or for a set of users: e.g. RFP). If you wanted to extrapolate that, just multiply it by the percentage of users worldwide who use FF.

Tests like panopticlick and amiunique are good for getting the number of buckets. In order to get the real entropy in a set, you need the distribution: i.e only get a single result from each user. Mozilla can do this via telemetry (for buckets: e.g I mentioned telemetry being gathered for system fonts) and studies (for distribution).

So imagine if Mozilla pushed a study to grab audio FPs (context, oscillator etc) for 1% of users. That there is pure gold: 20 million single one off data points: and shield studies can push special powers to get the real info, not info that is spoofed.

I have been pushing (and working on: but I'm not a JS wizard: I retired a long time ago and my career skills lie in data) for a FPing site that can do just what you say: it only allows FPs to be submitted by FF. The FP distinguishes between FF and TB (so this also lets us investigate the effect of RFP).

It could even be that the site is a mozilla domain, and they give that domain special powers - and a shield study could use it to push an auto-submit (obviously the shield study needs human interaction to say no PII, click here: and the data is sent to the backend database). That is visitors to the site have their data tagged as a visit, but shield study data is tagged as one off.

So one backend, one front-end, shield-studies leverage the backend: backend can do data analysis: drill down into TB, or FF, or RFP users, or all, by metric, by type (visit, study number), etc.

Beats the fuck out of guessing :) Although, we already know what needs "fixing", and for most we already know what the answer is. What we don't know is how damaging (entropy) each one is or even how many buckets: because, no decent FF only data, and no good stats on distribution.

Have you not seen TZP?

So far I've been attempting to blend my own browser in, mostly, with TB

You can't pretend to be TB ... but I understand what you're saying. RFP does most of that. Outside of that, depending on your platform, you can whitelist the fonts (just check what TB sets it as on your platform: it may contain non western ANSI (I think that's the word, i always use the wrong one chars, so be aware of that for a user.js), disable audio+webgl and you're probably good to go. Things like domrect and textmetrics aren't really in the wild AFAICT. And control what runs in your browser (uBO, uM) and you're probably safer than a nun's ass.

Don't overthink it: fingerprinters in ETP is the first line of defense. uBO + uM the second. After that, if a FPing script runs, RFP and pref tweaks for APIs is your third line of defense - but don't be fooled: if they wanted to, you're unique. However, most scripts are not that complicated, and basically covered by RFP/pref tweaks

[Thorin-Oakenpants]

otherwise a lost cause to try and improve on defaults

Not really. There is a w3c for standards and a FP framework - and standards are always evolving. No just new standards: e.g discussions on client hints, but also on phasing out and dropping old ones. Mozilla is very much involved here, and very aware of FPing and privacy. Even chrome devs are pro privacy - not everyone is "evil".

While chrome has ulterior motives (they're owned by an advertising company, so it's in their best interests to track individuals), they do have some good ideas. And they can code chrome itself to allow their own tracking regardless of standards (which they already do): i.e they don't really need to try and "manipulate" standards (speaking generally of course: obviously shit like manifest 3 sticks out) and in fact I would say that it's in their best interests to promote anti-fingeprinting/privacy as it hampers their opposition: for example their FP-API limit thingy: i.e request screen size = 1 point, every request for 10 fonts = 1 point, extrack canvas = 3 points, etc = sites are limited to 15 points and then the returns are undefined.

So changing standards is one way, but RFP is a shortcut: i.e it breaks standards. For example, RFP returns inner sizes for outer window dimensions. It doesn't break anything and is a bit of a legacy that websites no longer use for functionality. Therefore, mozilla can push that upstream to get the standard dropped: i.e no longer supported. The same can probably be said for outer window positions (who uses that for functionality?). Inner window positions and screen positions are a Mozilla thing (chrome returns undefined), so they can probably be dropped as well internally in FF. In fact, all that is in a bugzilla and being worked on

It's just zero priority for RFP, since RFP handles them - but for all users, Mozilla can promote cleaning up old standards (as well as removing their own proprietary things)

[Thorin-Oakenpants]

anyone want to know why entropy and stats from sites like amiunique etc are unreliable?

[ilikenwf]

Go for it...but I would assume that there's a bias issue?

…

On 5/17/20 10:20 PM, Thorin-Oakenpants wrote: anyone want to know why entropy and stats from sites like amiunique etc are unreliable? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOSVCM7XMHHZK3SI23LRSCSP7ANCNFSM4NAIKPJQ>.

[Thorin-Oakenpants]

bias: yup, in a number of ways. There's other issues as well, such as the time frame (which amiunique and pantopliclick have changed or allow a time frame: but it wasn't always that way: other entropy sites, IDK), not to mention the tests can be limited and/or faulty. And sometimes the logic just isn't smart enough (but there are changes: such as pantopticlick now detects canvas randomness where possible = a more smarter stable FP result)

I wrote this Wiki: Anti-Fingerprinting Extensions... F&%K NO!. The last section sums up a little of what's wrong with entropy from these sites. I can't be bothered explaining more in depth

[ilikenwf]

Ok, given and granted everything, what would you suggest, just using ghacks user.js, and certain addons?

That is to say, what strategy do you suggest for the right balance of fingerprint resistance (or blending in, either one), and usability?

[ilikenwf]

In addition, I don't see this happening to my browser, however it may to others...quite interesting and evil...when this method works it would bypass the firewall.

https://nullsweep.com/why-is-this-website-port-scanning-me/

[Thorin-Oakenpants]

Ok, given and granted everything, what would you suggest, just using ghacks user.js, and certain addons?

ghacks user.js doesn't enforce default values for prefs that can mess with RFP: i.e section 4600 is commented out by default, and the prefs for privacy.window.maxInner* just above that section. So it's important that users are aware of that and reset them if using RFP.

RFP is the only known set of enforced users - this is the way. Everyone else is just guessing.

But anti-FPing code is the last resort. My recommendation is to ramp up blocking 3rd parties etc: ETP fingerprinters list, uBO, uMatrix. Have RFP on as the best solution for fallback. And then if you want, CB offers domrect, textmetrics etc. Also audio, webgl if you enable those in prefs. Go for it.

At the end of the day, you'll still be unique if scripts dig deep enough. So don't overthink it

• e.g. personally, I open my browser and use it at 1600 x 900. At 1000 it's just not usable enough for me, but I also understand that in my setup, being FPed is highly unlikely, and that most real world scripts only grab screen (not inner), so at least that way, I have some fallback on that one metric.

--

Outside of the browser, compartmentalizing is good. Use Tor Browser when it fits, use secondary browsers (don't compromise your main FF setup).

I do. I have a portable Opera, a portable Chrome, and 23 portable Firefoxes for testing from ESR60-68, thru 59 to Beta, Dev, Nightly : all for testing. They're practically vanilla profiles with a few tweaks (no updates, sanitize on close). Nightly I added a few extensions for testing, but only uBO is on by default - I use NIghtly as my main one off, as it's easier to run concurrently with other FF's.

I also have six main TB's (32 + 64bit ESR60 finals, stables, alphas) and 34 other languages in alpha (I'm really pushing hard to find app language leaks: I have some, but not sharing)

So for me, if anything is unusable in my main FF that I can't work around (e.g. I don't give a shit if the css breaks when reading an article, or an icon glyph is missing) then I have a plethora of one off options :)

[ilikenwf]

In addition, I don't see this happening to my browser, however it may to others...quite interesting and evil...when this method works it would bypass the firewall.

https://nullsweep.com/why-is-this-website-port-scanning-me/

ubo can mitigate this, see netblue30/firejail#3427

Thanks to @rusty-snake for the tip:

||127.*$third-party or 
||127.0.^$important,third-party) 
and
||localhost^$important,third-party```

[rusty-snake]

||127.*$third-party or
||127.0.^$important,third-party)

I did some testing:
better: just ||127.*$important,third-party and ||localhost$important,third-party

NOTE: this will breaks 127.example.com too.

[gwarser]

For localhost: https://github.com/gwarser/filter-lists/blob/24c8aaecbaabe62d74aca02dab08aa89ba2e4624/lan-block.txt#L26

Discussed here uBlockOrigin/uAssets#4318 about blocking access by HTTP to local resources, for example router or modem interfaces.

[ilikenwf]

For localhost: https://github.com/gwarser/filter-lists/blob/24c8aaecbaabe62d74aca02dab08aa89ba2e4624/lan-block.txt#L26

Discussed here uBlockOrigin/uAssets#4318 about blocking access by HTTP to local resources, for example router on modem interfaces.

That's quite a bit more robust...

Chameleon also will block websockets, except for the whitelisted...and does a lot of other things. I just don't like how many errors it causes in the backend...nothing that makes anything not work, just disconcerting.

[crssi]

This was already discussed here.
Just search over closed issues.
And it is done over dynamic filters and not static.
I also use it. Peek into my repository.

[travankor]

https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.3-uMatrix

[ilikenwf]

https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.3-uMatrix
@gwarser s blocklist seems to handle this too, in uBO as far as I can tell, and includes all the IANA reserved ranges...

[crssi]

You can use the same in uBO from here #319 (comment), not sure for the IPv6 part doe.

[Thorin-Oakenpants]

OK, I think we're done here - closing. But do post any other FPing questions if you have any

[Thorin-Oakenpants]

from OP

and those opinions resonate with every single one of my contacts (tor project, mozilla, us naval research lab)

Not that I can particularly find concrete references .. it's not like I have kept a list (I don't need to), but here is one that helps explain in more generalized terms

• https://matt.traudt.xyz/posts/about-to-use-SkxEFK1m.html#testing-your-fingerprint

I have had the very occasional email with Matt Traudt: he works for the US Naval Research Lab and mostly lives in the network stack (i.e he works on Tor, not Tor Browser/FPing)

[ilikenwf]

I find the CSS fingerprinting to be especially concerning on non-FF derivatives since the branding difference is unique:

[Thorin-Oakenpants]

no-one does that except me. What's the dimensions?

[ilikenwf]

Dimensions of my screen, or of the images? I can find the branding dir on the waterfox git if you want them.

[Thorin-Oakenpants]

where it says e.g [resource://] browser | Firefox Browser - Developer/Nightly [336 x 64] .. the 336 x 64 is the dimensions of the branding svg

[ilikenwf]

There's a classic and a current branch of WF: https://github.com/MrAlex94/Waterfox/tree/current/browser/branding/waterfox https://github.com/MrAlex94/Waterfox/tree/classic/browser/branding/alpha

…

On 5/27/20 12:27 AM, Thorin-Oakenpants wrote: where it says e.g |[resource://] browser | Firefox Browser - Developer/Nightly [336 x 64]| .. the |336 x 64| is the dimensions of the branding svg — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOUDZCQ3HVZMTB3YAKTRTSQDBANCNFSM4NAIKPJQ>.

[Thorin-Oakenpants]

So what are the dimensions?

[ilikenwf]

Well, I linked the images so you could grab them yourself, but for me personally they are 128x22 for the "Waterfox" text image, and 300 x 236 for the logo with text, but that gets truncated and scaled down on the page.

[Thorin-Oakenpants]

Yeah but I'm not worried about it, you were :) https://github.com/MrAlex94/Waterfox/blob/current/browser/branding/waterfox/content/about-wordmark.svg tells me it's 128x22 if i check in the inspector

But https://github.com/MrAlex94/Waterfox/blob/classic/browser/branding/alpha/content/about-wordmark.svg tells me it's 300 x 107.

You need to use the actual PoC - that's what it's there for, because it eliminates (or shows up) variables: rather than me scurrying around loading files and inspecting them. I'm measuring an element, not the svg, btw (but AFAIK, the element should be the same size).

[Thorin-Oakenpants]

I'm also not measuring the item you see on the screen - I measuring a full sized one that is hidden

[ilikenwf]

Good to know... I think the way my DE scales things could be throwing it off.

…

On 5/27/20 1:45 AM, Thorin-Oakenpants wrote: I'm also not measuring the item you see on the screen - I measuring a full sized one that is hidden — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOQXXW7UOMAXUHT2XS3RTSZJFANCNFSM4NAIKPJQ>.

[ilikenwf]

On fingerprinting...we can at least get a good look at some of the techniques used including WS portscans by ebay and customers of this online metrics company - the payload decryption script is a nice tool, and you can find test cases for it in the archive.org cache of these fingerprint domains...

I'm going to paste my more interesting findings from
uBlockOrigin/uBlock-issues#1070

===

After doing some research, I've found that these portscanning fingerprint scripts are all hosted via CNAME on the same domain, which uBO already blocks when CNAME checking is on:

online-metrix.net

Beyond that, it usually is served up as one ore more of these:

• clear.png
• check.js
• fp.swf

It's used by a lot of sites:

https://src.ebay-us.com/fp/check.js?org_id=usllpic0&session_id=1
https://src.ebay-us.com/fp/fp.swf?org_id=usllpic0&session_id=1

https://content.mercadopago.com/fp/clear.png

https://b177.kabbage.com/fp/check.js?org_id=rxemj1ou&pageid=1&session_id=1

https://content3.risk.lexisnexis.com/tags.js?org_id=baa3flhp&allow_reprofile=1&session_id=1

And even more:
https://www.google.com/search?hl=en&q=inurl%3Acheck.js%3Forg_id%3D

Someone also has built a payload decryption tool:

https://gist.github.com/nemec/ea6b21bcd027b81ac1e3fbcfeb01db3e

[ilikenwf]

...because we know most of these fingerprinting/tracking companies' endpoints it makes me wonder why a tool isn't built to dump oodles of fake info into their systems and ruin their data models by increasing entropy.

[ilikenwf]

This seems relevant to this discussion, this is beyond disgusting:

https://smitop.com/post/whiteops-data/