Opened 2 years ago

Last modified 5 months ago

#22137 new defect

Provide the same scrollbar size across different platforms

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-resolution
Cc: arthuredelstein, brade, mcs, concerneduser Actual Points:
Parent ID: #18283 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (12)

comment:1 Changed 2 years ago by gk

Severity: MajorNormal

comment:2 Changed 2 years ago by flyingbird

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?

comment:3 Changed 2 years ago by cypherpunks

Keywords: tbb-fingerprinting-resolution added; tbb-fingerprinting removed
Parent ID: #18283

17px look good.

comment:4 Changed 2 years ago by arthuredelstein

Cc: arthuredelstein added

comment:5 Changed 2 years ago by mcs

Cc: brade mcs added

comment:7 Changed 5 months ago by gk

Cc: concerneduser added

Marking #29348 as a duplicate of this bug. #29348 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.

comment:8 Changed 5 months ago by 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%)

-- 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

comment:9 in reply to:  8 Changed 5 months ago by gk

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.

comment:10 Changed 5 months ago by Thorin

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

comment:11 Changed 5 months ago by concerneduser

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.

comment:12 in reply to:  8 Changed 5 months ago by Thorin

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)

Note: See TracTickets for help on using tickets.