Open Bug 1397996 Opened 8 years ago Updated 1 month ago

scrollbar thickness reveals platform

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Version:
55 Branch
Type:
defect

Tracking

()

People

(Reporter: thorin, Unassigned, NeedInfo)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [tor][fingerprinting][fp-triaged][tor 22137])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170824053622 Steps to reproduce: [tor][fingerprinting] Explanation and PoC [1] (scroll down to "Test results for your browser") > If scrollbars are displayed, then the Viewport Size can be subtracted from the [inner] Window Size in order to find the thickness of the scrollbars Scrollbar thickness varies depending on OS [1] https://www.hackerfactor.com/blog/index.php?/archives/761-Exploiting-the-TOR-Browser.html
Flags: needinfo?(ettseng)
Found a relevant tor ticket [2] https://trac.torproject.org/projects/tor/ticket/22137
Component: Untriaged → DOM
Product: Firefox → Core
Blocks: uplift_tor_fingerprinting
Flags: needinfo?(ettseng)
Priority: -- → P2
Whiteboard: [tor][fingerprinting][fp-backlog]
Whiteboard: [tor][fingerprinting][fp-backlog] → [tor][fingerprinting][fp:m4]
I just followed these instructions [1] for a floating scrollbar and retested [2] > Test results for your browser: > Screen Size: 1366x768 > Windows Size: 1366x768; TOR detected > Viewport Size: 1366x768 > Zoom Level: 100% > Scrollbar thickness: right 0px, bottom 0px; Detected MacOS X or mobile device Scrollbar thickness detected as zero. No I am not on TOR, no I am not on MacOS or a mobile device. Note: the code covers horizontal scrollbars as well. Works in text fields etc. Not sure about iframes. Needs thorough testing. This would also be a good idea for findbar and developer toolbar - i.e make them floating so as to not influence inner window measurements [1] https://www.reddit.com/r/firefox/comments/7f6kc4/floating_scrollbar_finally_possible_in_firefox_57/ [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 [2] https://www.hackerfactor.com/blog/index.php?/archives/761-Exploiting-the-TOR-Browser.html
Making things that reveal the OS P5.
Priority: P2 → P5
Whiteboard: [tor][fingerprinting][fp:m4] → [tor][fingerprinting]
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-triaged]

