Indeed. One can regenerate it on each shutdown / reboot. The process is a little different depending on whether one has systemd or not. It's a dbus thing but systemd ingests it and there is a specific process around updating that in systemd.
There is also the NetworkID in Firefox about:networking#networkid
Another trackable piece of information on most systems is the creation time of / which just about any application can query unless it is properly isolated. This can be turned into a short unique hash. There are hacky ways to change the Birth time on unmounted filesystems using debugfs which may result in corruption. Some overlay filesystems do not support Birth time but that is not going to help most people unless the general populous expect all applications to be isolated in name spaces and overlay filesystems but this would have to be an expected pattern across all applications universally.
stat / | grep irth
Birth: 2023-04-17 20:27:01.000000000 +0000
stat / | grep irth | md5sum
8b5e849954373f8f3c2a625847e4e858
But you don't have a service uploading it along with the URLs you visit, which is the creepy part. The ID itself can be useful for your own administration. And if such a service were to appear, it could easily be removed. Everything in Linux is optional, especially as long as you stick to open source.
How do we know? Does anyone check for things like this?
Many, many apps read /etc/machine-id if you do a quick github search.
Apps may have been silently correlating our activity for years without us knowing.
We know DHCP, EFI, GNOME, popularity-contest and many other apps already use it. There are countless ways it could be used already that are hard to detect.
Basically all source is open. Eyes are plenty. Somebody would raise a stink. People can also notice things while monitoring their network via a number of tools like Wireshark, etc. All it takes is one person to notice and share their findings.
It also helps that "Linux" isn't a monolith. One person's installation can be very different from another in terms of the software used. If one piece of software collects, that collection isn't as valuable as Microsoft's because the userbase is much smaller.
It's not perfect, but it's a hell of a lot better. A lot more resistant to abuse. Security in a lot of contexts tends to be relative like that. One's house isn't impenetrable; it's just better than another, in part because the neighborhood is better.
It should be noted that the "correct" usage of /etc/machine-id is that you use it in a way that doesn't allow cross-correlation between different applications by using a HMAC of the machine-id with an application-specific UUID instead of using it directly. systemd-id128 has a command line flag to do this for you.
Whether everyone does that correctly, that's a different question. On the other hand, while developers should be more careful about how they use identifiers like this, if an application on your machine wants to track you they don't need /etc/machine-id.
Mobile's came at the cost of composability between programs and the imposition of policy, which are against the Unix Philosophy. I wouldn't make that trade. Mobile's a sad state of affairs, inferior to desktop in many ways.
You can most likely get better security than mobile's, you just need to e.g. learn to write your own SELinux policies, etc. Facilities are there; they just have a learning curve.
How do you write SELinux policies to allow reading only certain files in /proc, where process IDs are not known ahead? I ended up writing my own FUSE-based /proc emulation. The facilities are there, but it feels like writing your own OS.
/etc/machine-id also exists
/etc/machine-id also exists
Indeed. One can regenerate it on each shutdown / reboot. The process is a little different depending on whether one has systemd or not. It's a dbus thing but systemd ingests it and there is a specific process around updating that in systemd.
There is also the NetworkID in Firefox about:networking#networkid
Another trackable piece of information on most systems is the creation time of / which just about any application can query unless it is properly isolated. This can be turned into a short unique hash. There are hacky ways to change the Birth time on unmounted filesystems using debugfs which may result in corruption. Some overlay filesystems do not support Birth time but that is not going to help most people unless the general populous expect all applications to be isolated in name spaces and overlay filesystems but this would have to be an expected pattern across all applications universally.
But you don't have a service uploading it along with the URLs you visit, which is the creepy part. The ID itself can be useful for your own administration. And if such a service were to appear, it could easily be removed. Everything in Linux is optional, especially as long as you stick to open source.
How do we know? Does anyone check for things like this?
Many, many apps read /etc/machine-id if you do a quick github search.
Apps may have been silently correlating our activity for years without us knowing.
We know DHCP, EFI, GNOME, popularity-contest and many other apps already use it. There are countless ways it could be used already that are hard to detect.
Basically all source is open. Eyes are plenty. Somebody would raise a stink. People can also notice things while monitoring their network via a number of tools like Wireshark, etc. All it takes is one person to notice and share their findings.
It also helps that "Linux" isn't a monolith. One person's installation can be very different from another in terms of the software used. If one piece of software collects, that collection isn't as valuable as Microsoft's because the userbase is much smaller.
It's not perfect, but it's a hell of a lot better. A lot more resistant to abuse. Security in a lot of contexts tends to be relative like that. One's house isn't impenetrable; it's just better than another, in part because the neighborhood is better.
It should be noted that the "correct" usage of /etc/machine-id is that you use it in a way that doesn't allow cross-correlation between different applications by using a HMAC of the machine-id with an application-specific UUID instead of using it directly. systemd-id128 has a command line flag to do this for you.
Whether everyone does that correctly, that's a different question. On the other hand, while developers should be more careful about how they use identifiers like this, if an application on your machine wants to track you they don't need /etc/machine-id.
Yes I think privacy and security on the desktop has fallen way behind mobile and we need much stronger protection these days.
Mobile's came at the cost of composability between programs and the imposition of policy, which are against the Unix Philosophy. I wouldn't make that trade. Mobile's a sad state of affairs, inferior to desktop in many ways.
You can most likely get better security than mobile's, you just need to e.g. learn to write your own SELinux policies, etc. Facilities are there; they just have a learning curve.
How do you write SELinux policies to allow reading only certain files in /proc, where process IDs are not known ahead? I ended up writing my own FUSE-based /proc emulation. The facilities are there, but it feels like writing your own OS.
And it’s easily altered.
It can still be correlated with past IDs by countless other methods in order to keep tracking you further.
But then you're using other methods, you're not using the ID as tracker. In fact if you just remove it, it eliminates this entire discussion.
Exactly , windows should be used for gaming. :D
That's exactly the advice at the end.