Opened 6 months ago

Last modified 6 months ago

#29563 new defect

css line-height revisted [at least zoom and linux]

Reported by: Thorin Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-os
Cc: igt0 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The mozilla upstream ticket is https://bugzilla.mozilla.org/show_bug.cgi?id=1397994

Following on from #23104, it seems that when applied on various (preset) zoom levels, that there are differences between Windows and Linux (I do not have any macOS or macOS X machines to test on)

Tor Browser (and RFP in Firefox) actively ignores site specific zoom levels, and new tabs/windows will open at 100% zoom. But that does not stop someone from using zoom, and indeed the setting stays for the current tab when re-used (even when the domain changes - i.e it is a per tab setting in this context). Examples are poorly designed websites, small devices, users with poor eyesight - where the user is effectively forced to zoom (in or out)

Looking at some test results: I used https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent - see the css line-height field (and feel free to zoom and refresh) - also see the attachment for some spreadsheet results (png), which is not definitive, but enough to draw some conclusions.

Clearly the mitigation in Windows covered all zoom settings, so was this a design decision? In Linux, it seems as if zoom was only factored in for 50, 100, 150, 200, and 300 (of the preset zoom levels). Is this because of some limitation in Linux?

As a result, so far, at least 8 zoom levels in TBB on Linux are unique and leak the OS as Linux. The 9th zoom level not covered (30%) is not unique in Firefox overall, but is unique on Tor Browser (it is trivial to detect if Tor Browser is being used, so this is in effect a unique value as well)

Note: for Tor Browser, you're not concerned with the Firefox values, I'm just showing them so you can see that outside of 100% zoom, without FP'ing protection, some results are not necessarily OS specific: e.g. FF62+ Windows and Linux are identical at 50, 67, 80, 90, 150, and 240%.

Child Tickets

Attachments (1)

TBB-cssLH-Linux.png (37.8 KB) - added by Thorin 6 months ago.
spreadsheet results as png

Download all attachments as: .zip

Change History (6)

Changed 6 months ago by Thorin

Attachment: TBB-cssLH-Linux.png added

spreadsheet results as png

comment:1 Changed 6 months ago by Thorin

Component: ApplicationsApplications/Tor Browser
Owner: set to tbb-team

comment:2 in reply to:  description Changed 6 months ago by gk

Replying to Thorin:

Clearly the mitigation in Windows covered all zoom settings, so was this a design decision? In Linux, it seems as if zoom was only factored in for 50, 100, 150, 200, and 300 (of the preset zoom levels). Is this because of some limitation in Linux?

That was not a design decision. We have not been testing the patch against various zoom levels back then (at least I did not).

comment:3 Changed 6 months ago by gk

Cc: igt0 added

Oh, and nice visualization, thanks!

comment:4 Changed 6 months ago by Thorin

oooh .. I have lots of visualizations :) building up quite a nice test suite here. Does anyone have any access to macOS and macOS X?

comment:5 in reply to:  4 Changed 6 months ago by mcs

Replying to Thorin:

Does anyone have any access to macOS and macOS X?

On a macOS 10.13.16 system that has a "Retina" (@2x) display, the https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent page reports 19.2px for all zoom levels.

Note: See TracTickets for help on using tickets.