(In reply to Tom Ritter [:tjr] (PTO) from comment #3)

Making things that reveal the OS P5.

Actually it's not just revealing the OS but can differentiate between Linux users as well (not sure about other platforms), given that Linux systems with XFCE and GNOME at least report different scrollbar thicknesses. So, it seems to me this should get bumped higher than P5?

Flags: needinfo?(tom)
Whiteboard: [tor][fingerprinting][fp-triaged] → [tor][fingerprinting][fp-triaged][tor 22137]

(In reply to Georg Koppen from comment #4)

Actually it's not just revealing the OS but can differentiate between Linux users as well (not sure about other platforms), given that Linux systems with XFCE and GNOME at least report different scrollbar thicknesses. So, it seems to me this should get bumped higher than P5?

That's an understatement. It's determined by the widget theme, so it'll vary within desktops from distro to distro and users can change it further.

Fair enough - bumping to P2 since there seems to be a potential patch forward for resolving this...

Flags: needinfo?(tom)
Priority: P5 → P2
Assignee: nobody → xeonchen
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Component: DOM → DOM: Core & HTML

Not actively working on this, unassign myself.

Assignee: xeonchen → nobody
Status: ASSIGNED → NEW

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #6)

Fair enough - bumping to P2 since there seems to be a potential patch forward for resolving this...

Tom, I am curious to know what the patch you have in mind is. This seems to be a hard problem to solve.

  1. Zoom changes things. But, for the sake of this patch, we could assume that zoom is at 100%.
  2. Even if we spoof the viewport width, ie document.documentElement.clientWidth, to window.innerWidth - 17 there might be a way to get the size of the scrollbar by calling document.X.clientWidth for some other CSS entity X. For instance, one could do the same attack with document.body.clientWidth in place of viewport width.

I am gonna end with a naive question: could we always auto-hide the scrollbars so we can always have document.documentElement.clientWidth = window.innerWidth?

Flags: needinfo?(tom)

(In reply to sanketh from comment #8)

  1. Zoom changes things. But, for the sake of this patch, we could assume that zoom is at 100%.
  2. Even if we spoof the viewport width, ie document.documentElement.clientWidth, to window.innerWidth - 17 there might be a way to get the size of the scrollbar by calling document.X.clientWidth for some other CSS entity X. For instance, one could do the same attack with document.body.clientWidth in place of viewport width.

Use an overlay. Android already has one. Mac allows you to use one (system setting AFAIK). Then zoom and other measuring methods don't matter

also see tor ticket: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22632 : The scrollbar in TB is enabled and disabled based on a setting in macOS system preferences

Perhaps privacy.resist-fingerprinting should imply widget.disable-native-theme-for-content now that we have it? (At this point it's enabled on Android and there's a plan to enable it for Windows in the short/medium term as well.)

I'm tempted to generalize this bug to be "scrollbar thickness or form control size reveals platform", although I suppose there might be some solutions that would fix one without the other... although they don't seem likely to be particularly useful since the other would remain unfixed.

I also think it probably belongs in either the Layout: Form Controls component, the Layout: Scrolling & Overflow component, or whichever of the Widget components is appropriate for native theme code generally.

Now that widget.disable-native-theme-for-content is the default for Linux Nightly, I'm inclined to agree that we should enable it when RFP is enabled. We may want to do some more testing on it though. It certainly seems like the correct choice, although I would like confirmation that it will actually fix this bug.

ui.useOverlayScrollbars = 1 works for element and viewport scrollbars, at least on Windows - not sure when it was added

  • Also see Bug 1690038 re the macOS pref (if needed)
  • Also see widget.non-native-theme.scrollbar.size.override FYI: FF97+ Bug 1719427 which can be used to unify widths in say Linux

I'm not sure what pref takes precedence, I think it is ui.useOverlayScrollbars which we could enforce on desktop as 1 if RFP is enabled - this is mainly for linux entropy - windows/android users should be the same, and macOS has two possible values (AFAIK) - but standardizing across all platforms seems reasonable to me

emilio: what are your thoughts?

Flags: needinfo?(emilio)

also see Bug 1757647 - is there some plan elsewhere to use overlay scrollbars?

(In reply to Simon Mainey from comment #14)

I'm not sure what pref takes precedence, I think it is ui.useOverlayScrollbars which we could enforce on desktop as 1 if RFP is enabled - this is mainly for linux entropy

As a desktop Linux user, I really don't like the creeping incursion of UI design elements from touchscreen-based platforms, of which, one thing is overlay scrollbars, since it either means I can't see my position in the document at a glance (I'm not a big fan of having to waggle the scroll position on a phone to bring that into view on a phone either, though I recognize the need at the given screen sizes) or have something constantly overlapping the content in an unappealing way.

Please consider forcing a browser-provided non-overlay scrollbar with consistent metrics instead.

Please consider forcing a browser-provided non-overlay scrollbar with consistent metrics instead

Noted, but I'm not in charge :) RFP is non-facing in Firefox as an upstream for Tor Browser. Tor Project and moz devs can consider the best strategy. I see no issue with overlay scrollbars - they are already the default in macOS (if I read that right) and now Win11 (if I read that right) and of course Android

I'm not a big fan of having to waggle the scroll position

The scrollbar shows by moving your mouse in the viewport, no need to waggle anything per se, but I get your viewpoint (no pun intended), e.g. it doesn't show up with ctlr-tab between tabs - the mouse must move

(In reply to Simon Mainey from comment #17)

I'm not a big fan of having to waggle the scroll position

The scrollbar shows by moving your mouse in the viewport, no need to waggle anything per se, but I get your viewpoint (no pun intended), e.g. it doesn't show up with ctlr-tab between tabs - the mouse must move

In that particular case, I was referring to the behaviour on mobile platforms where the behaviour originated. On the desktop, it'd be better, but still not ideal for two reasons:

  1. It'd be distracting to have something like that popping in whenever the mouse crosses the browser. (I have sensory processing issues and it's bad enough that the extension ecosystem never completely recovered from the switch to WebExtensions killing off legacy "make animation toggle-able" extensions.)

  2. I'd prefer not to have to take my hand off the keyboard or do a PgUp-PgDown dance just to check my position or do as I did back when there was no way to disable Ctrl+Q and implement an X11-level hack (or, given the advance of Wayland, maybe an evdev/uinput-level hack) to filter/synthesize events to work around limitations in the browser)

(In reply to Simon Mainey from comment #14)

ui.useOverlayScrollbars = 1 works for element and viewport scrollbars, at least on Windows - not sure when it was added

It's there since forever.

I'm not sure what pref takes precedence, I think it is ui.useOverlayScrollbars which we could enforce on desktop as 1 if RFP is enabled - this is mainly for linux entropy - windows/android users should be the same, and macOS has two possible values (AFAIK) - but standardizing across all platforms seems reasonable to me

emilio: what are your thoughts?

Scrollbar size should be the same within the same platform nowadays, even on Linux, modulo obscure Win32 registry settings. What am I missing? Anyways, on Linux now we "properly" support overlay scrollbars via widget.gtk.overlay-scrollbars.enabled.

Flags: needinfo?(emilio)

Scrollbar size should be the same within the same platform nowadays, even on Linux

By default? Isn't there a plethora of prefs to change widgets and desktop environment themes? rhetorical

OK, so there's nothing now stopping us enforcing the same width per platform. And since the overlay prefs override all the others, I suggest we enforce those with RFP? pinging tom, richard - assuming the windows one is shippable, we could land this next release to see what happens, in time for ESR102

Flags: needinfo?(richard)

(In reply to Simon Mainey from comment #20)

By default? Isn't there a plethora of prefs to change widgets and desktop environment themes? rhetorical

We paint Adwaita scrollbars, even on non-adwaita themes.

Bear in mind that some people (eg. KDE users), myself included, put this in our rcfiles, which is probably why I don't see overlay scrollbars in my Flatpak'd Firefox currently, given that Flatpak'd application do complain about the LD_PRELOAD=libgtk3-nocsd.so.0 set by the gtk3-nocsd APT package:

# Workaround for GTK+ 3.x scroll-wheel-on-unfocused-window bug
# Source:
#   https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1240957
#   https://bugs.kde.org/show_bug.cgi?id=348270
export GDK_CORE_DEVICE_EVENTS=1

# Where possible, disable GTK+ 3.x client-side window decorations
# (Where impossible, look for alternative programs)
export GTK_CSD=0

# Prefer XDG portal-provided file dialogs outside of Flatpak too
# (Also helps with the "where impossible" for GTK_CSD=0)
export GTK_USE_PORTAL=1

# No overlay scrolling please. Having a scroll handle just float over content
# looks tacky and ugly without going full swipe-to-scroll Android/iOS UI.
export GTK_OVERLAY_SCROLLING=0

Oh, to clarify, some of this stuff (eg. the gtk3-nocsd package) is default on some distros. (I believe gtk3-nocsd was created and is maintained by the LXDE/LXQt developers and is installed by default on Lubuntu)

(In reply to Simon Mainey from comment #20)

Scrollbar size should be the same within the same platform nowadays, even on Linux

By default? Isn't there a plethora of prefs to change widgets and desktop environment themes? rhetorical

OK, so there's nothing now stopping us enforcing the same width per platform. And since the overlay prefs override all the others, I suggest we enforce those with RFP? pinging tom, richard - assuming the windows one is shippable, we could land this next release to see what happens, in time for ESR102

Great!

Flags: needinfo?(richard)

(In reply to Richard Pospesel (Tor Browser Dev) from comment #24)

Great!

Cool! So you're OK with forcing overlay rather than set widths per platform? Taking into account Stephan's comments (I'm not Linux knowledgeable), who wants to do it?

(In reply to Stephan Sokolow from comment #22)

Bear in mind that some people (eg. KDE users), myself included, put this in our rcfiles, which is probably why I don't see overlay scrollbars in my Flatpak'd Firefox currently, given that Flatpak'd application do complain about the LD_PRELOAD=libgtk3-nocsd.so.0 set by the gtk3-nocsd APT package:

The reason you don't see them is because GTK overlay scrollbars are not enabled by default on release. Once they are you can enable and disable them from about:preferences.

Severity: normal → S3

We're discussing this in tor browser (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22137) and we're planning on just using overlay scrollbars on all platforms to allow each instance to draw scrollbars in whatever style without the width being exposed. Also, see related bug 1690038.

Overlay scrollbars are not always easy for users to see because they tend to be thin and only show the track on hover, which can be an accessibility problem. So we were planning on enabling a "non-overlay style" option for overlay scrollbars, to make them look as much like the non-overlay scrollbars as possible, with the exception that they don't take up any content size and will disappear if the mouse hasn't moved for some time. Mostly, this would be done by always draw the scrollbar track by avoiding this block of code https://searchfox.org/mozilla-central/rev/6f77213807eb5359c8afe458ac5628f973e92a25/widget/ScrollbarDrawing.cpp#188-191 There would be some platform-specific changes as well, like removing the half-width scrollbar thumb on linux.

My initial thought is to use this "non-overlay style" whenever NativeGetInt(IntID::UseOverlayScrollbars) is 0. I.e. whenever we override the native overlay logic. But I think we also want a preference to enable or disable this "non-overlay style" explicitly, mostly for windows 10 users who would otherwise be getting the "non-overlay style".

@emilio we could uplift whatever we put together. Out of the following, what would do you think would be good for firefox:

  1. Always using overlay scrollbars when resist fingerprinting is enabled.
  2. Whenever this overrides the native logic, the scrollbar will still not take up any content size and will fade with no mouse movement, but will always be painted in a "non-overlay style". Otherwise we use the normal overlay style.
  3. Adding a preference to explicitly enable or disable this "non-overlay style".

I would also appreciate any other insights in this area.

Flags: needinfo?(emilio)

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #27)

Overlay scrollbars are not always easy for users to see because they tend to be thin and only show the track on hover, which can be an accessibility problem. So we were planning on enabling a "non-overlay style" option for overlay scrollbars, to make them look as much like the non-overlay scrollbars as possible, with the exception that they don't take up any content size and will disappear if the mouse hasn't moved for some time.

Wouldn't that occlude a fair amount of content?

My initial thought is to use this "non-overlay style" whenever NativeGetInt(IntID::UseOverlayScrollbars) is 0. I.e. whenever we override the native overlay logic. But I think we also want a preference to enable or disable this "non-overlay style" explicitly, mostly for windows 10 users who would otherwise be getting the "non-overlay style".

I'm confused, what's wrong with the existing ui.useOverlayScrollbars preference?

  1. Always using overlay scrollbars when resist fingerprinting is enabled.

That seems trivial-ish.

  1. Whenever this overrides the native logic, the scrollbar will still not take up any content size and will fade with no mouse movement, but will always be painted in a "non-overlay style". Otherwise we use the normal overlay style.
  2. Adding a preference to explicitly enable or disable this "non-overlay style".

I'd rather add an explicit ScrollbarStyle member or pref for this, if needed. Though I think you get most of the way there by choosing Win10 scrollbars + overlay scrollbars?

I would also appreciate any other insights in this area.

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.

Maybe tor just needs to set an override size + style?

Flags: needinfo?(emilio)

Thanks for the reply.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

Wouldn't that occlude a fair amount of content?

It would depend on the styling, but yes up to ~20px. The idea is that it would still disappear like overlay scrollbars normally do when the mouse is not being moved over the content. Most scrollable content tends to have some padding anyway, so I'm not sure how often this would block text, but I'll have to test a few web pages.

I'm confused, what's wrong with the existing ui.useOverlayScrollbars preference?

We could use ui.useOverlayScrollbars to force all platforms to use overlay scrollbars, but since this is meant to be a resist fingerprinting feature (when we upstream it) we want it to be controlled by that preference and leave ui.useOverlayScrollbars unset.

I'd rather add an explicit ScrollbarStyle member or pref for this, if needed. Though I think you get most of the way there by choosing Win10 scrollbars + overlay scrollbars?

Like adding another ScrollbarDrawing file? I think we want this "non-overlay style" to visually match the desktop style, so it would be more of a variation of the existing drawing styles. Like I said, it would mostly come down to drawing the track and we'd make adjustments around this depending on the scrollbar style.

If we do make this its own pref, it would only be used for resist fingerprinting users.

I would also appreciate any other insights in this area.

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.

It is not as bad on linux, but I think there is more fingerprinting potential on windows without the override.

Maybe tor just needs to set an override size + style?

An override size was the initial plan, but it would need to be reasonably large, so I guess we wouldn't do that on android. How would this work with different DPIs on windows?

I hadn't considered the override style, we could just give everyone windows 10 style. However, there were two things that swayed me to user overlay scrollbars:

  1. It seems overlay scrollbars are becoming the default, being used on mobile, macos, GNOME, and windows 11. I think with most people using windows 10, we could probably use non-overlay scrollbars for everyone right now, but I don't think it'll last long.
  2. Using overlay scrollbars allows us to draw the scrollbars in a desktop appropriate way, and to match user preferences.

I suppose a third option I hadn't considered before was "reserving" the same amount of space on all platforms, but not necessarily filling it entirely when painting. Just seems like extra padding though.

@emilio After doing more research and asking the firefox accessibility team, for Resist Fingerprinting I think there are two options (for desktop) that are mostly accessible:

  1. Force non-overlay scrollbars with a universal and fixed width of 24px to meet the minimum size requirements for AA accessibility. Note that this is softer than the AAA criteria of 44px. For comparison, the current default size on windows is 17px and it is the same on macos.
  2. Force overlay scrollbars, which allows for variable scroll widths. As a compromise, when non-overlay scrollbars would have been preferred by the user's (accessibility) settings, try and make them more accessible. Specifically, there are three changes that were recommended to me by the accessibility team:
    a. Always use a full-width thumb when drawing to improve visibility (rather than drawing half-width when non-hovered and non-active).
    b. Draw the track when it is hovered or active (as we do now), but also when the mouse moves within ~50px (rather than always drawing it on mouse move, as I suggested before).
    c. Be able to dismiss the scrollbar with Escape key press and don't draw it again until the user has moved the mouse sufficiently outside the scrollbar track. Similar to the tooltips shown via the title attribute. This would allow the user to dismiss the scrollbar if it is covering content, especially for interactive content.

Option 1 is much easier to achieve implementation-wise, but if option 2 can be achieved it would allow for variation in the scrollbar sizes. Does option 2 seem feasible to you and something you are likely to accept in firefox?

Part 2c seems useful for overlay scrollbars in general (regardless of whether we have thick thumbs). Do you know where the code is that handles the tooltip display and the Escape behaviour?

Part 2b would require some extra state information for the scrollbar to track the mouse position relative to the scrollbar, maybe that could be handled in ScrollbarActivity.cpp.

Part 2a and 2b would also require a preference to track whether to apply them or not. I feel like we would want a three-way value: "on", "off" and "default". Where "default" will switch on the feature if useOverlayScrollbars is false, i.e. if overlay scrollbars have been forced on by resist fingerprinting.

Flags: needinfo?(emilio)

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #30)

@emilio After doing more research and asking the firefox accessibility team, for Resist Fingerprinting I think there are two options (for desktop) that are mostly accessible:

  1. Force non-overlay scrollbars with a universal and fixed width of 24px to meet the minimum size requirements for AA accessibility. Note that this is softer than the AAA criteria of 44px. For comparison, the current default size on windows is 17px and it is the same on macos.

I'm pretty sure that'd break some websites fwiw. I'd leave it at 17 unless there's a very strong reason not to.

  1. Force overlay scrollbars, which allows for variable scroll widths. As a compromise, when non-overlay scrollbars would have been preferred by the user's (accessibility) settings, try and make them more accessible. Specifically, there are three changes that were recommended to me by the accessibility team:
    a. Always use a full-width thumb when drawing to improve visibility (rather than drawing half-width when non-hovered and non-active).

That seems rather unfortunate as that means they'd get in the way of content a lot more easily...

b. Draw the track when it is hovered or active (as we do now), but also when the mouse moves within ~50px (rather than always drawing it on mouse move, as I suggested before).

Same issue...

c. Be able to dismiss the scrollbar with Escape key press and don't draw it again until the user has moved the mouse sufficiently outside the scrollbar track. Similar to the tooltips shown via the title attribute. This would allow the user to dismiss the scrollbar if it is covering content, especially for interactive content.

I see, so this is rather tricky, in the sense that I wouldn't expect "Esc" to have an effect on the scrollbar at all as a user, and would be very specific to RFP, which means it'd invariably break... If we'd consider enabling it by default it might be a bit more palatable, but see below...

Option 1 is much easier to achieve implementation-wise, but if option 2 can be achieved it would allow for variation in the scrollbar sizes. Does option 2 seem feasible to you and something you are likely to accept in firefox?

Part 2c seems useful for overlay scrollbars in general (regardless of whether we have thick thumbs). Do you know where the code is that handles the tooltip display and the Escape behaviour?

That's very different code. Tooltip code lives here. The scrollbar code would need to deal with it here. You'd like to probably also deal with Escape there, though the main issue is that keyboard events don't get sent at the position of the mouse but at DOM focus, so I'm not sure how to best deal with it.

Part 2b would require some extra state information for the scrollbar to track the mouse position relative to the scrollbar, maybe that could be handled in ScrollbarActivity.cpp.

Yeah (sorry, replying top to bottom, should've read the whole thing first clearly!)

Part 2a and 2b would also require a preference to track whether to apply them or not. I feel like we would want a three-way value: "on", "off" and "default". Where "default" will switch on the feature if useOverlayScrollbars is false, i.e. if overlay scrollbars have been forced on by resist fingerprinting.

That seems doable... I suspect the harder thing here will be testing, and the key event stuff...

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)

I'm pretty sure [24px scrollbars would] break some websites fwiw. I'd leave it at 17 unless there's a very strong reason not to.

I guess it would break it because the scrollable area is too thin, so there is not enough room for a scrollbar? Can you think of a website that might be susceptible? I suppose websites can use scrollbar-width: thin for cramped content, but that may not be generally used.

I was following the WAI accessibility guide for minimum sizes, e.g. as referenced here where it is acknowledged that most browsers do not follow this. However, after a quick search it seems that there is no way to change this width on windows OS without doing some hacking, so it doesn't seem this option has been generally shown to users on windows and/or firefox.

That seems rather unfortunate as that means they'd get in the way of content a lot more easily...

Same issue...

Yes, I think that is why the Escape behaviour was recommended to me.

You'd like to probably also deal with Escape there, though the main issue is that keyboard events don't get sent at the position of the mouse but at DOM focus, so I'm not sure how to best deal with it.

Good point.

That seems doable... I suspect the harder thing here will be testing, and the key event stuff...

I think for the time being, since most users are on windows 10 or lower, forcing non-overlay scrollbars with the same width is the way to get an easy fix for Resist Fingerprinting. I will test out 24px vs the current 17px and settle on one (probably sticking to 17px). How does that sound to you for in firefox?

Once overlay scrollbars become more common on desktop (as they are in windows 11) and we can solve the accessibility issues, we could switch to overlay scrollbars then, but I agree that if the behaviour is only exposed behind Resist Fingerprinting it won't receive much attention and testing. I think we would need to do some proper user testing (in tor browser) to really know if it works and is better than the non-overlay scrollbars.

Flags: needinfo?(emilio)

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #32)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)

I'm pretty sure [24px scrollbars would] break some websites fwiw. I'd leave it at 17 unless there's a very strong reason not to.

I guess it would break it because the scrollable area is too thin, so there is not enough room for a scrollbar? Can you think of a website that might be susceptible? I suppose websites can use scrollbar-width: thin for cramped content, but that may not be generally used.

Pretty sure youtube in fullscreen mode used to have a hard-coded 17px shift to hide the root scrollbar. Maybe they fixed it a while ago. But I suspect other sites might have similar assumptions.

I was following the WAI accessibility guide for minimum sizes, e.g. as referenced here where it is acknowledged that most browsers do not follow this. However, after a quick search it seems that there is no way to change this width on windows OS without doing some hacking, so it doesn't seem this option has been generally shown to users on windows and/or firefox.

Yeah, that's bug 1786665.

I think for the time being, since most users are on windows 10 or lower, forcing non-overlay scrollbars with the same width is the way to get an easy fix for Resist Fingerprinting. I will test out 24px vs the current 17px and settle on one (probably sticking to 17px). How does that sound to you for in firefox?

So that's doable right now with ui.useOverlayScrollbars=0 and widget.non-native-theme.scrollbar.size.override=17 (or 24 or what not right?)

I'd be ok introducing an special resistFingerprinting switch if needed (though it's a bit unfortunate).

Once overlay scrollbars become more common on desktop (as they are in windows 11) and we can solve the accessibility issues, we could switch to overlay scrollbars then, but I agree that if the behaviour is only exposed behind Resist Fingerprinting it won't receive much attention and testing. I think we would need to do some proper user testing (in tor browser) to really know if it works and is better than the non-overlay scrollbars.

Agreed.

Flags: needinfo?(emilio)

ok. Thanks for the help and insights! I'll come back with a patch at some point.

As long as there's a way to pin it visible, whether using wheel scrolling or PageUp/PageDown/Up/Down keyboard scrolling (eg. park the cursor over the track and leave it there), so I don't have to do something like tapping Up/Down or Down/Up to check my reading progress, I could get used to overlay scrollbars.

Not all sites do as FiMFiction does and construct their own content-scoped scroll progress indicator on another edge of the screen.

emilio: is it possible/feasible to engineer (non-overlay) scrollbars to always use full pixels

Duplicate of this bug: 1690038

(In reply to Thorin [:thorin] from comment #36)

emilio: is it possible/feasible to engineer (non-overlay) scrollbars to always use full pixels

What does a full pixel mean in this context? Full CSS pixel? Full device pixel?

All of them. Any measurements via any method are integers

Edit: TBH my motive here is for you to say it's not feasible. I've followed comments like https://github.com/w3c/csswg-drafts/issues/5260 and understand the issue of subpixels re entropy. In Bug 418986 for example we limited a number of metrics to return the zoom value, i.e ignore dpi, devicePixelRatio, etc - as this makes it harder for trivial fingerprinting. Subpixel entropy will still exist elsewhere, and I suspect scrollbar subpixels is equivalency, but depending on how it's calculated, it may in fact add to it. I've also seen patches that limit the results, e.g. in fonts, to 1/4ths or 1/8ths, etc. So perhaps we can snap to full pixels with RFP, or limit the differences. That said, my position has always been to use overlays, and that's what I'm looking for - that my solution is the only solution.

So right now at least, scrollbar sizes like most widget sizes return int device pixels: https://searchfox.org/mozilla-central/rev/fa86401b80f19afb6ed9bfca127ecc5e3a6f0cdc/gfx/src/nsITheme.h#113

That means that they could be different depending on zoom / dpi. That said, things like https://phabricator.services.mozilla.com/D98100 would avoid that issue.

Duplicate of this bug: 1913639
Blocks: tor-uplift-esr140
See Also: → https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22137
Whiteboard: [tor][fingerprinting][fp-triaged][tor 22137] → [tor][fingerprinting][fp-triaged][tor 22137][tor 22137]
Whiteboard: [tor][fingerprinting][fp-triaged][tor 22137][tor 22137] → [tor][fingerprinting][fp-triaged][tor 22137]
You need to log in before you can comment on or make changes to this bug.