Provide user feedback if "check for updates" fails

[unman]

The problem you're addressing (if any)

The check for updates may fail due to misconfiguration, network error, or malicious action.
As @andrewdavidwong said - in #6585

The truth is that the user shouldn't have to carefully scrutinize a block of technical output in order to be alerted when updates are failing. There should be big alarm bells going off. As designers of a secure system, we should want it to be fail-evident, since this in itself is a measure of defense against compromise.

Describe the solution you'd like

Provide visual/auditory feedback, and a popup - pop up would be less desirable because it is too easily clicked through.
If a popup notification is used then the user should have the option to ignore warnings for the next X checks.
Suitable visual feedback might be turning the GUI update icon red with a hover over explanation, suggesting a configuration check, or perhaps overlay the update icon with a standard error icon.
@ninavizz @marmarta - thoughts?

Where is the value to a user, and who might that user be?

Any user who uses the "check for update" feature.
If there is a misconfiguration, or the update check fails for some other reason, the user has no way of knowing, so may mistakenly believe there are no updates available.

Describe alternatives you've considered

I don't use this feature, so am at a loss.

Additional context

See discussion in #6585

Relevant documentation you've consulted

https://www.qubes-os.org/doc/updating-qubes-os/ references the icon without indicating when it shows that updates are available.

Related, non-duplicate issues

#6585 - Incorrect status report if Salt update fails

[ninavizz]

I'd be happy to compose text and/or icons, etc. TBH, the current Updater could use a refresh, anyway. Not sure how much @marmarta might be keen to work on a UI update. A great ticket summarized some issues in #6299 and with SecureDrop, we'd love to be able to configure the Updater to prioritize our unique (hand gestures for technical things I do not understand).

Anywho, via the above:

The check for updates may fail due to misconfiguration, network error, or malicious action.

If someone who is technically adept might be keen to help me out for starters, by creating a manifest of all failure reasons identified in the technical logs, today? Then, remediation options. From there, I can compose user-facing messaging and how to present in the Updater UI or Toast messages.

Example, from above:

1. Problem: Misconfiguration. Remediation: Peel a banana. See docs link, here: banana.com/peeling
2. Problem: Network error. Remediation: Check your network or Whonix connection

• Might the updater know the connectivity method utilised (Tor, Wifi, Firewall, Ethernet) to more directly message the user to at least know which service-vm or hardware to poke?

3. Problem: Malicious Action. Remediation: Peel an apple. See docs link, here: apple.com/peeling

• Need clarification on "Malicious Action," as that could be a lot of things—and those words will set off alarm-bells for many users. Also curious what kind of guidance is prudent to offer here, so that users can be gently guided down the ladder of any anxiety this could trigger.

[andrewdavidwong]

I'd be happy to compose text and/or icons, etc. TBH, the current Updater could use a refresh, anyway. Not sure how much @marmarta might be keen to work on a UI update. A great ticket summarized some issues in #6299 and with SecureDrop, we'd love to be able to configure the Updater to prioritize our unique (hand gestures for technical things I do not understand).

Anywho, via the above:

The check for updates may fail due to misconfiguration, network error, or malicious action.

If someone who is technically adept might be keen to help me out for starters, by creating a manifest of all failure reasons identified in the technical logs, today? Then, remediation options. From there, I can compose user-facing messaging and how to present in the Updater UI or Toast messages.

Example, from above:

1. Problem: Misconfiguration. Remediation: Peel a banana. See docs link, here: banana.com/peeling

2. Problem: Network error. Remediation: Check your network or Whonix connection

• Might the updater know the connectivity method utilised (Tor, Wifi, Firewall, Ethernet) to more directly message the user to at least know which service-vm or hardware to poke?

3. Problem: Malicious Action. Remediation: Peel an apple. See docs link, here: apple.com/peeling

• Need clarification on "Malicious Action," as that could be a lot of things—and those words will set off alarm-bells for many users. Also curious what kind of guidance is prudent to offer here, so that users can be gently guided down the ladder of any anxiety this could trigger.

IMHO, it would be best just to start with something simple and not try to differentiate between such causes, as that can be very difficult or, in some cases, impossible. (For example, a sophisticated attack disguised as a network error or misconfiguration could be effectively impossible to conclusively identify as an attack, even by a sapient expert, let alone a less intelligent automated system.)

I have a feeling that setting such a high bar would ensure that nothing gets implemented for a very long time, if ever, and that your question gets ignored because everyone is too daunted to reply. Rather, I'd suggest starting by lumping all those cases into one. That's tractable, constitutes a significant improvement over the status quo, and still allows for more sophisticated enhancements in the future.

Given my experience with the typical shape of this problem and the manner in which users typically respond to it and to guidance about it, I provisionally offer this example as a starting point:

---

Update check failed. This may be due to an internet connection problem. Please check your connection and try again.

If your connection is normal but the problem persists, there may be a transient network problem in the third-party infrastructure between you and the update servers, possibly affecting the update servers themselves. Please wait a while and try again later.

If the problem still persists after that, there may be a configuration problem in your system. Please see https://www.qubes-os.org/support.

[marmarek]

I fear false positives will be a real problem here, with Qubes use case. For laptop it is quite normal to not be connected to the network all the time (or connected via some poor connection maybe). And then user will quickly start ignoring this message completely.

Maybe we should emit such message only if few consecutive update checks fails? Or check what sys-net (or whatever netvm is used there) thinks about network connection state first?

[andrewdavidwong]

I fear false positives will be a real problem here, with Qubes use case. For laptop it is quite normal to not be connected to the network all the time (or connected via some poor connection maybe). And then user will quickly start ignoring this message completely.

Maybe we should emit such message only if few consecutive update checks fails?

Yes, this was exactly my suggestion: 'If the automatic update checker has been unable to successfully complete a check after a certain period of time or a certain number of attempts, the user should be notified. (For example, "Warning: Qubes has been unable to reach the updates servers for three days!") How and where I leave to the UX experts...'

It can still make sense to warn the user that their installation has not been updated in a long time, even if the machine has been intentionally offline, since the longer an installation goes without updating, the more likely it is that there are important security updates missing. For example, this can indicate to the user that, when she does go back online, it's important to update before performing any sensitive tasks.

Nonetheless, it would also make sense to include an option to silence the warning for N days, e.g., if the user knows that she will be offline for an extended period of time and doesn't want to be bothered. This seems to be a standard feature of such systems.

Or check what sys-net (or whatever netvm is used there) thinks about network connection state first?

Yes, this could be a good heuristic. If sys-net can reach the internet, yet the update checker cannot reach the update servers, then that indicates a problem among the possibilities described above.

However, as I argued above, even a dead simple implementation to start with would be a major improvement over the status quo. While the addition of more and more sophisticated heuristics will always be possible (and welcome!), I caution against allowing the prospect of potential perfection to be the enemy of the what would be sufficiently good in the present.

[ninavizz]

However, as I argued above, even a dead simple implementation to start with would be a major improvement over the status quo. While the addition of more and more sophisticated heuristics will always be possible (and welcome!), I caution against allowing the prospect of potential perfection to be the enemy of the what would be sufficiently good in the present.

I could not agree, more, with that! My simplistic brain still needs a simple list, tho, as a starting point. :) Your added context on the sys-net bit as a good decision-gate to flag in a message, is very helpful. As well as all the other thoughts.

Lots of small improvements could be made to the existing Updater experience, short of a complete redesign. 100% agreed. Can make a separate issue to track as an epic—feel free to nix, if you feel that would be issue-bloat.