Auto-update is a mixed bag. We got into auto-update as a standard practice over the last decade because a large fraction of users never updated anything, so security issues would linger forever (not to mention ancient software versions holding back platform technologies, and financial concerns for software shops).

So it's not that auto-update is flatly a bad idea, it's more that it's a trade-off that sometimes makes security issues almost evaporate, and sometimes makes them impossible to dodge.

I think the difference with browser extensions is the anonymity and speed of changing owners. There's more momentum to notice big companies going downhill (+- stuff like sourceforge)

...which happens all the time in the free software world, when you type `apt-get|yum|brew update`.

What are the odds of one dependency being taken over by a shady anonymous entity?

Packages in the default repos for some large Linux distro are usually reviewed and tested by many people until they make it into updates for current stable version, so while it's probably not entirely impossible for some malicious code to get in, it seems pretty unlikely. Unlike browser extensions, where the current owner can upload anything they want and it's pushed to the users without them even knowing.

How about `npm`, `pip`, `cpan`?...

We have seen bad updates breaking the entire Javascript ecosystem, but they were not intentional.

All it takes to inject a bad dependency is a burned out developer willing to delegate his free project to someone else...

The fact that you have to manually type in `apt-get update` (or similar) means it's not automatic. You have full control over when the update takes place, and which packages get updated.

When discussing software updates, I feel like folks on HN commonly overestimate how much impact opportunity for controlling updates has. I haven't seen someone in my social/professional circles ever hesitate before applying an apt-get update. Nobody I've known checks changelogs (except developers checking on direct dependencies), nobody reads the patches for the updates to verify nothing malicious slipped in. "There's an update, I'd better apply it, unless it smells like a breaking change."

So in practical terms, my experience is that vanishingly few people will behave differently than an auto-update system would behave, except in rare occasions like a malicious update making the headlines. We definitely need a solution for rejecting malicious updates, but I feel backing away from auto updates throws the baby out with the bathwater and would be a net-negative change for the industry and for users.

There are exceptions but I think that’s true in the same way people tell their doctor they eat well, exercise daily, and go to sleep on time every night — aspirational, almost certainly discounting the times it doesn’t happen as exceptions and ignoring the actual frequency. The most I’ve seen people consistently do is delay a little in case an update is pulled, and statistically nobody does the kind of analysis that you’d need to catch an unadvertised change.

There's also the occasional _necessity_ for making a breaking change, in particular _breaking some exploit_ and thereby making the software more secure.

I don't envy Chrome leadership's decision or having that problem to solve.

I don't think the question is about control but rather whether automatic updates, when intentionally activated by the user, contribute more positively to the system's security than negatively.

Without automatic updates, you might be more inclined to put off a patch which turns out to be urgent. Or you might be more likely to lose track of which patches have been applied across your various systems.

It's more the chance of an unexpected breaking change. When you use a package manager, you're expecting stuff to change (and get to review what's changing).

Upgrading manually regularly: Good idea.

Having a cronjob to do it automatically without user intervention: Bad idea.