1529517 - Add new prefs for defining features in content blocking categories

Status: RESOLVED FIXED

(Firefox :: Protections UI, enhancement, P2)

Description

[Johann Hofmann [:johannh]]

When introducing or promoting new content blocking features (like Fingerprinting and Cryptomining), we would like to be able to add them to content blocking categories (Standard, Strict or Custom) simply by changing prefs, without having to do front-end work every time. The front-end should look at the relevant prefs to decide how to display things to the user.

I'm imagining a pref structure similar to this:

browser.contentblocking.features.standard = "tpPrivate, 3rdPartyTrackingCookiesBasic";
browser.contentblocking.features.strict = "tp, 3rdPartyTrackingCookiesStrict";

Where "tpPrivate" etc. are magic strings that we internally map to the pref names and some other meta data and UI info like strings.

And whatever is not mentioned there would go into "Custom" and not be selected by default or shown as detected by default in the control center (but shown as an option in custom on about:preferences).

That's my idea, happy to talk about it if someone thinks we can improve on it.

Comment 1

[Erica Wright [:ewright]]

Attachment: Bug 1529517 - Add prefs for defining expected values in each content blocking category.

Add prefs for definining expected values in each content blocking category, depend on those prefs to set expectations.

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

I'm curious why we're using prefs like this. Is it so that we can make changes via Normandy for experiments?

Comment 3

[Johann Hofmann [:johannh]]

(In reply to Nihanth Subramanya [:nhnt11] from comment #2)

I'm curious why we're using prefs like this. Is it so that we can make changes via Normandy for experiments?

I think I mentioned why in comment 0, but let me elaborate. The idea is that we want to be able to modify the features that are in Standard and Strict without updating the front-end every time. Currently, this is a problem for Shield studies, pref flip uplifts, etc., and it goes in both directions. When we want to uplift enabling a feature then we don't have the appropriate UI for it, and if we want to uplift disabling a feature then we have inaccurate UI that shows the feature is part of e.g. Standard when it really isn't anymore.

Previously we've dealt with this by implementing an atrocious number of conditional UI ahead of time, controlled by separate prefs. It's always a waste of time (because we need to implement at least two UIs and only end up shipping one) and we remain really inflexible.

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

I need to verify that ongoing Shield studies are compatible with this change. Needinfo'ing myself to track.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f15dfc64b11e
Add prefs for defining expected values in each content blocking category. r=johannh,flod

Comment 6

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/f15dfc64b11e