1795481 - Bundle preloaded ETP list with Firefox install

Status: RESOLVED WONTFIX

(Core :: Privacy: Anti-Tracking, task)

Description

[Chris Peterson [:cpeterson]]

This would address issues like Fenix bug 1794130 where, due to intermittent network problems, a new user can start browsing before the initial ETP list has been populated during first run.

Fixing this will probably require moving the ETP list from Shavar to RemoteSettings. Maybe this bug can be generalized to preload a snapshot of all RemoteSettings in a new Firefox install instead of downloading everything during first run.

Comment 1

[Dan Mehic]

Closing this as WONTFIX. Not because the underlying problem is solved — it is not, and bug 1794130 is still open for it — but because this bug is a proposed approach whose stated premise no longer describes the tree, and the approach was not the one the platform took.

The premise in comment 0 is now obsolete

Comment 0 reasoned that "fixing this will probably require moving the ETP list from Shavar to RemoteSettings". That migration has since shipped. modules/libpref/init/all.js#3447 now defaults to Remote Settings for every build and channel:

pref("browser.safebrowsing.provider.mozilla.updateURL", "moz-sbrs:://antitracking");

nsUrlClassifierStreamUpdater::FetchUpdate routes the moz-sbrs scheme to UrlClassifierRemoteSettingsService, which reads the tracking-protection-lists collection. So the prerequisite this bug was blocked on is met, but the conclusion that bundling would follow from it did not happen.

The generalized ask was answered a different way

Comment 0 also suggested generalizing to "preload a snapshot of all RemoteSettings in a new Firefox install instead of downloading everything during first run". Remote Settings has since addressed that cost, but network-side rather than install-side: Utils.fetchChangesetsBundle (Utils.sys.mjs#640) pulls a single bundles/startup.json.mozlz4 covering many collections in one request, instead of one request per collection.

That is worth being precise about, because it is easy to mistake for this bug being fixed: the startup bundle is a network fetch, not a preload, and tracking-protection-lists is one of the collections it carries. It reduces first-run round-trips; it does nothing for a client with no network.

Nothing is bundled today

For the record, so a future reader does not have to re-derive it:

• There is no tracking-protection-lists.json under services/settings/dumps/, in any bucket, and dumps/main/moz.build does not package one.
• The Remote Settings tests assert this directly — test_remote_settings_startup_bundle.js#67: Assert.ok(!(await Utils.hasLocalDump(...)), "Client has no packaged dump").

If anyone does revisit bundling

Two things that were not true in 2022 and would shape the work:

1. The ETP list payload lives in Remote Settings attachments, not in the records — see rs.attachments.downloadAsBytes(entry) at UrlClassifierRemoteSettingsService.sys.mjs#99. A records dump alone would be useless. Packaged attachments are now a solved problem though: search-config-icons ships roughly 50 of them via FINAL_TARGET_FILES.defaults.settings.main["search-config-icons"] in dumps/main/moz.build. That is the template to copy.
2. dumps/main/moz.build currently excludes mobile outright ("Android/iOS don't use/want the dumps"). Since the motivating report was on Fenix, that exclusion would have to be revisited first.

Why WONTFIX rather than leaving it open

The cost is disproportionate to what it buys: multi-MB digest256 lists plus attachments in every installer on every platform, to cover a window of seconds to minutes on first run and only when the network is degraded — and the bundled copy is stale the day it ships and is discarded at the first successful sync. Meanwhile network.cookie.cookieBehavior defaults to 5 (dFPI), which partitions third-party cookies independently of the list, so the "user browses completely unprotected" framing from 2022 overstates today's exposure. It does not eliminate it: privacy.trackingprotection.fingerprinting.enabled and .cryptomining.enabled are both true by default and do depend on the list.

This bug has also been untouched since October 2022, with no assignee and no severity set.

The actual defect — the list not being available at startup — remains open as bug 1794130, and I am copying the technical findings above over there so nothing is lost by closing this one. If someone decides bundling is the right fix after all, please reopen or file fresh against the current premise rather than the 2022 one.