[danenania]

Agreed on everything here, but I’d draw a distinction on automatic updates being the problem vs. selective or ephemeral updates.

Even if updates are opt-in, 99.9% of users are just going to click through and update. They’re not going to look at the diffs first.

The real problem is when an update can be targeted at a specific user and not leave a trace elsewhere. This removes the deterrent of potential public discovery, shaming, and loss of trust, which in practice is the best defense we have.

If you use a desktop client with signed updates that come from a ‘logicless’ third party CDN like S3 or Github, you can at least be sure that any update you download will also be downloaded by many other users, which greatly increases the risk of discovery for an insider who wants to snoop on your messages.

[Ajedi32]

Targeted attacks can be made impossible to conceal using binary transparency[1] (similar to how certificate transparency makes malicious certificates impossible to conceal on the web).

Unless the product is open source though with reproducible builds even that level of transparency would only get you so far. It's pretty easy to conceal a backdoor in a black box binary, especially if nobody's looking for it.

The gold standard right now is to allow third party clients. When the service provider doesn't control the client, E2E encryption can be very a powerful defense indeed.

[1]: https://developers.google.com/android/binary_transparency

[danenania]

Third party clients seem like a double-edged sword.

Allowing users to build the client from source is good--no doubt about that. But encouraging use of third party clients undermines the trust model of verified developer certificates on Mac and Windows.

Ultimately, you need to trust whoever built and packaged the client. You need to know exactly who that is, and that their reputation depends on the security of the software you're about to run.

[a1369209993]

> Even if updates are opt-in, 99.9% of users are just going to click through and update.

That's still automatic updates. A non-automatic update occurs when the user takes some unprompted action such as clicking Help > Check for updates, which by design mostly only happens when the application's current behaviour is unsatisfactory.

> from a 'logicless' third party CDN like S3 or Github

Those aren't logicless, you just haven't caught them using nontrivial logic. (Or you have and conveniently forgot about it - I recall hearing that Github returned different results to queries from Iranian IP addresses at some point - those were error messages, but could as easily have been state-supplied backdoored versions of the requested software.)

[danenania]

"That's still automatic updates."

I see what you're getting at, but the vast majority of users don't define "automatic updates" in that way. Automatic updates (to almost everyone) means an update that requires no user interaction or approval. If you have to click a button, it's not automatic. The user could, if they wanted to, download the latest version and examine it, check the diffs on Github if the project is open source, etc. before updating.

What you're referring to I guess could be called an 'unprompted update'. But in practice, it's important for users to be aware of updates that include bug fixes, even if they haven't hit those bugs yet, so I don't think this is really desirable behavior.

"Those aren't logicless"

They're not logicless for the service providers (AWS and Github) but are logicless from the perspective of the software provider. Up to the point that you trust AWS or Github, you can trust that a link to a static Github/S3 file will serve the same file to every user, and the software provider can't change that.