Open Bug 1397996 Opened 3 years ago Updated 3 months ago

scrollbar thickness reveals platform

Categories

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

55 Branch
defect

Tracking

()

People

(Reporter: simon.mainey, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

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

You need to log in before you can comment on or make changes to this bug.