https://freedesktop.org/software/systemd/man/machine-id.html
/etc/machine-id is a nasty part of nasty systemd
https://sysdfree.wordpress.com/
https://without-systemd.org/wiki/index_php/Main_Page.html
The contents on my machine is 9a069ccef8244ec02b964c4f61c1d905.
How has /etc/machine-id got into my OpenBSD?
man hier, man machine-id, apropos machine | grep -i id give nothing.
pkg_info -E /etc/machine-id ("Look for the package(s) that contains the given filename") - gives nothing.
apropos systemd
xscreensaver-systemd(1) - lock the screen when the machine suspends.
Hmm, it's not xscreensaver, it's xscreensaver-systemd. Not very honest towards those expecting xscreensaver when they pkg_add xscreensaver.
Yet pkg_info -L xscreensaver ("Show the files within each package.") - doesn't mention /etc/machine-id.
A post from antiX Linux forum:
https://www.antixforum.com/forums/topic/kids-find-a-security-flaw-in-linux-mint-by-mashing-keys/#post-50665
May I humbly add Sytemd ID to the tracking features of many distros. It is generated by the work of a
mischevious ugly gnome called something near too but not quite Harry the Potter.
Happens on first boot and used to uniquely identify a computer installation.
It is generated by
uuid-gen
FWIW, we cannot (dare not) uninstall it
and, similarly, during a running session we cannot (dare not) delete the “machine-id” file it generates.
Its legitimate purpose, as originally conceived:
Avoid “falldown goboom” if any VMs on a machine are running, using a kernel identical to the host system.
Nowadays…
(I had tested to confirm this, but haven’t recently repeated the test)
Google Chrome, and/or Chromium web browser sniffs the UUID from the machine-id file, and will refuse to launch if it is unavailable.
^-> but go ahead, use Chromium and just “clear your cookies” if that makes ya feel warm n fuzzy n “nonnymus”
—–> go ahead, use a vpn, route your traffic via tor…
(pointless, b/c the uuid can be, and betcha it is, injected into your browser’s http-request headers and/or inserted into a field within XHttpRequest bodies, etc.)
What we can do, regarding uuid-gen:
1) add a startup file which deletes the uuid file at each boot (causing a new, randomly-generated, uuid to be generated)
and/or
2) on a liveboot persistent system, add
/var/lib/dbus/machine-id
to the list of excluded files within /usr/local/share/excludes/persist-save-exclude.list
(as well as the sibling *exclude.list files used for snapshot and remaster operations)
I tried renaming /etc/machine-id, then launching chrome. It does launch, although spits in the terminal output:
(Failed to open "/var/lib/dbus/machine-id": No such file or directory; Failed to open "/etc/machine-id": No such file or directory)
But again, pkg_info -L chromium doesn't show /etc/machine-id
Where has /etc/machine-id come from?
pkg_info -E /etc/machine-id should have answered but it hasn't.
What if I put a cron job for regular rming the file or
printf '%s' 9a069ccef8244ec02b964c4f61c1d905 | wc -m
32
echoing 32 characters of random [0..9a..f] nonsense into it?
Is something gonna break?
Let's stay healthy, you and me and our machines
