The Devuan machine-id patch - solving a problem or blowing smoke?

Question

As reported on SlashDot, Devuan has recently introduced a patch with the following description:

A few days ago Devuan ASCII 2.1 was announced and one update has been overlooked by most media outlets: our dbus patch to re-generate machine-id at every boot.

This patch matters for everyone's privacy and I hope more distributions will follow our example, let alone Debian. We are dealing with important privacy implications: non-consensual user tracking is illegal in many countries and is not even mentioned in the machine-id documentation so far.

So, what the patch does is make machine-tracking limited to the period between reboots, as opposed to the period between re-installation of the OS.

I don't quite see how this solves the problem it is intended to solve. At most, it mitigates it. But then - if the whole idea of using machine-id when D-Bus'ing over the network is consistently self-identifying your machine, then the privacy issue seems to be with D-Bus itself, and this "jerry-rigging" patch seems like a weird way to address that.

Can someone explain the rationale here?

Answer 1

As I understand it, the rationale is

• the machine-id is world-readable (for some value of “world” meaning any process on the computer, it’s not exposed by default);
• some people report that it’s being read by potentially nefarious programs (including Chromium);
• it doesn’t seem to be needed by anything important (or at least, it doesn’t need to contain a stable value);
• a least in Devuan, generating it at every boot doesn’t appear to break anything, and it reduces machines’ identifiable surface, so it might as well be done.

The discussion starts here on the mailing list, and here on IRC.

I’m not sure all the claims are accurate, or at least, that they all apply to all distributions; but as Adam Borowski says,

Any thoughts on the matter are appreciated, but concrete insight on the ins and outs are much more useful I guess (read: please let's avoid a useless uninformed flame about that :P).

Be realistic... avoiding an uninformed flame would be against our rules :)

Chromium uses the machine identifier for token storage, and as far as I can tell it doesn’t expose it outside (at least, not without masking it as recommended in the machine-id documentation). I don’t know what a change to the machine id affects in Chromium, if anything. The Debian archives allow searches through all the source code: "machine-id" and sd_id128 don’t show anything anything else that seems particularly dangerous (which doesn’t mean there couldn’t be at some point in the future).

On systemd-based systems, changing the machine identifier does have one consequence: journald relies on it to store its logs (see /var/log/journal). Ironically, systemd-based distributions can be set up to change their machine identifier very easily: if /var/lib/dbus/machine-id and /etc/machine-id are empty or missing at boot, the machine identifier is re-generated.

Note that D-Bus is only really used for computer-local communications (although remote communications are supportable in theory). The machine identifier is useful remotely for centralised logs, but again that’s mostly a concern with systems running systemd, or in setups where the administrator specifically uses the machine id as an identifier — and in the latter case, the administrator can also override whatever choices the distribution makes.

The D-Bus documentation explicitly allows for varying machine identifiers as implemented in Devuan:

This UUID must be the same for all processes on a single system at least until that system next reboots. It should be the same across reboots if possible, but this is not always possible to implement and is not guaranteed.

(“This UUID” is the machine id.)

JdeBP has a page on the topic with more information.