1909736 - RFP: hide textDecoration's underline computedStyle on links

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[Thorin [:thorin]]

Bug 1858397 and Bug 1664278 added the ability for users to always (or not) underline links. This adds a fingerprinting bit by checking a link with getComputedStyle(element).textDecoration

• e.g. with underline you would get underline rgb(157, 178, 220) and without you get rgb(157, 178, 220)

Either under RFP or for all users, we think this should property should be hidden in link elements, just like we protect visited link status (color)

Comment 1

[Emilio Cobos Álvarez (:emilio)]

The reason for visited protections is completely different (not exposing your history).

I'm not convinced this is worth it, clicking the "always underline links" is no different to using a user stylesheet... We could move the implementation to later in the pipeline rather than CSS, but that'd just make it harder really (you can paint an SVG image with a link on a canvas and see if you get an underline for example).

Comment 2

[Thorin [:thorin]]

So from TB's (RFP's) perspective, we protect canvas. Meanwhile we also protect against binary choices such as prefers dark/light. If a site (or user) sets links to be underlined, that's different IMO. This is about exposing the default setting in the UI. That is expose a link without an underline and then check if it has one - unless I'm missing something. We'd could of course remove the UI and set the pref (even lock it), but that's not exactly accessibility friendly. Just exploring if we can do it another way - that is never report underlined

Comment 3

[Tom Ritter [:tjr]]

(In reply to Thorin [:thorin] from comment #2)

So from TB's (RFP's) perspective, we protect canvas.

I hope that we can get to a point where we make canvas nearly unfingerprintable and then stop protecting it :) So this would be a problem at that point.

This is about exposing the default setting in the UI. That is expose a link without an underline and then check if it has one - unless I'm missing something.

Right, if the user has set the behavior - then they are more unique, fingerprint-wise.

Just exploring if we can do it another way - that is never report underlined

It sounds like the canvas bypass means this has a limited lifespan. Or at least, hopefully limited...

We'd could of course remove the UI and set the pref (even lock it), but that's not exactly accessibility friendly.

It seems like this is another case where Firefox-exposed settings (not preferences) can result in making you fingerprintable - just like changing your default font, font size, or colors. At least soon we will know how much people actually change these prefs....