Fingerprinting and Accessibility

This is a general issue to discuss the impact resist fingerprinting (RFP) is having on accessibility. Maybe we can organise some research and link related issues.

On the surface, there is a potential conflict between the goal of "make every user look the same online" and the fact that lots of users have different needs and usage patterns. But there could be some room for improvement and creative thinking.

Some initial thoughts:

• Tor browser is not only an anti-tracking tool. We want to make sure that users who need it for something else are not kept out by RFP.
• Some decisions made for RFP also effect accessibility. For example, we force CSS media queries (prefers-contrast, prefers-color-scheme, prefers-reduced-motion).
• Can we choose better values?
• Can we allow for punching some holes in these?
• Can we add some noise so that users who can handle either value can adopt random values to give users who need a specific value some cover?
• Can we hack in some accessibility features that are undetectable to web content. E.g. a simple one would be to inverse colors or lower contrast at the xul:browser level.
• Can we offer users guidance on tools outside of tor browser that improve accessibility without raising fingerprinting. E.g. tools that operate at the desktop level outside of web page's control, like magnifiers and color filters.
• Users of accessibility tools can end up standing out in any behaviour analysis. E.g. if you navigate with a keyboard, then the website will receive a lot of Tab and arrow key events. Can we give them better cover?

/cc @donuts @clairehurst @dan @ma1 @pierov @morgan @tjr @thorin

added Accessibility Meta Fingerprinting labels

added Roadmap::Future label

added All Platforms label

From a technical point of view, once https://bugzilla.mozilla.org/show_bug.cgi?id=1824222 lands, there will be the capability to exempt individual sites, in either a first of third party context, from individual RFP behaviors. This will be via a pref that will take a policy specified in a JSON string.

This means, for example, Tor Browser could carry a (minimal) patch that would allow a Tor Browser extension to expose the UI (whatever it may be) for a user to be able to say things like:

• I want my Dark Mode preference available to all websites except facebook.com
• I want my real prefers-color-scheme value to be available to example.com but only when it's a first party. I don't want iframes of example.com to see my real value.

Tom's example as an example is fine, but I just want to stress my total opposition to adding prefers-color-scheme to accessibility. It is a user preference, not an accessibility feature - it's not universally used, i.e arbitrary for websites to implement.

There is a UI for changing website colors including using system ones - so without checking exactly what we restricted there with RFP, that is what we should relax

sorry for the noise, but I get the vibe that all the people who have complained about prefers-color-scheme are just whinging and don't really need dark mode, and it's the wrong feature for those who do need it (dark)

sorry for the noise, but I get the vibe that all the people who have complained about prefers-color-scheme are just whinging and don't really need dark mode, and it's the wrong feature for those who do need it (dark)

This is not the issue to discuss speculation about who needs what features or not. We want research and backed-up accessibility knowledge.

I get that you might consider dark mode a visual preference rather than an absolute requirement, but there really isn't such a hard line. In general, when considering accessibility, I think it is important to remember that whilst putting up with a missing feature might be do-able for a user, it can still make their life harder.

Moreover, a lot of web accessibility features rely entirely on the web pages implementing them, and there are many examples of web pages failing to do so. So the arbitrariness of whether a feature is implemented is not a good test for whether it is an accessibility feature.

@tjr thank you for sharing the feature!

So the arbitrariness of whether a feature is implemented is not a good test for whether it is an accessibility feature.

Didn't mean to imply that. I was implying the difference with the UI feature to change website colors which is universal (RFP restrictions aside, if any) since it's implemented by the app. No more comments from me as I'm not qualified

mentioned in issue #42226

marked this issue as related to #42226

marked this issue as related to #40337

marked this issue as related to #22409

marked this issue as related to #41305

marked this issue as related to #18376

marked this issue as related to #41026

mentioned in issue #40337

marked this issue as related to #42070 (closed)

marked this issue as related to #22137

mentioned in merge request !1043 (merged)

mentioned in issue #40789

changed the description

I liked the idea brought up by manuel and tjr in our meeting.

We could highlighting the use of about:reader for users to better present long text content where we can apply custom fonts, colors, color schemes, text sizes, etc. about:reader is already exempt from some fingerprinting protections, so a lot of this will work now.

about:reader isn't always available for a web page. We could in principle allow user to highlight a section of document and copy it to an about:reader like page or popup.

Its not clear to what extent this would address everyday usage. If this is needed constantly by a user the process could be frustrating or tedious. We would probably need some testing to get some insight.

marked this issue as related to #43513 (closed)

edited - see #42226 (comment 3043570)

added Apps::Impact::High label