Provide the same scrollbar size across different platforms + versions (and subpixel entropy)
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.
Activity
added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac parent::18283 in Legacy / Trac priority::high in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-fingerprinting-resolution in Legacy / Trac type::defect in Legacy / Trac labels
17px look good.
Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-resolution added
Parent: N/A to legacy/trac#18283 (moved)
FWIW: https://bugzilla.mozilla.org/show_bug.cgi?id=1397996 is the Mozilla bug.
-
Marking legacy/trac#29348 (moved) as a duplicate of this bug. legacy/trac#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] oswhen 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] oswhen 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.cssetc. 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. 
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] oswhen 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.cssetc.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
cssfile binds thexmlfile, which in turn runs thejsfile: 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. mentioned in issue legacy/trac#22226 (moved)
mentioned in issue legacy/trac#29348 (moved)
mentioned in issue legacy/trac#30647 (moved)
moved from legacy/trac#22137 (moved)
added Bug label and removed 1 deleted label
added Fingerprinting label and removed 1 deleted label
mentioned in issue #40184 (closed)
-
Scrollbar leaks OS (mac/linux etc) which we cannot hide. But within those Mac has two settings (floating or not), and Linux is quite variable - see TZP feature dectection, you can zoom in and out and it will update in real time
FYI: FF97+ 1719427
widget.non-native-theme.scrollbar.style0. Default platform scrollbar style. 1. macOS scrollbars 2. GTK scrollbars 3. Android scrollbars 4. Windows 10 scrollbars 5. Windows 11 scrollbarswidget.non-native-theme.scrollbar.size.overrideI had a little play and set "android" style on windows and got 6 pixels - I was hoping it would use an overlay :) not to be. Anyway, that's a little naff since it's about styling, but might be useful or needed to enforce GTK
The size.override works perfectly (so far). We could enforce a scrollbar overlay (or not) on mac (#22632 (closed)), and force a size on linux.
@gk IDK if you want to (or can) backport all of that (and there may be other underlying patches), but this could definitely be a next-esr item
That said, I still think an overlay scrollbar for all is cleanest and less susceptible to bugs
changed milestone to %Tor Browser 11.5
mentioned in issue #40789
added Roadmap::Future label
mentioned in issue #22632 (closed)
a useful upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1690038
-
more like 1397996#c25 ... it should be a very simple patch AFAICT - just check for RFP using a fine-grained cut, e.g. 1757994 and enforce
ui.useOverlayScrollbars=1.. and backport to ESR102.1, be home in time for tea and biscuits -
@thorin did some digging and just want to confirm: you're proposing a patch which changes something like https://searchfox.org/mozilla-central/source/layout/base/nsPresContext.cpp#1637 to override the per-platform/per-pref value if RFP is enabled yeah?
-
which changes something like
that looks about right.Emilio can confirm/review.edit: ughh, now I see the new comment below
Edited by Thorin
mentioned in issue #40761 (closed)
removed Roadmap::Future label
added Next label
changed milestone to %Sponsor 131 - Phase 3 - Major ESR 102 Migration
added Sponsor 131 label
added Q4 label
assigned to @richard
-
Ok did a little more digging.
Setting
ui.useOverlayScrollbarsdoes nothing as far as I can tell on my linux machine, the 'real' pref iswidget.gtk.overlay-scrollbars.enabledwhich is actually toggleable in about:preferences > General > Browsing (though only for gtk builds -> https://searchfox.org/mozilla-central/source/browser/components/preferences/main.inc.xhtml#713 ).There seems to be a bit of a spiderweb of legacy/new prefs in this space that need to be de-tangled and sorted out. As far as I can tell, all platforms are using this entry-point for their scrollbar styling (gated on the
widget.non-native-theme.scrollbar.stylepref)Edited by morgan 
The patch on bugzilla seems to do what we need https://phabricator.services.mozilla.com/D103702
This basically avoids the call to
NativeGetInt, where the per-platform logic comes in.One thing I would point out is that on windows 10 or lower using overlay scroll is always off:
So enabling it for all platforms would be untested.
For reference, here are the other places where it is decided:
Edited by henry-
One thing I would point out is that on windows 10 or lower using overlay scroll is always off:
I also had a feeling it was auto enabled on tablets too. And on macOS it is dependent on an OS setting (last time I checked). And on linux widths can vary depending on the desktop environment. And users can change scroll widths via prefs. That's the whole point
So enabling it for all platforms would be untested.
We set it, we test it. RFP is not front facing in Firefox, and at the very least if we do it here, we can spot any flaws, fix em, and upstream it. It's been four+ years .. I am trembling with anticipation
-
I know that some people don't like overlay scrollbars because
- They can be hard to see without the gutter (on GNOME at least they are quite thin).
- The overlay disappears unless there is mouse movement over the scrollable area. This can make them hard to find, and it is less obvious that the area has overflowing content, especially if there is no visually cropped content.
The above could be especially bad if you have any vision problems, so I would be hesitant to force it on all users. Thick visible scrollbars might be the most functional for everyone.
@duncan do you have any UX insight?
-
this was mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c17 (scroll up & down a little)
come on, this has been 5+ years in the
waitingmaking ... and is a damaging FP vector, especially in Linux. JUST DO IT (already!). This incessant moaning about a few cosmetics - TB users will learn 
My only concern are older users and/or those who require accessibility considerations who may have chosen to disable hidden scrollbars at the OS level for good reason (as @henry has pointed out).
I think the best compromise would be to add this as an opt-out pref in
General > Language & Appearance(maybe with an option that just respects whatever the system-wide setting is?) and add an appropriate warning about scrollbars being a fingerprinting vector to it.-
I think the best compromise would be to add this as an opt-out pref
Noooooooo! You can't. Protections behind RFP are an all-in buy-in. We do not and never have allow exceptions in RFP, despite numerous requests. (canvas per site and in TB per session, is not the same thing)
IDK if this pref exists in 102 but it works a F treat on windows
-
ui.useOverlayScrollbars= 1 -
layout.testing.overlay-scrollbars.always-visible= true - load https://arkenfox.github.io/TZP/index.html (which is long enough for a vertical scrollbar)
- lose focus .. no, NOT like that, pay attention .. so that the scrollbar has time to disappear
- behold that scrollbar does not disappear
IDK how you repurpose that
testingpref or or add a UI for it, but there's the proof in the pudding that it can be done. Default disappear, UI option to make sticky -
-
Thanks for all the input.
Whilst overlay scrollbars are visible they block the content underneath. That is why they tend to be thin, but importantly need to be able to disappear.
Looking through the code, it does seem the case that there is a few OS-specific scrollbar sizings. However, I'm not sure this is worse for linux users, it seems everyone gets 12px unless overridden with a preference. It seems a worse fingerprint for microsoft windows, where it seems to take DPI into account.
Anyway, ideally we could stick close to the desktop's settings (as far as LookAndFeel interprets them). And I like what @richard said about customizing the overlay ourselves. One possible approach is:
- Use overlay scrollbars on all platforms.
- To offset the visibility issue we could always paint the scrollbar track when the user moves the mouse, regardless of if the scrollbar has hover by removing this code. This makes the scrollbar far more visible and obviously a scrollbar for mouse users.
- On GTK, we remove this code that halves the size of the scrollbar when it doesn't have hover. Other platforms might need something similar.
There's still the issue of a disappearing scrollbar making it less obvious that the area has overflowing content. But this is more situational.
@duncan what do you think? Drawing the scrollbar track when moving a mouse is less elegant, but it seems more practical and clear. But do you think it would sufficiently address the visibility issues?
-
@henry Sorry, I'm not sure I understand fully. Are you proposing we do "More obvious scrollbars" for:
- Everyone
- Only those with a particular system setting we can read
- Only those who've opted-in for more obvious scrollbars within
about:preferences
If it's the former, constantly revealing the scrollbar with any mouse movement for everyone would be a little annoying. However if it's one of the latter two cases, I like it :D
-
Are you proposing we do "More obvious scrollbars" for [...]
I was only really proposing a way to change the overlay scrollbar drawing to make up for some of its downfalls. I hadn't really thought about whether everyone should get these "fixes", but it should be possible to apply it selectively :)
We could hijack the current LookAndFeel's
useOverlayScrollbarlogic to determine whether we apply it or not. So windows 10 users would get the "fixes", windows 11 it would be based on the system settings, ect. We might have to change the wording of the "Always show scrollbars" preference on linux though.We could also add a preference to override this (but no way to opt out of overlay entirely), mostly for the windows 10 users if they don't like it.
Edited by henry -
So windows 10 users would get the "fixes", windows 11 it would be based on the system settings, ect.
I'm going to say this once, and I'm getting very frustrated and upset. The whole point of this issue is to reduce fingerprinting per platform. We already have a solution: overlays for all. It is already the default on android, and used by macOS system settings, and on by default on some windows versions (I forget which). It works, people use it.
Then there is a concern that the overlay fades away after inactivity/focus. There is code to stop that: maybe we can use that and give it a UI options
Then there is a concern on linux about width. IDK much about linux desktop environments, but surely you can change that in code after getting feedback in alpha
Please, in plain english, tell me what the strategy is here, or any concerns I have missed, so I can decide if I want to be part of it (any of it) any longer (the whole RFP has stagnated upstream for years and I'm getting tired of fighting - more than happy to just give it away)
-
I think we're pretty much agreed about enforcing overlayed scrollbars across the board? We're just handwringing about providing a more accessible option too. My understanding of @richard and @henry's last comments is that it would also be overlayed, but with more obvious styling.
Either way, we can enable the first part in Nighty or Alpha or whatever for testing (probably best in the 12.5a series now?) and figure out the second part later (if it's still necessary).
This is a long and complicated thread though, so I may have misunderstood something :)
Edited by donuts -
@thorin: overlays are coming, we just need to make sure accessibility is not hurt in the process. Before we change things for everyone, we must provide users with vision/motor impairments an overlayed option which will work for them so they can get the privacy benefits the rest of the users get while still also being able to use Tor Browser.
@henry: the linux-only 'Always show scrollbars' check will def have to go away/reworded and unified across the platforms.
So I think for each platform, we should also provide an accessible overlay version. Which overlay version to use should follow the system preferences, unless the user opts out then it should be explicitly configurable (like the 'Always use private browsing mode' and child settings in
about:preferences#privacy). This setting block should probably go under 'Language and in Appearance'about:preferences#general.If we want to get super fancy in the future we could try making the overlayed scrollbar properties configurable for both power users and those with accessibility needs.
-
OT: is something up with notifications (settings remain unchanged): I am getting nothing from
gitlab.torproject.organd am missing replies/comments etc to keep me abreast of things - and they're not in promotion or spam email folders on the server (gmail). Started in the last 24 hours AFAICT. Did I trigger some sort of filter? -
@thorin not to my knowledge, all that sort of thing is controlled in your profile: https://gitlab.torproject.org/-/profile/notifications
-
Setting
ui.useOverlayScrollbarsdoes nothing as far as I can tell on my linux machine, the 'real' pref iswidget.gtk.overlay-scrollbars.enabled@richard could you double check this? Setting
ui.useOverlayScrollbarsto1or0changed the behaviour for me, regardless of the gtk preferences. I found that going from overlay to non-overlay was a bit buggy (the scrollbar would fade and then reappear), but it was fine after a restart.This is the code that avoids the native logic, so the gtk preference should be ignored. The value gets cached though and maybe there is some bug in not refreshing the cache when the pref changes.
-
@henry you are right of course, I was creating
ui.useOverlayScrollbarsas aboolpref rather thanint. Having correct that I'm seeing the behaviour you've described. -
See https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c27 and onwards for where this is at now. Basically, I'm not going to use overlay scrollbars and instead use a set width on all desktop platforms. We might use overlay in the future.
Edited by henry -
I'm not going to use overlay scrollbars
FWIW I'm against this
Overlays are used on android, they are used on windows 11 (and 10?) by default (and note that windows 7 will be dead within a year or so), they are used on mac OS. All without issue. As emilio said, and I said, it already all works and is fine for users/accessibility IMO [1][2]. And if width is important for accessibility down the track, then the only way to increase that without entropy is as an overlay (i.e accessibility users width !== same as normal-width users). Also using an overlay means we don't have to worry about users changing the width and trying to lock that down. Think about it. It's a non-brainer, seriously!
All the code is already there [3]. I do not see why we should force non-overlay when that is not the direction desktop is going, and it just adds complexity
[1] emilio comment 28
I'm confused, what's wrong with the existing ui.useOverlayScrollbars preference
[2] emilio comment 28
Always using overlay scrollbars
That seems trivial-ish
[3] emilio comment 28
I'm dubious the problem is as bad as it was in the original issue. In particular, scrollbar sizes now should depend exclusively in the combination of OS text scale + widget.non-native-theme.scrollbar.size.override + widget.non-native-theme.scrollbar.style.
-
^ don't take it personally .. I'm going to die on this hill or walk away ...
fourfive years man ... the answer is overlaysEdited by Thorin -
@thorin whilst parts were do-able, other parts which are important for usability/accessibility were not do-able or had unknown UX implications. The firefox accessibility team basically confirmed that non-overlay scrollbars are ideal whilst overlay scrollbars would require some modifications (that are hard to implement right now).
Windows 10 does not use overlay scrollbars, so that is the majority right now. On windows 11, non-overlay scrollbars are re-enabled in the accessibility settings.
As mentioned in bugzilla, universal overlay scrollbars may work in the future but would require some proper modifications and user testing.
Overall, whilst I initially wanted overlay scrollbars to work, I'm choosing an option that is workable and usable right now and seems likely to be accepted upstream.
-
I'm not buying it - accessibility in TB is already broken (not that we shouldn't fix them): screen reader + speech engines, prefers-color (although I do not accept this as a solution since it is arbitrary for websites to implement), css colors (I think: I've never had the nerve to flip my system into high contrast), and likely more. 17px vs 24px is not a deal breaker IMO - that's what system scaling is for.
Using non-overlays opens up avenues for users to bypass them (better lock those all down) and creates entropy with subpixels: although that would manifest elsewhere I guess (equivalency)
IDK, not feeling like a happy camper here.
unassigned @richard
assigned to @henry
added Uplift label
added Doing label
