Open Bug 1861362 Opened 2 years ago Updated 2 months ago

Stop exposing system accent color by default

Categories

(Core :: Widget, task, P3)

Product:
Core
Component:
Widget
Type:
task

Tracking

()

People

(Reporter: mt, Unassigned)

References

(
URL
)

Details

This has some trade-offs, but I think that the balance of privacy vs. utility is off here.

On systems where widget.non-native-theme.use-theme-accent is true (all except Windows currently), this is quite visible in terms of form controls and highlight colors. That increases the feeling that Firefox is integrated with the system.

However, exposing this to content provides many bits of fingerprinting entropy. People do customize their phones with themes. Highlight colors are often derived from either the theme or things like the choice of home screen background image. This won't be the full 24 bit color depth, but it's not as little as the other accessibility things we expose (which are of much higher value).

Component: Theme → Widget
Product: Firefox → Core
Severity: -- → S3
Priority: -- → P3

notes:

  • false on windows, true everywhere else, but that could change
  • at least on windows, the pref is real-time (android we think requires a force restart)
  • this doesn't seem to affect any chrome

emilio, are there any reasons why this couldn't be behind a RFPTarget and controlled per site - that is we would like to not use system accent with RFP/RFPTarget enabled otherwise fall back to the pref value | cc tjr

Flags: needinfo?(emilio)

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

at least on windows, the pref is real-time (android we think requires a force restart)

It should also be dynamic.

this doesn't seem to affect any chrome

Can you elaborate? You mean chrome pages? If so... it does, some of the callers don't have access to a document handy.

emilio, are there any reasons why this couldn't be behind a RFPTarget and controlled per site - that is we would like to not use system accent with RFP/RFPTarget enabled otherwise fall back to the pref value | cc tjr

No reasons other than the above, we'd have to fix stuff so that things like ThemeColors's default color palette etc handle this. All the callers eventually have access to a document or so.

Flags: needinfo?(emilio)

So RFP (target is UseStandinsForNativeColors) seems to already protect AccentColor [1]. Is there another way to get the color (and not in canvas) - OP didn't provide any PoCs

[1] STR windows

did I miss something here?

It should also be dynamic.

yup :)

Note, we looked into this a little bit in Tor Browser. See my comment in gitlab for more context.

Summary

After a little bit of research, my conclusion was that RFP seems to already protect against measurement by web content, but the current experience with RFP and widget.non-native-theme.use-theme-accent set to true is somewhat inconsistent:

  1. Text highlight will use the stand in color (blue).
  2. Custom styling applied by web pages, using AccentColor etc, will use the stand in color (blue).
  3. Checkboxes and other widgets will use the system color.
  4. Focus outline will use the system color.

So by switching widget.non-native-theme.use-theme-accent to false we change to last two cases to also use the stand in (blue) color instead, which makes the styling for web pages more consistent for the user.

So, I guess in Firefox you would want the current effect of widget.non-native-theme.use-theme-accent to be dependent on RFP.

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

So RFP (target is UseStandinsForNativeColors) seems to already protect AccentColor [1]. Is there another way to get the color (and not in canvas) - OP didn't provide any PoCs

[1] STR windows

I don't think it should be visually pink after that last step. At least testing on linux, the AccentColor's visual presentation and measurement should match.

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #4)

  1. Checkboxes and other widgets will use the system color.
  2. Focus outline will use the system color.

Just to be clear, I don't think there is any RFP-specific mechanism to stop these colors being measured by web content. It is just that I'm not aware of a way for content to measure these. E.g. the getComputedStyle().borderColor of a focused <input> will be grey, rather than the visual accent color.

@pierov tried to do this.

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

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

at least on windows, the pref is real-time (android we think requires a force restart)

It should also be dynamic.

Yes, I confirm flipping the pref is immediate.
In my comment downstream from some hours ago I meant that any changes in system theme require a force-stop and restart, at least on my Pixel 4a (I added a clarification now).

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #5)

I don't think it should be visually pink after that last step. At least testing on linux, the AccentColor's visual presentation and measurement should match.

sorry, I should have been clearer. The TZP css test, using AccentColor is visually blue. A (edit: unstyled) checkbox, radio button, focused text input is visually pink

I very, very much do not want this. Perhaps, this would be a useful change for about:preferences#privacy:~:text=Known%20fingerprinters's fingerprinting protection to make, but it should not be the default. I don't care how much my browser is fingerprinted, nor does the lay man, but they shall, and I do, care about having sites not adapt to their themes.

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