sereneblue / chameleon

WebExtension port of Random Agent Spoofer
https://sereneblue.github.io/chameleon
GNU General Public License v3.0
517 stars 53 forks source link

Screen size spoofing is detectable. Need improvement #170

Closed ReporterX closed 5 years ago

ReporterX commented 5 years ago

It is easy to detect whether you are spoofing screen size. Let's say you use 1920×1080 which is one of the most common screen size.

Simply check window.innerWidth and window.innerHeight. It is likely that you are spoofing if they are exactly the same as your screen size which is abnormal.

The inner window won't be the same as screen size even if you maximize the window, because you have taskbar and Firefox toolbars.

Take Windows 7 as an example, Windows 7's default taskbar - 40px for large icons, 30px for small icons Firefox default toolbar interface (normal UI density) - 74px Total - 114px So window.innerHeight should be 966.

Perhaps the addon can do the math and set them automatically, or let people define window.innerHeight.


Another set of values which you should pay attention are availWidth and availHeight (which is 1040 or 1050 by default, should be lower than the screen height). Yours stays the same when spoofing which is abnormal.

Also Window outerWidth and outerHeight.

Thorin-Oakenpants commented 5 years ago

You can't hide the fact that you are spoofing here. You either spoof everything to the inner window (such as privacy.resistFingerprinting), or you spoof everything to screen (using common metrics)

Factors (on windows) such as startbar position (left.right vs top/bottom), startbar height, using large/small icons, windows dpi etc are not always the same. On Linux it would probably get even more variation due to various desktop environments (I'm not a linux expert). And what about Mac.

everything must be spoofed to either of those two values - anything else just adds complexity, and you would still be caught out if they wanted to get you (see css media).

Here is the Tor Browser using RFP tb

Even if you did spoof a common available screen vs actual screen, you'll still be detected by the inner vs outer measurements being the same, among other metrics (it's easy to tell if you're in full screen or headless as well).

The fact that you're spoofing to beat fingerprinting will also be apparent in other measures you take, for example: if you spoof a new canvas value on each request, or you use RFP's 10x10 white canvas. Hell, I can even tell if you're lying about your browser (chrome/firefox etc), OS and even your browser version.

are you using anti-fingerprinting techniques is trivial to detect. It's either true or false - everyone has this metric. It's not 50/50 (e.g are you male or female), so it's not 1 bit of entropy. But it's not something you can do anything about, and it's especially useless to even worry about it when you try to raise entropy, randomly, which is what Chameleon does

sereneblue commented 5 years ago

I did some research and it doesn't look like there is a 'correct' approach. Making the inner/outer windows the same as the screen resolution works for the Tor Browser because you're using Tor and that's expected behavior. I thought Mozilla did something similar with RFP but it looks like RFP doesn't do that anymore (?).

It wouldn't be too difficult for me to update Chameleon to better spoof the values.

Thorin-Oakenpants commented 5 years ago

but it looks like RFP doesn't do that anymore (?).

It does. RFP spoofs screen, available screen, outer as actual inner-measurements

sereneblue commented 5 years ago

but it looks like RFP doesn't do that anymore (?).

It does. RFP spoofs screen, available screen, outer as actual inner-measurements

I see. I thought RFP used the screen resolution (ex 1920x1080) for those values instead of the available screen. I suppose it wouldn't hurt to make the screen values more realistic.

seascape commented 5 years ago

Meta question related to this.

I've been trying to figure this out: If you can't/won't change your browser window to a specific common size (like Tor Browser does), and you're worried that your browser's resolution is too unique to resist fingerprinting (which it usually will be), what are (second-)best practices for reducing that vulnerability? I've heard using FF RFP's resolution features somehow makes you more identifiable rather than less, and I wonder if Chameleon can fare better.

Thorin-Oakenpants commented 5 years ago

I've heard using FF RFP's resolution features somehow makes you more identifiable rather than less

RFP users are an enforced set to some degree. There are issues with height being out by a few pixels (but consistent per platform) if you have the bookmarks toolbar showing. Theme density also affects the padding on the toolbar, so that's more FP buckets users can fall into. Additionally, system settings like DPI can cause the 1000x1000 to be out by several pixels. And of course users can resize their browser (manually, full screen) or alter the inner window (opening docked dev tools, sidebar, menubar, and other chrome elements).

So it's not perfect. Hopefully, most people would only fall into a few buckets: they open at 1000x1000 and don't resize, or if they have the toolbar showing on Windows for example, they are 1000x997 (or whatever it is). This is far better than having no protection. No way does using RFP make you more unique.

Then there is letterboxing, which is not currently tied to RFP. This solves all those problems above by letterboxing the inner window regardless of all the chrome issues (chrome: all the parts of the browser that are not the web content).

Letterboxing uses the most space it can, stepping in (currently) 100px height and 200px widths. This reduces the possible combinations a lot. This facilitates usability and encourages uptake: but for sure, instead of everyone supposed to being at 1000x1000, now there will be lots of sizes: e.g 1400 x 1200, 1600 x 1200, and so on. Another thing that will probably happen is that the steps will use a sliding scale: e.g it might move in 50px steps at lower resolutions, and 200px steps in higher resolutions. Better usability without increasing the set of returned values.

This is still magnitudes better than anything else. What it needs, like the Tor Browser, is more people using it. That's all. The math and science behind it are solid. It could be conceivable that a maximized Firefox on a common screen res, on a common OS layout is no worse: but no one has any data on that: and changes to the chrome, will alter it. Just installing a theme will could change it.

I also want to point out that RFP covers some FPing techniques that extensions can't (correct me if I'm wrong). Such as css media queries: although I doubt anyone uses that. However, you cannot hide the true viewport measurements: it is trivial to measure an element with a style position:fixed;top:0;left:0;bottom:0;right:0;

If you want to have a play, go check out https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen - the screen, window and viewport measurements update in real time. I haven't tested Chameleon in a long while, but I bet the viewport is not spoofed

sereneblue commented 5 years ago

I don't think it's possible to reliably spoof the viewport with WebExtensions so I'm not sure if it's worth putting work into addressing it.

I've done some experimentation with possible screen sizes. There isn't a consistent value for a browser. I was able to obtain some data using virtual machines, however, the current Chameleon injection API is ill equipped to handle variations in the screen resolution per OS/browser. I believe the current solution is fine for now, so I'll be closing this issue. I'm working on a better design for script injection that will be available in v0.20. Profile spoofing will be improved to handle variations in the screen sizes.