The scrollbar in TBB is enabled and disabled based on a setting in macOS system preferences

The scrollbar in TBB is enabled and disabled based on a setting in macOS system preferences, this can be used to fingerprint users. TBB 7.0.1

Trac:
Username: Dbryrtfbcbhgf

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::low in Legacy / Trac reporter::Dbryrtfbcbhgf in Legacy / Trac severity::minor in Legacy / Trac status::reopened in Legacy / Trac tbb-fingerprinting in Legacy / Trac type::defect in Legacy / Trac labels

Here is a video showing the bug. https://filenurse.com/download/321b77b27e20114dc4e9dbaa46410840.html

Trac:
Username: Dbryrtfbcbhgf

This is not a bug. There are far, far worse tracking vectors in the open at the moment. If you keep javascript disabled, the scrollbars disappearing (or not) definitely cannot be detected. Merely enabling javascript access (even with the many good modifications the TorProject has made to Mozilla's code) opens up so many APIs that it is very difficult to prevent getting tracked - the DOM sucks. Leaving the macOS default for scrollbars is probably the best choice.

If I am being harsh here, please provide more detail and evidence to show that this actually is a serious tracking vector when weighed against all the other tracking vectors in the wild. Otherwise, adding these kinds of bugs only clogs the bug tracker.

Trac:
Resolution: N/A to not a bug
Severity: Major to Minor
Status: new to closed
Priority: Medium to Low

While I agree that this is low priority I still think it should not be possible for websites to get that bit of information out of macOS users.

Trac:
Status: closed to reopened
Keywords: N/A deleted, tbb-fingerprinting added
Resolution: not a bug to N/A

Is there any evidence of such fingerprinting or a known way that js can be used to detect the status of the scrollbar? I am 99% certain without javascript it is impossible. Unless there is anything here beyond mouse tracking with javascript, which already has a ticket, shouldn't there be some evidence brought forward?

I know this really should be in another ticket, but I don't like adding duplicate or unnecessary ones (there are enough already) - does anyone know if ClientRects fingerprinting has been examined in TorBrowser? https://browserleaks.com/rects .

Imho though, if you let the tens of thousands of lines of js code (e.g. https://www.youtube.com/yts/jsbin/www-en_US-vflBNfd5x/base.js) (https://www.youtube.com/yts/jsbin/player-vfle90bgw/en_US/base.js) that most mainstream sites include run, as I said, it is practically impossible to stop some form of fingerprinting. The only way this will improve is if more real-world analysis of javascript tracking is done - examining which APIs are used, to RE obfuscated code.

Either the DOM/ECMAScript are changed fundamentally and browser developers stop adding new unnecessary APIs every other day, emphasize security/privacy, document preferences properly, encourage control and encourage web developers to follow the principles of progressive enhancement.

moved from legacy/trac#22632 (moved)

added Bug label and removed 1 deleted label

added Fingerprinting label and removed 1 deleted label

upstream: 1690038

mentioned in issue #40184 (closed)

mentioned in issue #22137

mentioned in issue #40789

let's call this a dupe of #22137

slow down or we'll have no tickets left to work on

the horror

closed