72
Linux has /etc/machine-id and you forgot to setup your init daemon to periodically truncate and regenerate a new machine-id so you can be tracked via user telemetry analytics. (lemmy.ml)
submitted 4 months ago by to c/privacy@lemmy.ml
76 comments fedilink hide all child comments
 

Ultimately, the problem is much bigger than /etc/machine-id since there are dozens of hardware IDs on any PC that can be used by malicious telemetry to silently to uniquely identify and track you, and the only solution to this problem currently is to make sure you really trust any software you use.

Systemd, in particular, acts a lot like malware for Linux because if you try to reset your machine-id a long list of stuff that breaks in in it. You could make a cron script to reset /etc/machine-id every day, but machine-id is so deep in the stack that you'd also have to reboot to ensure it's updated.

you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 4 months ago (1 child)

Flatpak provides access to /etc/machine-id by default.

flatpak run org.torproject.torbrowser-launcher && TOR_PROCESS_ID=$(flatpak ps | grep tor | cut -f 1 | head -n 1) && clear && flatpak enter $TOR_PROCESS_ID cat /etc/machine-id

https://docs.flatpak.org/en/latest/sandbox-permissions.html

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 4 months ago*

    Good call, I double checked and you seem to be right.

    I found the github issue tracking this: https://github.com/flatpak/flatpak/issues/4311

    This is easy to state but a lot less easy to solve.

    Hiding /etc/machine-id isn't going to be a meaningful improvement if "other device identifiers" can't be hidden. The most obvious one is the MAC address of each network interface, which is globally unique and available to all processes that have network access.

    To prevent access to the machine ID, xdg-dbus-proxy would have to block all org.freedesktop.DBus.Peer.GetMachineId() calls, which is an incompatible change. That method was intended as a way to determine whether two processes on the bus are running on the same machine; with hindsight, it would have been better as IsOnSameMachine(s: unique_name) -> b on the message bus, rather than GetMachineId() -> s on each peer, but running untrusted software was not really a thing when the Peer interface was designed 15+ years ago.

    Just goes to show how much deeper these problems are than they appear on the surface. Design decisions from 15+ years ago haunting software of today

    P.S. You can shorten your command to simply flatpak run --command=bash org.torproject.torbrowser-launcher -c "cat /etc/machine-id"

    I use --command=bash a lot when I want to just enter a shell inside the flatpak environment

  • permalink
  • fedilink
  • source
  • parent