Closed Bug 1520297 Opened 6 years ago Closed 2 years ago

Preload Intermediates on Android

Categories

(Core :: Security: PSM, enhancement, P1)

All
Android
enhancement

Tracking

()

RESOLVED FIXED
107 Branch
Webcompat Priority P1
Tracking Status
relnote-firefox --- 107+
firefox-esr102 --- wontfix
firefox66 --- wontfix
firefox105 --- wontfix
firefox106 --- wontfix
firefox107 --- fixed

People

(Reporter: jcj, Assigned: keeler)

References

(Blocks 4 open bugs)

Details

(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

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.

Blocks: 1404934
No longer blocks: 1520278
Summary: Fix intermediate preloading on Android → Preload Intermediates on Android

(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?

Flags: needinfo?(mathieu)

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.

Flags: needinfo?(mathieu)
Blocks: 1555407
Blocks: 1606696
No longer blocks: 1672402
Blocks: 1677157

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

Webcompat Priority: --- → P1

Let's try to contact them (Apple).

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

No longer blocks: 1606696

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.

Flags: needinfo?(dkeeler)
Severity: normal → S2
Flags: needinfo?(dkeeler)
Depends on: 1772232
Severity: S2 → N/A
Type: defect → enhancement
Priority: P3 → P2

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.

Assignee: nobody → dkeeler
Status: NEW → ASSIGNED
Priority: P2 → P1
Whiteboard: [crlite] [psm-backlog] → [crlite] [psm-assigned]
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b137f4bb4524
enable intermediate preloading on Android r=jschanck
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch

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/

relnote-firefox: --- → ?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: