Open Bug 1397994 Opened 3 years ago Updated 9 months ago

CSS line-height reveals platform

Categories

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

55 Branch
defect

Tracking

()

Tracking Status
firefox57 --- fix-optional
firefox58 --- affected

People

(Reporter: simon.mainey, Unassigned)

References

(Blocks 1 open bug)

Details

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

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

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