Opened 7 months ago

Last modified 2 weeks ago

#30939 new project

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

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-performance, ux-team
Cc: arma, sysrqb, antonela Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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?

Child Tickets

Change History (11)

comment:1 Changed 7 months ago by 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.

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.

comment:3 in reply to:  1 Changed 7 months ago by gk

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

comment:4 Changed 7 months ago by cypherpunks

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

comment:5 Changed 4 months ago by gk

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

Version 0, edited 4 months ago by gk (next)

comment:6 Changed 3 months ago by acat

Note: we might want to reenable the UrlClassifierSkipListService that we disabled in #31740.

comment:7 Changed 8 weeks ago by gk

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

Last edited 8 weeks ago by gk (previous) (diff)

comment:8 Changed 8 weeks ago by gk

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.

comment:9 Changed 8 weeks ago by cypherpunks

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

comment:10 Changed 6 weeks ago by gk

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

comment:11 Changed 2 weeks ago by gk

Some further bits from the Mozilla tickets I looked through during work on #31597:

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.

Note: See TracTickets for help on using tickets.