Should desktop applications silently update?

Question

Lots of programs silently update, notably Chrome, which must always silently update, but most operating systems can be set to silently update, and many other programs can as well, though it is not often the default and even less often is it mandatory.

But, I have created programs that silently update myself, and had complaints about security issues. So, do you think that programs should

• Be forced to silently update?

• Optionally silently update, with silent updating being the default?

• Optionally silently update, with silent updating not being the default?

And what are the potential security issues with a silently updating program?

Answer 1

Personally, I think programs being forced to silently update is out of the question. In a high-security environment where software is audited, your "update" is an attempt to introduce unknown code to the environment without permission, hence is automatically treated as malicious. It only takes a small number of users who consider your software malicious to constitute a problem.

Even in a less uptight environment, I think it's antisocial to deny your users the ability to delay updates for their own reasons. I could speculate what those reasons are: for example they might rely on some behavior of the old version, but the basic point is that the reasons are your users' reasons, not yours. You don't get to know what they are, so if you respect your users in the slightest degree, you can't force them to change the software on their machine just because you think the new version is better.

That said, update by default is probably a good idea at the moment. Windows in particular has decided, over the last 15 years or so since it has been really feasible, not to introduce any kind of integrated update management for applications. The result is a terrible mess of intrusive software update strategies, and the least intrusive strategy available seems to me to be:

1. check for updates when the software starts up (and periodically while it is running), not all the time in some unkillable background process.
2. install updates silently unless the user has said they're interested in updates, in which case tell them about the update and (if they've said they want to be asked) ask them whether to install it or not.
3. Provide the user with an easy means to check the update history.

A checked-by-default checkbox at install time, "look for and install all updates in future", would seem to me to be adequate permission, but consult your own lawyer.

In security terms, if your update procedure is really secure then your silent update procedure will be too. So if we're willing to assume perfection there's no difference.

However, if the user doesn't trust your update procedure, then they might not want to take updates when they're on e.g. an insecure wireless network, because they might be concerned e.g. that somebody has obtained a fake SSL certificate for your domain. Obviously MITM attacks can be performed on networks other than insecure wireless networks, but they certainly are far more common in that case, so the risk is higher. Silent updating prevents the user from managing that risk in a way they're comfortable with, instead it's managed in a way that you (the software author) is comfortable with. You have to think about whose comfort is more important, and again that's about what kind of respect you have for your users.

The first person whose silent software update gets subverted at a Black Hat conference, thereby pwning every machine in the room foolish enough to have their software installed, will get precisely the coverage they deserve in the tech press.