Closed Bug 1397994 Opened 7 years ago Closed 3 years ago

CSS line-height reveals platform

Categories

(Core :: CSS Parsing and Computation, defect, P5)

Product:
Core
Component:
CSS Parsing and Computation
Version:
55 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox57 --- fix-optional
firefox58 --- affected

People

(Reporter: simon.mainey, Assigned: pierov)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor 23104][tor 23701][tor 29563][fingerprinting][fp-triaged])

Attachments

(1 file)

The patch for Firefox 91.9.0 ESR that we are using in Tor Browser
(deleted), patch
Details | Diff | Splinter Review
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] > It is possible to detect the platform a Tor Browser is running with the CSS line-height attribute: 19px is used on Linux, 19.5167px on macOS, and 19.2px or 20px on Windows. [1] https://trac.torproject.org/projects/tor/ticket/23104
Flags: needinfo?(ettseng)
Blocks: uplift_tor_fingerprinting
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ettseng)
Whiteboard: [tor][fingerprinting]
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Priority: -- → P2
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-backlog]
Whiteboard: [tor][fingerprinting][fp-backlog] → [tor][fingerprinting][fp:m4]
Priority: P2 → P3
It looks like the current patch only changes behavior if the (off-by-default) privacy.resistFingerprinting pref is enabled, so let's call this "fix-optional" for 57. (Hypothetically if it's fixed on trunk soonish, and if we need it on 57, we could conceivably uplift without too much risk.)
status-firefox57: --- → fix-optional
status-firefox58: --- → affected
This doesn't seem all that interesting unless tor browser also ships with fonts, and then forbids use of OS fonts, since a big part of what it's hiding is what the default fonts are, which is easily detectable through horizontal metrics as well. (It's also possible to distinguish between versions of fonts based on character fallback, etc., depending on what the differences between font versions are.) Does it do so? (I'm also skeptical that avoiding exposing Mac vs. Windows vs. Linux is realistic.)
(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #3) > This doesn't seem all that interesting unless tor browser also ships with > fonts It does. (Makes the linux distribution huge I believe) > and then forbids use of OS fonts Their code says "restrict to a selection": https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-52.3.0esr-7.5-2#n367 and the per-OS pref is different, so I don't think so. > (I'm also skeptical that avoiding exposing Mac vs. Windows vs. Linux is > realistic.) Tor is as well. They will fix things when it's simple, but they realize it's very difficult if not impossible (And don't pay bounties for it for example.)
Whiteboard: [tor][fingerprinting][fp:m4] → [tor 23104][tor 23701][fingerprinting][fp:m4]
Priority: P3 → P5
Whiteboard: [tor 23104][tor 23701][fingerprinting][fp:m4] → [tor 23104][tor 23701][fingerprinting][fp-triaged]

(In reply to Tom Ritter [:tjr] (On Leave) from comment #1)

Tor's patch: https://gitweb.torproject.org/tor-browser.git/patch/?id=722fd29

also see https://trac.torproject.org/projects/tor/ticket/29563 - where the tor patch (there may have been other patches since) seems to be inconsistent with at least Linux on various zoom levels (e.g as compared to say Windows). I do not know if this is a limitation, or a design decision by the patch authors

Whiteboard: [tor 23104][tor 23701][fingerprinting][fp-triaged] → [tor 23104][tor 23701][tor 29563][fingerprinting][fp-triaged]

In FF69+ there is a pref layout.css.line-height.normal-as-resolved-value.enabled (see Bug 1536871) when set as true will return normal for getComputedStyle for value line-height. It is currently enabled as default true in 69. We could backport 1536871 to Tor Browser and/or enforce this with RFP (or just wait to see if it makes stable as true).

Note that the pref is only on for nightly and early beta, fwiw, since there may be compat fallout. I'll turn it on on release probably after a couple releases.

Also note that this doesn't change the layout behavior, which can be observed in other ways like getBoxQuads or such, if line-height ends up affecting the height of any box.

Since Bug 1579624 turned layout.css.line-height.normal-as-resolved-value.enabled on by default, I think this could be closed.

We will probably drop the patch from Tor Browser as well.

I don't think that matters in practice? You can observe the line-height via a bunch of other APIs that aren't getComputedStyle. But again if tor ships with the same fonts across platforms you should be getting the same normal line-height, unless I'm missing something.

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

But again if tor ships with the same fonts across platforms you should be getting the same normal line-height, unless I'm missing something.

We allow a restricted number of fonts, but at the moment they differ from platform to platform.
We ship some fonts on all platforms to support non-latin scripts (at least on Linux and Windows).
In addition to that, on Linux we ship more fonts (like Arimo, which should have the same metrics as Arial), because there isn't a unique list of available fonts that works for all installations. So we create our own list of fonts.

I don't think that matters in practice? You can observe the line-height via a bunch of other APIs that aren't getComputedStyle.

We decided to enable platform specific navigator.userAgent (while keeping Windows on the User-Agent header), so getting the platform is as trivial as checking that string with JS enabled.
I know that some fingerprinting can be done also without JS, but I wonder whether it is possible to leverage the line-height.

That said, let me know if you think that the patch is good (I am attaching it) and you are interested in getting it in Firefox 🙂️.

Assignee: nobody → pierov

(In reply to Pier Angelo Vendrame from comment #8)

We will probably drop the patch from Tor Browser as well.

(In reply to Pier Angelo Vendrame from comment #10)

We decided to enable platform specific navigator.userAgent (while keeping Windows on the User-Agent header), so getting the platform is as trivial as checking that string with JS enabled.

Given these^ notes, I think we can close this as WONTFIX (unless there's a different compelling motivation for taking this patch or one like it besides trying-to-make-it-harder-to-detect-the-user's-OS).

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX

Given these^ notes, I think we can close this as WONTFIX

lineheight might reveal major OS (guesswork based on a dataset of default fonts and sizes and styles (language), zoom and/or layout.css.devPixelsPerPx), but it can also reveal more entropy. All those affect measurements, but we could ultimately control.

That said, we should investigate this downstream, to see what else affects this, e.g. devicePixelRatio, system scaling, GPU rendering of fonts, clearType, font versions (ignoring diffs in supported unicode code points) ...

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

Attachment

General

Creator:
Created:
Updated:
Size: