1794130 - Tracking protection list not downloaded on start up

Status: NEW

(GeckoView :: General, defect, P3)

Description

[Arturo Mejia [:amejia]]

We need to investigate why the tracking protection list is not download just after startup, as we are seeing long delays until the list is available.

Related tickets

Fenix
https://github.com/mozilla-mobile/fenix/issues/7907
Focus
https://github.com/mozilla-mobile/focus-android/issues/7821

Comment 1

[Chris Peterson [:cpeterson]]

Are Fenix and Focus UI tests allowed to use the network? Intermittent network errors or perf differences might prevent the ETP lists from being downloaded soon enough.

Firefox desktop tests aren't allowed to use the network. (If they do, they will crash.) This approach is to make the tests more reliable and deterministic. Tests must use a mock server running on localhost, though that might not be feasible on Android.

Comment 2

[Roger Yang [:royang]]

Using testing and console debugging, I've narrowed down the issue:

1. Fails to download tracking protection block list on first start.
2. Retry timer set to 20 minutes from first start.
3a. If the user doesn't restart Fenix, when retry timer expires, list will be downloaded. (100% success rate)
3b. If the user restart Fenix (swipe away first), then the list will be downloaded right away. (100% success rate)

In my opinion this issue is seen because of three reasons:

1. Inconsistent success rate when downloading block list at first start.
2. We don't have a default list built in.
3. Long backoff retry timer when we fails to download at first start.

Comment 3

[Chris Peterson [:cpeterson]]

I filed bug 1795481 about bundling a preloaded ETP list, but I don't know when it might be prioritized.

A new user temporarily browsing with an empty ETP list is not a fatal problem (especially after we ship TCP). So conclusively fixing this problem by preloading an initial ETP list is probably not a high priority. But tweaking our retry timer in the meantime is probably worthwhile.

Comment 4

[Dimi Lee [:dimi]]

(In reply to Chris Peterson [:cpeterson] from comment #3)

A new user temporarily browsing with an empty ETP list is not a fatal problem (especially after we ship TCP). So conclusively fixing this problem by preloading an initial ETP list is probably not a high priority. But tweaking our retry timer in the meantime is probably worthwhile.

Unfortunately, currently, the backoff timer is not configurable. This is because Safe Browsing spec defines the backoff algorithm, and we want to make sure we follow that.

Although it is still possible to make the backoff timer configurable only when list provider is "mozilla", I would prefer doing this only if we can't wait for fixing this issue with the "preloaded list" approach.

Comment 5

[Chris Peterson [:cpeterson]]

Tim Huang says Gecko doesn't support initializing the Shavar-based ETP list with local data, but Remote Settings does support initial data. Fixing this bug would require moving the ETP list from Shavar to Remote Settings.

https://firefox-source-docs.mozilla.org/services/settings/index.html#initial-data

This bug is not a high priority for now because the user exposure is small and we don't have an ETA for moving ETP to Remote Settings.