The intermediate preloading tests fail on Android, likely due to tighter constraints.

See log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=222040989&repo=autoland&lineNumber=2017

On Android we're going to want to be careful when fetching our intermediates, too. We should prefer to do so while in a strong network and connected to power before turning this feature on.

(In reply to J.C. Jones [:jcj] (he/him) from comment #1)

We should prefer to do so while in a strong network

The dev-platform post suggested that "strong network" means wifi. Could you, please, (since the Android system seems to lack one) add a pref that allows the user to affirm that their mobile connection is a proper Internet connection? The assumption of "wifi good, mobile bad" is problematic in countries where mobile is not only fast and unmetered but is the only practical option for some residential areas. In such places, devices might never naturally connect to wifi except as a specific manual chore to work around U.S.-centric limits on software updates. (It's bad to have to take devices out of the house to some other place that has wifi to work around limitations that updates work on wifi only or to have to set up mobile devices as wifi hotspots for other mobile devices and be sure to mix operating systems enough that the other device believes it's on stationary wifi and not on tethering wifi in order to download updates.)

Would a pref such as security.remote_settings.intermediates.download_via_mobile_network that defaulted false work for your use case, Henri?

(In reply to J.C. Jones [:jcj] (he/him) from comment #3)

Would a pref such as security.remote_settings.intermediates.download_via_mobile_network that defaulted false work for your use case, Henri?

With UI exposure in the prefs, yes, but it should probably be more generic so that potential other future background download logic could use the same pref to decide whether to wait for wifi and plugged in or just go ahead if plugged in.

Mathieu -

Given comment 3 and comment 4, what would you prefer the key name of such a preference to be?

If it applies to Remote Settings, I would suggest it to have services.settings. as a prefix like the existing ones: https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/modules/libpref/init/all.js#2749-2754
And since intermediates are records attachments, services.settings.attachments.download_via_mobile_network could work!

If it's even more generic than that within the browser (assets, updates, ...), then I'd rather let you choose ;) It seems some of them start with browser.download.

This is currently breaking https://www.apple.com/ca/shop
which is quite a major website.

Let's try to contact them (Apple).

(Apple has fixed its cdn for images and it is now working.)

The severity field for this bug is set to normal. However, this bug has a P1 WebCompat priority.
:keeler, could you consider increasing the severity of this web compatibility bug?

For more information, please visit auto_nag documentation.

The current collection of preloaded intermediates is under 3MB. This should not
be a prohibitive amount for mobile users to download. Once downloaded, updates
to the collection are minimal and again should not be an issue.

https://hg.mozilla.org/mozilla-central/rev/b137f4bb4524

Release Note Request (optional, but appreciated)
[Why is this notable]: Reducing TLS errors that our users encounter
[Affects Firefox for Android]: Only
[Suggested wording]: Reduced the number of secure website errors that users encounter by preloading intermediate certificates
[Links (documentation, blog post, etc)]: Desktop blog post by Dana https://blog.mozilla.org/security/2020/11/13/preloading-intermediate-ca-certificates-into-firefox/