@avarice
https://news.ycombinator.com/item?id=48815196
asked llm for a summary thing:
Here's an analysis of the attack vectors:
1. Browser fingerprinting (the most practical vector)
Chrome/Chromium reads /etc/machine-id at startup via sd_id128_get_machine(). Combined with other browser signals, it provides a stable, long-term hardware anchor that persists across:
Clearing cookies, cache, localStorage
Using incognito/private mode
VPN/proxy IP changes
The HN thread's gcr comment noted this explicitly.
2. Local network exposure via DHCP
NetworkManager uses a hash of machine-id as the default DHCP client identifier (dhcp-client-id). This means your machine broadcasts a stable, unique token on every network you join — even with random MAC addresses enabled. A WiFi access point or router sees the same DHCP ID from your machine across sessions, defeating MAC randomization.
3. Systemd-resolved DNS correlation
If systemd-resolved is in use, DNS queries can potentially be correlated back to the machine-id through various logging mechanisms, allowing a network observer or DNS resolver to fingerprint traffic as originating from the same device.
4. Journald log leakage
The machine-id is embedded in every systemd journal entry. If logs are exfiltrated (via a breach, an application crash reporter, or a support bundle), they can be correlated to a specific machine across time and services.
5. Application-level surveillance
Any app with read access to /etc/machine-id (or access to dbus, which exposes it via org.freedesktop.DBus.Properties) can use it for tracking. This includes:
- Games with anti-cheat (as noted in HN, they already fingerprint hardware)
- IDE telemetry (VS Code, JetBrains)
- Package managers and dev tools that phone home
- Electron apps (which commonly read system IDs)
6. VM/container image cloning
If a VM template or Docker image ships with a pre-populated /etc/machine-id, all cloned instances share the same ID. This allows cloud providers or adversaries to identify that different instances originated from the same image — useful for infrastructure fingerprinting and targeting.
7. Cross-service correlation
If two different online services both receive hashed versions of the machine-id (via an app, browser extension, etc.), they can correlate user activity across services that the user believes are unrelated, bridging previously siloed identities.
8. Persistence across OS reinstalls
On the same hardware, if you dual-boot or reinstall Linux, the machine-id is not tied to hardware (unlike Windows GDID). So a reinstall generates a new ID. However, if someone uses a backup of /etc or restores from an image, the old ID persists. This is less of a vector than GDID but relevant in imaging scenarios.
9. Combined with TPM/smbios for hardware binding
As noted in the manpage, systemd can derive machine-id from firmware UUIDs (KVM DMI product_uuid, devicetree vm,uuid, Xen UUID). On bare metal, this ties the software identifier to hardware, giving a similar persistence profile to GDID.
Mitigation summary from the thread/manpage:
- Set
systemd.machine_id=uninitialized in kernel cmdline for a fresh ID each boot
- Truncate
/etc/machine-id to 0 bytes + disable systemd-machine-id-commit.service (per HN's gcr)
- Use Whonix or a VM for strong compartmentalization
- Configure NetworkManager to use randomized DHCP client IDs separate from machine-id
which apparently yea, it been a thing even before systemd in d-bus which started in 2004 while systemd apparently a thing since 2010 so like, is been a thing for like literally forever
can be mitigated tho, still dumb designs...
but even the internet is not designed to be like private this or private that
is like, boomers been like "step 1 - get it to work first, worry about the rest later" type thing lol
same for like https or whatever that came just a few years later or somethin somethin
for linux at least, it's not purposefuly designed to be harmful on purpose, it can be mitigated to some extent
windows is still fucked tho, and will always be
