Closed Bug 1529517 Opened 8 months ago Closed 7 months ago

Add new prefs for defining features in content blocking categories

Categories

(Firefox :: Protections UI, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 --- fixed

People

(Reporter: johannh, Assigned: ewright, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [anti-tracking])

Attachments

(1 file)

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.

Assignee: nobody → ewright
Status: NEW → ASSIGNED

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

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

Flags: needinfo?(jhofmann)

(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.

Flags: needinfo?(jhofmann)
Attachment #9046745 - Attachment description: Bug 1529517 - Add prefs for definining expected values in each content blocking category. → Bug 1529517 - Add prefs for defining expected values in each content blocking category.

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

Flags: needinfo?(nhnt11)
Pushed by ewright@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f15dfc64b11e
Add prefs for defining expected values in each content blocking category. r=johannh,flod
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Blocks: 1551675
You need to log in before you can comment on or make changes to this bug.