Question about ethical auto-updates

Question

I'm working on a project which needs to always be up-to-date for my users. It's quite simple to make an auto-update feature, but I need to know how ethical this is.

If, when the user installs the software, it tells them it'll automatically install updates silently in the background (when the user opens it intentionally, of course - I'm not trying to be Microsoft here...) without prompting them. Is this bad practice, even if I warn them ahead of time?

If it's a better idea to prompt the user to update every time, would it be inadvisable to 'lock out' the app until it's updated? If this is the case, how can I ensure they won't break something by using an outdated version?

Answer 1

I see only one ethical aspect here: when you (or your company) abuse the silent auto-update feature to change a "harmless" application into a malicious one, which first establishes a large crowd of happy users, and then causes some harm. For example, it could start spying on them (I did not invent this, this has happened in the past). However, this could also happen when your users have to install updates manually and you just "forget" to mention the new "spying feature", so the unethical aspect here is not the "silent auto-update feature", but the content of the specific update (or th fact it was not mentioned in the change log).

Hence I think the question for a silent auto-updater is not primarily a question of ethics. It is a question of necessary constraints to make sense and to make it work well. This involves aspects like

• security
• user perceiption
• backwards compatibility
• responsibility for trouble shooting (and I mean this in both directions, for bugs which are fixed by an auto-update, or issues which are introduced by one)
• communicating changes in the app
• and sometimes even legal aspects

which have to be balanced. Hence it depends a lot on the specific kind of application, the specific kind of updates, the kind of data managed by the application and also the organizational environment where the application runs.

Note that almost any web app does silently autoupdates. Companies like Facebook, Google, Microsoft or Amazon do regulary updates in the background or their major web apps, and you don't even notice (but this is also true for every smaller vendor's web app - users don't get a choice which version runs on the vendors server, and vendors rarely do different updates for different users). Also, most mobile apps do updates in the background (not completely silent, but almost unintrusive).

IMHO silent auto-updates make most sense when they restrict themselves to unintrusive changes like bug fixes. This makes sure that users are not stumbling about astonishing changes to the user interfaces. It also minimizes the risk of getting new bugs automatically, since new bugs are way more likely to occur in new features than in old ones. Updates which make changes to the UI which are not fully self-explanatory should be clearly advertised, telling the user what they get before they install the new version.

Be aware that any update does not only fix bugs, it can also introduce new ones (up to the point where the auto-updating does not work any more). Hence It also a good idea to provide a the option of manually installing an earlier version as a fallback in case that helps. That, however, works best when your application behaves backwards compatible. The update to a newer version shall not forbid to go back again to an earlier one because some data schema was changed in a way the older app cannot process the persistent data any more.

Answer 2

If your application needs to be up-to-date, then I don't see why an auto-update feature would necessarily be problematic. I use several applications with different types of automatic update functionality. Some client applications force the update to be applied in order to be able to communicate with the server side. Other applications take different types of prompting or notification, with some making old versions obsolete and unusable while not necessarily requiring the latest version.

From an ethical perspective, I would look at how you are minimizing harm. For example, forcing users to update to an alpha or beta version could be introducing the risk of defects which could lead to problems like loss or disclosure of data. You should take great care in making sure that software updates don't disrupt a user's workflow. The features delivered could also play into the decision. For example, if you used your auto-update mechanism to deliver malware or functionality that invades privacy (such as hijacking microphones or cameras), then that would be unethical. Make sure to make information available about what has changed with the system. However, these are more about how the auto-update mechanism is used rather than the existence of the mechanism itself.

I would recommend working with the stakeholders - particularly end users - to understand the impacts and risks of different options and how to mitigate any concerns that they have. However, a lot depends on the context of the system, the expectations of end users, and the technical reasons for needing updates.

Answer 3

TL;DR: The one thing that you can't ethically do is update the app "behind the user's back".

There are a few things to consider apart from ethics, which probably help to clarify which kind of solution works best for your case:

First you should know exactly why an update would be required, you just write "needs to be up-to-date" without giving a reason.

Does your app contain data that grows old, such as a holiday calendar, or price lists? Then you should perhaps retrieve that data from a web service instead.

Does your app have serious quality issues which put the user's data at risk? Then you should definitely work on QA instead of letting the users test your software on their valuable data (the first one to find a bug will have been bitten by it).

Do you have a backend service that only works correctly with up-to-date versions of the app? Implement stable backward-compatible APIs instead so that older versions of the frontend still work when you update the backend. If you announce discontinuing a deprecated API long enough in advance, your users will know that they need to update their app before it ceases to work.

If your users can't generally be trusted to take care of updating their apps (so they belong to the "unwashed masses") an automatic mechanism that the user agrees to when installing the app may be Ok. Many apps do this, often either as a voluntary step when individual updates become available, or by being updated as part of automatic system updates as many Linux distributions do.

Answer 4

It depends.

One one hand, as a user, I am happy with modern browsers self updating automatically and fixing security breaches and privacy leaks.

One the other hand, as a developer, I need to fully control my compilation chain and my whole environement.

I am sure that others have other preferences. I think that auto-update feature should be enabled or disabled by a user setting.

Answer 5

A forced auto-update is a can of worms. Already some users pointed out the security risk, but that is not the only problem. You have no idea of what is the situation on the device when the app is started. Might it be a mobile phone with a contract with a periodic limit on the data transfer? A big update might exhaust the data available. Could the user start the app while another app is already doing a heavy download? Your app might be left hanging because the transfer rate is too slow.

Leave it to the user to decide when it is the right moment to update.

If your project is really so delicate that it needs to always be up-to-date. You have to handle it in some way.

would it be inadvisable to 'lock out' the app until it's updated?

No. It would be a quick and dirty solution, but if you don't have enough time for a more complex and resilient solution it is still acceptable. Just don't say "user locked out" because it would appear unfriendly. You could put a consistency check and fail fast before the app can make any damage. Just crash with the message "Technical error. App needs to be updated".