1623259 - privacy.resistFingerprinting + CSS4 system colors [+ other prefixed -moz- colors]

Status: RESOLVED DUPLICATE of bug 1603332

(Core :: CSS Parsing and Computation, defect)

Description

[Thorin [:thorin]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Bug 1590894 (FF76+) introduces CSS4 system colors, however, this seems to break RFP's protection (introduced in Bug 1485266)

The "new" values, AFAICT, are

• Canvas, CanvasText, LinkText, VisitedText, ActiveText, Field, FieldText

Not sure if only VisitedText is affected - see below

Actual results:

STR

• make sure RFP is enabled
• about:config: browser.display.use_system_colors = default false
  • ^^ settings > general > language and appearance > colors
• visit test site [1]
  • you should get a green RFP result
• change browser.display.use_system_colors to true
• re-run the test in [1] (might pay to hard refresh)
  • you should now get a red RFP result (assuming your system color is diff)

The only value that changed (for me) is VisitedText

• when the use_system_colors pref is false, the correct value of rgb(0, 0, 238) (dark blue) is used, when true, the system value is used: in my case it differs

Tested on Windows 7

[1] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#css

Expected results:

FYI:

• I tested previous releases
• It seems Field is returned in FF72+ (at least on my Win7)
  • 71 or lower: rgb(0, 0, 0)
  • 72+: rgb(255, 255, 255)
• toggling the system colors pref in FF75 and lower had no affect (for me)

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I don't think that bug is introducing any new issue that wasn't present before with the prefixed colors. If you use -moz-visitedhyperlinktext instead of the unprefixed version you should see the same, right?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

And when standins are used that uses the pref browser.visited_color.

Comment 3

[Thorin [:thorin]]

My understanding is that RFP bypasses ui.use_standins_for_native_colors , effectively treating it as true

• RFP = true, standins = true, system colors = true ==> still leaks

As for browser.display.use_system_colors: I'd have to test a bit more, but sure: it's probably already present with -moz- colors, but it wasn't with system colors, until now, because (IANAE) you're mapping some moz ones to the new values

There is a bug open for -moz- : bug 1603332. If fixing that bug fixes this one (and the other new items if needed?), then we can close this as a duplicate. But I see bug 1603332 as more of a meta ticket or a FF-proprietary one, whereas these are open standards

Comment 4

[Thorin [:thorin]]

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

I don't think that bug is introducing any new issue that wasn't present before with the prefixed colors. If you use -moz-visitedhyperlinktext instead of the unprefixed version you should see the same, right?

The -moz- test looks at 61 prefixed colors. In 71 + 76, the results are the same. Note: I'm already on Windows 7, and RFP is off.

The difference (for me) between use_system_colors = true vs false comes from eight items

false (default)

-moz-hyperlinktext, rgb(0, 0, 238)
-moz-mac-accentdarkestshadow, rgb(0, 0, 238)
-moz-mac-accentdarkshadow, rgb(0, 0, 238)
-moz-mac-accentface, rgb(0, 0, 238)
-moz-mac-accentlightesthighlight, rgb(0, 0, 238)
-moz-mac-accentlightshadow, rgb(0, 0, 238)
-moz-mac-accentregularhighlight, rgb(0, 0, 238)
-moz-mac-accentregularshadow, rgb(0, 0, 238)

true - all the above change to rgb(0, 102, 204)

[why do moz-mac- change on a windows machine? you don't have to answer that]

So yes, -moz-hyperlinktext has been fingerprintable if different when system colors are used, since .. forever. I'm not entirely sure my systems colors are the originals (windows 7, which is what the original RFP tried to match) - so I can't confirm other prefixed colors, including new CSS4 ones, don't also "leak"

Feel free to close this as a duplicate of Bug 1603332, since that's the underlying cause and the less bugs to track the better. **Or... ** since this breaks the intent of RFP to protect "system" colors - deal with -moz-hyperlinktext (and any other aliases) separately here. Your call :) It's not a big deal, since the pref is default false

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Yeah, let's dupe this to bug 1603332.