OS updates should not update your settings. They can update system frameworks, but they shouldn't just randomly change the preferences you have set.

It is a bug that can easily happen by mistake, especially if the update changes how preferences are stored in any way.

OP meant why tech savvy people are surprised the Google has the possibility to do such things even though it's obvious they have full control over your operating system.

For actual OS updates on my phone, I have to initiate them on purpose.

The main problem is that this is completely bypassing updates!

That is just an illusion ultimately, which you see crack in instances like these. Google play services have system level privileges. If you don't want such surprises, run AOSP.

There's the difference between the possibility of a software update changing settings and "Google has a whole configuration management infrastructure deployed and active and phones polling for new settings so that one slip of a finger can change the settings on millions of phone by mistake"

This happens in ubuntu linux actually. Every now and then, an update changes my configuration of systemd without asking.

Thus is the nature of updating settings. Easy mistakes to make include:

* Changing a field's default value (is that even a mistake? users might perceive it that way. Also, is there a difference between a field set to the default value and has never been changed vs a field explicitly set to the default value? Should you change it in the latter case? Did you even track the latter case?).

* Overwriting a field's non-default value and setting it back to default.

* Migrating a field and mapping the non-default value to the wrong non-default value.

* Migrating a tuple of fields to another tuple of fields and getting the map wrong for an edge case subset of the input values (bonus points if that subset was thought to be an impossible state to get into).

etc...

The best way to avoid settings updates it to throw it all on the user. eg, Arch Linux just takes the approach: if, you update a file in /etc, the new file is just created with a special file extension and merging the new and current file is left to the user. You don't get nearly as many surprise updates, but... you spend time merging config files, which few people are willing to do.

> The best way to avoid settings updates it to throw it all on the user. eg, Arch Linux ...

actually I prefer Slackware's way to do it: you can keep either the new or the old file, or launch vimdiff and merge them yourself

That's the way Arch Linux does it as well.

That is a combination of different problems. Updates are hard in general, to which there aren't too many mainstream solutions. Emerging ones seem to be in nixos, rpmostree etc. However, ubuntu/debian has a more pedestrian problem, which is that they do a bunch of junk in the post install scripts (like automatically starting and enabling the systemd service for the package). Systemd being a fragile flake will break. That's not the worst that can happen. More likely is that some poor sap will pull in some random server (mail server, database server, http server etc.) as a dependency, and it will get enabled. And ubuntu in their wisdom, don't enable the firewall in desktop variants. So you may be running an open server unknowingly.

I have had some files deleted due to this, to my despair

My whole /tmp/ directory was silently deleted by some "cleanup" systemd shit, hours after an update that changed my configuration.

In fairness, deleting (even moderately) old stuff from /tmp is a Unix convention that goes back roughly three decades prior to the very existence of systemd. In SCO Unix in the early 1990s, for example, it was the task of the /usr/lib/cleantmp program. AIX had a script, invoked by a daily cron job, called /usr/sbin/skulker that did this and more besides.

Putting stuff in /tmp and expecting it to stick around has been a user and indeed a system administration mistake for all of that time, motivating, for example, warnings like this in Kent's & Williams' 1990 Encyclopedia of Computer Science and Technology (volume 22, "The UNIX operating system"):

> /tmp and /usr/tmp: These directories are used by utility programs to contain temporary files. They are cleaned out periodically, so files should not be stored here.

Que Corporation's Using UNIX and Using Linux both said:

> Because the system automatically deletes the contents of this directory periodically, do not keep anything you might need later in this directory.

15 years before the existence of systemd, Linux Filesystem Structure (later to become the Filesystem Hierarchy Standard) was similarly warning:

> /tmp may be cleaned out at boot time or at relatively frequent intervals. Therefore, data stored in /tmp should not be expected to remain for any long period.

A mere 13 years before the existence of systemd, that warning was made starker:

> Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

To all software companies I'd like to say: make updates revertible!