What are possible issues with Chrome-like self-updating application for administrators

Question

Administrators of organization computers are often very careful about what they allow to be installed on computers. They often disable automatic updates, and instead vet the updates manually and push them to computers if they are sure it didn't break any user workflows.

But then, comes in Chrome, which has tendency to update itself automatically and frequently. I don't know if Chrome provides a "gated" update, that allows organization administrators to test the updates before letting it inside the organization. But I can imagine it does.

My question is this. How are applications, which update themselves automatically, frequently and often without user even knowing, seen by administrators of organization computers? If I were to create such an application, would those administrators require ability to turn off the auto updates? Or would they be fine with being able to check the updates before hand?

I realize this question might be too broad and depend heavily on specific organization. I'm more interested in "best practices" and "general rules" answer.

Background

The reason why I'm asking is that idea of Continuous Deployment has been growing strong in software development. This is much easier with server components, when you control the server the software is deployed on. But it becomes difficult with software installed directly on client stations. I believe Chrome is doing Continuous Deployment, which is why it is relying heavily automated updates of new releases. Those can, in extreme cases, be daily incremental builds. What I want to know what kind of friction I should expect from administrators if I were to sell application, that tries to update itself weekly or even daily? And possibly what should this kind of automated update system provide to administrators to make it easier for them. As I wouldn't want admins go against the application if it breaks their update workflows.

Answer 1

In the case of Google Chrome, this was solved in three ways:

1. Windows versions have an MSI installer option for enterprises, specifically to address this issue. Updates are available via a feed for administrators so they can vet and rollout updates as they need.

2. Default Chrome installations are user-bound and cannot (and do not) affect other users or system-level items, so even if auto-update is on, at worst, it means wiping a user's profile which in a controlled environment often boils down to deleting non-critical things like the user's registry and some AppData. Most enterprises store documents etc. outside of the user's profile and important application data is replicated and synchronised with servers (i.e. CalDAV, IMAP, Exchange, for PIM, and Git for source code etc.) so the impact is rather small.

3. For other operating systems, (macOS, Linux) installation has both options as well (local user installation vs. system installation) but for system installation management, both Linux and macOS based systems have a good set to tools to make this work as they have package-based installers requiring either a single .pkg/.deb/.rpm to be installed/updated/removed or a single directory copied over (i.e. the .app format). Again, settings and profiles are stored inside the user's home in a directory separate from the user's actual files so even there a worst case scenario is identical to any other type of profile problem: wipe the profile and the user can get back to work.

I'm sure there are applications that do not offer managed installations, and only work with automated updates, but I have not seen the combination of system-level and auto-updaters in any enterprise setting where it was the only choice. If you have an application you'd like to sell, at least offer a packaged/container version that can be added or removed as a single item with user-level access. This means that it can be managed both by the user and by administrators.

Best would be to have multiple packaged builds so you can service everyone. Setting up your internal CI/CD to do this is often something you need to get right once and then only maintain it for changes. When the software is built/compiled etc. the last packaging step can include automated installer builds, packaged builds, MSI builds, PKG builds etc. and you'll be able to service everything with minimal cost to yourself.

Answer 2

The answer will depend on what methods the platform you are using provides for updating software. My answer will be aimed at the platforms I know best which are Ubuntu and Fedora. Those are using deb and rpm packages respectively for installing software and updates, the differences between deb and rpm are minor in the context of this question.

The installed files will for the most part be owned by root and the installer will need to run as root in order to have privileges to update the files. The application itself will run as an unprivileged user without any way to update the files. If the application tries to update itself it will fail to do so.

The application can inform the user an update is available. But if it wants to actually install the update the best it can do is to start the update manager which would open a window prompting the user for the necessary password.

At this point the auto update will have been reduced to a shortcut for opening the update manager. And the question will thus be if you want each user in your organization to have administrative privileges on their own machine.

Strategies for rolling out an update

In a large organisation you will likely want to only roll out the change to a small number of users at first and gradually increase the speed as long as you don't hear problem reports from the users.

You will need to weigh this against how critical the update is. If it is fixing a vulnerability that is being actively exploited or if the bug could cause loss of data or render devices unable to boot you may want the update to roll out faster.

One has to take into account the risk that it may take time from an update is released until your system administrator realize there is a critical update warranting an expedited rollout.

A large organisation is more likely to have enough system administrators to be able to evaluate each software update on a short notice and decide how quickly to roll it out to all machines. A small organisation won't have those resources and may have to trust the software vendor enough to start rolling out the software updates without a manual vetting step.