Use Firefox's Tracking Protection as a means for performance improvements

When improving browser performance one of the low-hanging fruits we could think about is using at least some of the Enhanced Tracking Protection (ETP) feature for that purpose. This ticket is the parent ticket to track all the involved work.

There are a number of questions involved that we need to discuss and decide how to proceed (and probably more than I came up with below):

a) Do we want to use the same message and UI of ETP as it is shipped right now in Firefox?

b) Do we want to enable the same lists as Mozilla is doing in the respective browsing modes?

c) Do we want to use the same list retrieval mechanism as Mozilla (using the safebrowsing protocol)?

d) Do we want to host the tracking protection lists ourselves?

e) Does the work in this ticket (and child tickets) is our answer to "ship an ad blocker" in Tor Browser? Or do we feel the need to still ship another blocking tool on top of ETP?

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-performance in Legacy / Trac type::project in Legacy / Trac ux-team in Legacy / Trac labels

To start the discussion here is how I currently think we could answer the above questions:

a) No, we don't want to do that but rather we should make sure that ETP is only used and perceived as a performance improvement. That might mean getting ETP out of the privacy part of the preferences and changing the respective text if it is talking about privacy. I think we could keep all non-UI things, though, like the preferences governing this.

b) I think we could start small e.g. by blocking all the cryptominers and see how that goes and add all the other bits successively if we are confident enough.

c) Not sure. I think we need to audit the mechanism Mozilla needs for this. It is slightly different than the regular safebrowsing retrieval.

d) Maybe, although I think it would be fine to use what Mozilla has to be able to start experimenting (That's dependent on the answer to c), though).

e) I think we should not ship an ad blocker on top of that and use that mechanism as our blocking tool.

UX/UI specs -> https://mozilla.invisionapp.com/share/38S2U6FPFKD#/screens/359913354

Replying to gk:

To start the discussion here is how I currently think we could answer the above questions:

a) No, we don't want to do that but rather we should make sure that ETP is only used and perceived as a performance improvement. That might mean getting ETP out of the privacy part of the preferences and changing the respective text if it is talking about privacy. I think we could keep all non-UI things, though, like the preferences governing this.

Oh, and as a reminder, all the UI showing different state on the URL bar and behind the "i" icon should go as well: there is just one state for fingerprinting reasons which is "enabled".

gk finally supporting some small amount of junk blocking, I can't believe it this must be some kind of dream or something...

By the way I think your b) is totally unnecessary just start with what Mozilla accepts as its default, they're already very concerned with the defaults not breaking the web (see all the WebCompat reports that they fix with that regards).

Note: we should make sure the fixes for https://bugzilla.mozilla.org/show_bug.cgi?id=1560623 (aka bug 1572240) have either landed on the branch we use or they got backported by us once we get to this bug.

Note: we might want to reenable the UrlClassifierSkipListService that we disabled in legacy/trac#31740 (moved).

Note: https://bugzilla.mozilla.org/show_bug.cgi?id=1482129 might be of interest (not sure whether the implementation still matches when we get to this bug).

https://bugzilla.mozilla.org/show_bug.cgi?id=1475424#c0 contains some interesting study Mozilla made to track performance improvements, see: https://docs.google.com/document/d/1LQdOFIZeoiD38NNMxvpm32bX6Urnv0KbEsGfgAuw5L8/edit as well.

I want DNT settings back just like in version 7-8.

There are two metabugs at least for collecting breakage introduced due to tracking protection. When implementing this for Tor Browser it might be smart to check how worse the situation gets for us and whether that's worth the benefits (or, assuming we have different options here, in which scenario the breakage is worth it).

Some further bits from the Mozilla tickets I looked through during work on legacy/trac#31597 (moved):

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1535697 makes sure that separate connections are used for isolated third-party trackers. We want to make sure this works with our First-Party Isolation as expected.

2. There is the option to delay tracking loads. This is interesting in the sense that we could play with (perceived) performance improvements while not needing to block anything.

legacy/trac#33046 (moved) for reference and historical record (or however that works).

We learned we don't want the "Enhanced" part of "Tracking Protection". Maybe legacy/trac#17569 (moved) or https://github.com/brave/adblock-rust are better alternatives, too.

Trac:
Summary: Use Firefox's Enhanced Tracking Protection as a means for performance improvements to Use Firefox's Tracking Protection as a means for performance improvements

mentioned in issue legacy/trac#31740 (moved)

mentioned in issue legacy/trac#33046 (moved)

moved from legacy/trac#30939 (moved)

added Project UX labels and removed 1 deleted label

added Performance label and removed 1 deleted label

added Icebox label

mentioned in issue #40783 (closed)

marked this issue as related to #40220 (closed)

added Meta label

added All Platforms label

mentioned in issue #41596 (closed)

marked this issue as related to #41092 (closed)

mentioned in issue #40789

added Apps::Impact::Unknown label