Preload Intermediates on Android
Categories
(Core :: Security: PSM, enhancement, P1)
Tracking
()
People
(Reporter: jcj, Assigned: keeler)
References
(Blocks 4 open bugs)
Details
(Keywords: webcompat:platform-bug, Whiteboard: [crlite] [psm-assigned])
Attachments
(1 file)
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
Reporter | ||
Comment 1•6 years ago
|
||
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.
Comment 2•6 years ago
|
||
(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.)
Reporter | ||
Comment 3•6 years ago
|
||
Would a pref such as security.remote_settings.intermediates.download_via_mobile_network
that defaulted false
work for your use case, Henri?
Comment 4•6 years ago
|
||
(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 defaultedfalse
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.
Reporter | ||
Comment 5•6 years ago
|
||
Mathieu -
Given comment 3 and comment 4, what would you prefer the key name of such a preference to be?
Comment 6•6 years ago
|
||
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.
Reporter | ||
Updated•5 years ago
|
Updated•4 years ago
|
Comment 9•4 years ago
|
||
This is currently breaking https://www.apple.com/ca/shop
which is quite a major website.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
•
|
||
Let's try to contact them (Apple).
Comment 11•4 years ago
|
||
(Apple has fixed its cdn for images and it is now working.)
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Comment 14•2 years ago
|
||
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.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 18•2 years ago
|
||
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.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Comment 20•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 21•2 years ago
|
||
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/
Updated•2 years ago
|
Updated•2 months ago
|
Description
•