Privacy

50695 readers

607 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
Don't promote proprietary software
Try to keep things on topic
If you have a question, please try searching for previous discussions, maybe it has already been answered
Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
Be nice :)

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 6 years ago

MODERATORS

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 1 month ago by yogthos@lemmy.ml to c/privacy@lemmy.ml

77 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

[–] hirihit640@sh.itjust.works 2 points 1 month ago* (last edited 1 month 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