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.
75 Comments
onlinepersona@programming.dev · 27 pts · 44d
Wat? If you have something running on your system that's tracking you, you are already fucked. It doesn't require that file. It can just create one anywhere on the system and use it, if need be.
yogthos@lemmy.ml · 9 pts · 44d
The problem with machine-id specifically is that it's become a standard way for the browser to identify itself. There obviously other ways you can be tracked, but this is a very low bar and a common way of sites tracking people.
someone@lemmy.today · 2 pts · 39d
this is really shocking. wouldn't browser makers concerned with privacy like librewolf, mullvad, ungoogled-chromium, etc, try to block this by default? is it that they don't know? is it that it can't be blocked?
how does a regular user of a typical linux distribution like fedora or debian block this?
is this machine-id used to track people on hardened distros like tails or qubes?
can this machine id be read by sites when using tor browser?
i don't understand why debian, for example, who removed telemetry from keepassxc before putting it in their repo because they didn't like a password manager phoning home, would allow a persistent id that could be easily read by many sites.
yogthos@lemmy.ml · 2 pts · 39d
I believe liberewolf does hide your machine id
MangoPenguin@lemmy.blahaj.zone · 4 pts · 42d
A browser is one example, what's the alternative to that other than sticking it inside some sandbox or something?
onlinepersona@programming.dev · 2 pts · 41d
Sticking it into a sandbox is reasonable, but you can also use more privacy aware browsers like LibreWolf. Chrome and Chromium will track you 100%, so don't launch those unless necessary.
At least that's what I do.
hirihit640@sh.itjust.works · 18 pts · 45d
Flatpaks might be the solution here. Flatpaks run in containers, they might have isolated machine-id already.
Though tbh if you don't trust the apps on your Linux system, you have more to worry about than fingerprinting. Regular executable binaries and system packages have zero isolation, any malware can wreak havoc. Flatpaks are getting there but many apps still ask for permissions they don't need, increasing risk.
For untrusted apps, run them in a browser (if a web-app), a container/distrobox, or a VM.
yogthos@lemmy.ml · 13 pts · 45d
The browser itself is one of the biggest vectors of attacks here. Both Chrome and Firefox indirectly via libdbus, read your machine-id. Firefox shares browsing data and other unique info with 'with partners, service providers, suppliers and contractors' including Cloudflare and Google.
hirihit640@sh.itjust.works · 4 pts · 45d
Well browsers are apps, just like any other app on your system. So the same advice applies. If you don't trust chrome and firefox but you still want to run them, use a container/distrobox/VM. There are plenty of more private browsers though, like Brave or Mullvad Browser.
Web apps, on the other hand, run inside the browser sandbox, which is an entirely different environment. They don't have access to machineid unless the browser gave it to them, for example via a browser extension. There's still a lot of fingerprinting vectors though, so use Tor Browser or Mullvad Browser, ideally with JS disabled. This website is a great way to check your fingerprint: https://abrahamjuliot.github.io/creepjs/
yogthos@lemmy.ml · 20 pts · 45d
Browsers aren't just apps, they're effectively platforms which run all kinds of apps you end up accessing online when you visit sites. Since the browser leaks the id to these apps, you're effectively trusting the apps. Sure, you could run your browser in a VM or whatever, but that's missing the point entirely. The real question is why your machine needs to have a unique identifier, and why the fuck it's baked into functionality of systemd which is now replacing the traditional tool chain with a monolith.
And yes, I'm fully aware of other metadata that the browser leaks, and the fact that people are just starting to talk about that is also a problem. Running with Js disabled or putting a browser in a VM, is not really a solution for vast majority of people. The issue is that we have systems that are designed to enable tracking by default, and you have to jump through hoops to get around that. Telling people here are the hoops isn't really helpful.
hirihit640@sh.itjust.works · 5 pts · 45d
I'm not familiar with the purposes or history of machine-id, I'd guess that it's just a legacy artifact that can't be easily removed now.
There's definitely a lot to be desired when it comes to privacy on Linux. Unfortunately Linux was designed before many of the privacy and security best practices became established, which is why is it less secure than modern systems like Android (source). Trying to re-architect Linux at this point would be an insane undertaking. Machine-id is just one thing in a long list that would need to be changed. Nothing wrong with advocating for it, but I just wouldn't expect it to happen for at least 5 years.
Containers are a modern technology with isolation and security as a core goal from the start. And by now, containers are already deeply integrated into the Linux community, for example look at how the entire Fedora Atomic project (including Bluefin, Aurora, Bazzite) uses container-based infrastructure to build the OS images. So that's why I've been moving towards it as a solution for my privacy needs, and I recommend others look into it as well.
Edit: rewording some sentences
yogthos@lemmy.ml · 12 pts · 45d
Systemd was designed long after a lot of these security practices and problems with tracking were well understood. There's very little excuse for it doing a lot of the things it does. Systemd is literally re-architecting how Linux was meant to work originally, and for the worse. I get the impression you're not actually familiar with the history of Linux or Unix philosophy in general.
Having to put everything into containers is really just a work around bad architecture that keeps being pushed in the Linux world. Containers are useful, and probably the only way to actually keep apps from having too much access to the system at this point, but I don't see why bad architecture should be accepted and then have to be worked around.
hirihit640@sh.itjust.works · 4 pts · 44d
I've read enough mailing lists and issue trackers to know that they are far more complex than they look on the surface, so I definitely won't claim authority about them.
Take this one that I found recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257
It's a bug report about Firefox's favicon cache. They started looking into it, but found out that if they fix this bug, it creates fingerprinting risk, so they have to address that as well. And so the issue gets stuck in limbo for like 10 years, and is still open till today.
Regarding systemd, it had to be built on top of the existing architecture, and more importantly, had to appeal to the Linux community to be adopted, so it couldn't change too much. I assume they have their reasons for depending on machine-id. It might not even be a direct dependency. Maybe it allowed easier adoption by the big players.
I don't know, and honestly, I don't really care about digging into every single fingerprinting vector (of which there are probably tons more), when I can just use containers. And while using containers might feel like a hack or workaround, if we look at Flatpak, it seems like containers are becoming the framework for app isolation on Linux, similar to what already exists on Android. So it may very well become the official solution to privacy and security on Linux.
yogthos@lemmy.ml · 4 pts · 44d
My point is that systemd did not have to be built at all. It's an abomination that goes directly against the original philosophy of Linux creating a monolithic monstrosity to replace individual and composable programs that used to be the way init works. Now, everything is tied to it and it's become like a cancer in a linux system that's inoperable. The whole system-id problem is just one example of why this is a terrible design.
sudoer777@lemmy.ml · 3 pts · 44d
Running browsers safely in a Linux container/sandbox is not straightforward, for instance Flatpak blocks unprivileged namespaces which breaks the browser's own sandboxing so it's recommended to avoid Flatpak browsers.
hirihit640@sh.itjust.works · 2 pts · 44d
Tbh I haven't kept up with that issue for a while now. I'm guessing it still isn't addressed. I usually disable JS anyways so that mitigates almost all attacks. But I have installed browsers in Distrobox before, installing the browser as a system package instead of a Flatpak. Do you know how the sandboxing works in that case?
sudoer777@lemmy.ml · 3 pts · 44d
Not sure, although I just did some searches and it appears that Distrobox uses rootless Podman which supports nested unprivileged namespaces. And if it broke the saneboxing there probably would have been an error when you tried to run it.
umbrella@lemmy.ml · 2 pts · 43d
yogthos@lemmy.ml · 1 pts · 43d
don't think so
Ferk@lemmy.ml · 10 pts · 44d
Note that flatpaks are using systemd's sd_id128_get_machine_app_specific API, which generates an app-specific id that's derived from the original machine-id.
The app-specific id will be unique per-app so it won't be shared between different apps / flatpaks. The apps can't know the original machine-id, but the id they get would still be the same on every restart of the app and in theory does not prevent different sessions within the same app to be fingerprinted as coming from the same user.
0t79JeIfK01RHyzo@lemmy.ml · 7 pts · 43d
Flatpak provides access to
/etc/machine-idby default.https://docs.flatpak.org/en/latest/sandbox-permissions.html
hirihit640@sh.itjust.works · 2 pts · 41d
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
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=basha lot when I want to just enter a shell inside the flatpak environmentmarcie@lemmy.ml · 12 pts · 44d
The bigger concern here is that the app isn't sandboxed, not machine id. Run something like secureblue that has better sandboxing by default
https://github.com/secureblue/secureblue/issues/1121
FineCoatMummy@sh.itjust.works · 8 pts · 44d
I tried librewolf to see if it reads /etc/machine-id. It does not. At least not to my trials so far. I used the strace cmd to watch it. I tried when starting librewofl. And again when loading various sites.
LW does read MANY font related files from /etc. That could be a fingerprint ofc. Esp if a site reads back the canvas! Fonts are a majority of what LW reads from /etc. LW also reads /etc/os-release. IDK what it does with that. That file does not have a unique machine id, but it ids your OS and version. There are a few others too. Like /etc/localtime.
IDK about Firefox. I didn't try it. Maybe it would be much worse. Someone can try and report here about it?
My guess is, every normal browser can be accurately fingerprinted. Even with fingerprint resistance like FF forks. Esp if JS is enabled!! There are just toooo many ways. ID resolution services are used by most big sites now. They employ very smart and clever data scientists. I doubt we can block every method they have, in a good enough way.
Tor Browser tries! But that is blocked by sites that use identity resolution. Also, TBH I don't even believe Tor can block enough fingerprinting. Some like TLS fingerprints are not even blockable by a browser.
kuerbiskernoel@feddit.org · 3 pts · 43d
What about terminal browsers?
Anonymous_Leaker@lemmy.world · 2 pts · 43d
TwilightKiddy@programming.dev · 1 pts · 44d
I'd guess it's some standardized way to determine which OS the browser is running under? Like it does not report the specific Linux version in the user agent header, but it does say that it's Linux and it's architecture. I'd assume there is just some standardized library for it and for Linux the easiest way to know where the hell your binary got launched is
/etc/os-release.FineCoatMummy@sh.itjust.works · 1 pts · 43d
Yah that's gotta be it.
AnnaFrankfurter@lemmy.ml · 7 pts · 44d
Firejail
dawcas@scribe.disroot.org · 2 pts · 43d
I believe flatpak apps are also sandboxed, but I haven't checked anything so I may be saying the stupidest thing.
sudoer777@lemmy.ml · 6 pts · 44d
The Impermanence module for NixOS recommends persisting
/etc/machine-id. Is there any downside to not persisting it? (which is currently what I'm doing because I get errors when I do)yogthos@lemmy.ml · 5 pts · 44d
for most desktop users, not persisting /etc/machine-id is usually fine, but there are some specific scenarios where it can cause issues. Systemd uses machine-id to tag log entries. If it changes, you might lose the ability to correlate logs across boot sessions in journalctl. This is mostly an annoyance for debugging rather than a functional problem. A few NixOS modules like services.openssh or certain mail servers use machine-id for generating default host keys or identifiers. Changing it might cause warnings on first boot after a change, but usually nothing breaks since they fall back to other identifiers.
kwarg@mander.xyz · 5 pts · 44d
so, for the noobs, what do we do? do we just live with thay file untouched there? :S
yogthos@lemmy.ml · 2 pts · 44d
Pretty much...
dropdrip@lemmy.ml · 5 pts · 44d
I was unaware of this. As far as I can understand this is a design for admins who manage fleets and virtual machines, so it's not surprising it comes from Lennart and systemd. However, even openbsd has /etc/machine-id. Over in bsd land it seems to come from dbus. Is the file a systemd design or a dbus design? Is it something users should be concerned about... probably, but all of computing is a nightmare. Just another fire to add to the fire pit.
yogthos@lemmy.ml · 1 pts · 44d
Yeah, since OpenBSD doesn't use systemd, that points to dbus origins for the file.
Anonymous_Leaker@lemmy.world · 2 pts · 43d
yogthos@lemmy.ml · 2 pts · 43d
as I recall it does actively randomize machine-id?
someone@lemmy.today · 1 pts · 39d
is this something sites can actually query on linux system in most browsers?
for example, if cloudflare is checking if I am a human, are they able to read my machine id if i am using firefox, librewolf, mullvad browser, tor browser, chrome, or chromium?
yogthos@lemmy.ml · 4 pts · 39d
yup, both Chrome and Firefox expose your machine-id by default
someone@lemmy.today · 2 pts · 39d
how did you learn about this?
i thought i was aware of privacy but have not heard about this before.
why are open-source operating systems allowing this as a tracking vector?
what is the smart way to reduce tracking by this mechanism?
yogthos@lemmy.ml · 2 pts · 39d
Just ran across somebody talking about it on a forum. To be clear, having a consistent id can be useful outside of tracking, which is probably why it got introduced, but clearly tracking potential wasn't considered fully here.
procapra@lemmy.ml · 1 pts · 40d
So then as long as my machine doesn't have systemd im fine?
yogthos@lemmy.ml · 1 pts · 40d
not necessarily, but it's definitely easier to avoid having machine id without it