Provide the same scrollbar size across different platforms

Scrollbar sizes are different on different platforms. But it seems that there are ways to split the Linux users into different buckets based on that: On a Debian Stretch system with XFCE I get 15px thickness on an Ubuntu 14.04 system with GNOME I get 13px thickness.

A test can be found on http://www.hackerfactor.com/blog/index.php?/archives/761-Exploiting-the-TOR-Browser.html.

One option mentioned in that blog post would be to provide 17px on all platforms.

added component::applications/tor browser owner::tbb-team parent::18283 priority::high severity::normal status::new tbb-fingerprinting-resolution type::defect labels

Trac:
Severity: Major to Normal

What about UI elements that can be embedded in web pages (text fields, scroll bars, buttons, etc)? Is it possible to differentiate users based on os-dependent appearance of these elements?

Trac:
Username: flyingbird

17px look good.

Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-resolution added
Parent: N/A to #18283 (moved)

Trac:
Cc: N/A to arthuredelstein

Trac:
Cc: arthuredelstein to arthuredelstein, brade, mcs

FWIW: https://bugzilla.mozilla.org/show_bug.cgi?id=1397996 is the Mozilla bug.

Marking #29348 (moved) as a duplicate of this bug. #29348 (moved) proposes to use https://gist.github.com/mrkwatz/277fb19d210a7539304ca2388f24d8e3 and notes

it makes the clientWidth become 1000 as intended (you obviously could also make the scrollbars the same width/height as on Windows, but I think this is a better approach). If something like this is included into standard Tor browser it would minimize segregation and thus allow users to use Tor on Linux/Mac while still appearing as Windows users.

Trac:
Cc: arthuredelstein, brade, mcs to arthuredelstein, brade, mcs, concerneduser

Georg, I have been using the solution outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c2 for over year, flawlessly. These are the original authors. I don't know about this new one (which looks like a modified version or copy), but the one I've used has a menu item to turn it on/off - so you'd probably need to remove that (I guess).

FYI: There will also be a test for this at https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent - under [scrollbar width] os when added (soon), which incorporates detection of zoom (which is required to correctly calculate the scrollbar width if zoom is not 100%)

-- from the bugzilla comment to save time [STEP1] https://github.com/nuchi/firefox-quantum-userchromejs

• save (or append to existing) userChrome.xml and userChrome.js to profile/chrome [STEP2] https://github.com/Endor8/userChrome.js/blob/master/floatingscrollbar/FloatingScrollbar.uc.js
• save (or append to existing) FloatingScrollbar.uc.js as userChrome.js to profile/chrome [Step3] clear CACHE and restart

Replying to Thorin:

Georg, I have been using the solution outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c2 for over year, flawlessly. These are the original authors. I don't know about this new one (which looks like a modified version or copy), but the one I've used has a menu item to turn it on/off - so you'd probably need to remove that (I guess).

FYI: There will also be a test for this at https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent - under [scrollbar width] os when added (soon), which incorporates detection of zoom (which is required to correctly calculate the scrollbar width if zoom is not 100%)

Nice!

I think what we need to figure out in this ticket first is the approach we want to take to solve this issue. I am not a huge fan of shipping some userChrome.css etc. if we have the option to easily patch the browser ourselves (which we have) as patching seems less complex and error-prone to me and we want to upstream the fix to Firefox anyway. (That way everyone can benefit.) The easiest and sufficient solution might still be to just give a fixed value, say 17px, back for all platforms.

Definitely prefer patching, but would like it done at Mozilla's end, even if tied to RFP

Obviously patching is better no doubt.

Though seeing how old the issue here and over at mozillas tracker is I would highly suggest to include the userChrome while this is "natively" implemented. I did not know that different GTK themes provide different widths this should be considered a severe fingerprinting issue. This should be resolved as fast as possible. We all want everyone to look the same right?

Another, very easy, way to resolve this is to simply set the env var GTK_THEME=Adwaita since Adwaita is the default GTK theme. Though keep in mind Tor should strive to have every OS display the same clientWidth (ie 1000), meaning this as well should only be a temporary solution.

Trac:
Username: concerneduser

FYI: There will also be a test for this at https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent - under [scrollbar width] os when added (soon), which incorporates detection of zoom (which is required to correctly calculate the scrollbar width if zoom is not 100%)

Added it. I didn't bother to add the os logic yet, but have built detection of zoom (but not factored it to reverse the result - it's not very precise). Anyway, at least the test is there to return the width in tests. Zoom your page and refresh to see what I mean.

Probably tomorrow I will add, if zoom is at 100%, an OS value as well (which isn't really the point, the actual width itself is the entropy)

Replying to gk:

I think what we need to figure out in this ticket first is the approach we want to take to solve this issue. I am not a huge fan of shipping some userChrome.css etc.

Come ESR78, this solution won't even be available anymore as XBL/XUL is ripped out AFAIK

if we have the option to easily patch the browser ourselves (which we have) as patching seems less complex and error-prone to me and we want to upstream the fix to Firefox anyway. (That way everyone can benefit.) The easiest and sufficient solution might still be to just give a fixed value, say 17px, back for all platforms.

I'd still pump for an overlay (but only code it for desktop I guess) - this way all platforms are the same.

The css file binds the xml file, which in turn runs the js file: which is 90 lines long, including adding a menu option to turn it on and off (which is at least half of it). It isn't much - 30 lines of css (in the js file). I would add tying the color to the theme (light/dark/default), choose our own thickness and transparency. And it works on all scrollbars: in elements (iframes, textareas), horizontal, vertical: and it's never caused me any issues in two years or so.

Trac:

mouseover (top image) changes the transparency

mentioned in issue #22226 (moved)

mentioned in issue #29348 (moved)

mentioned in issue #30647 (moved)

moved to tpo/applications/tor-browser#22137