[ranger_danger]

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.

[jolmg]

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.

[ranger_danger]

I think it's a common misconception that just because source is available, people are actually looking at it properly.

The number of new security bugs that e.g. LLM models have been finding lately, most of which are very old, are staggering.

[jolmg]

By way of bugs (unintended effects in code), who knows how it compares to proprietary codebases. Those also depend on the particular companies.

However, by way of intentional code that goes against the interests of the user, which would be considered security issues with FOSS but not with proprietary codebases where the interests of the company come first, things should be better with FOSS.

The latter should also be more noticeable than the former. It's possible some of the former may not have run at all, neither accidentally nor intentionally. A bug can just stay dormant without ever surfacing in practice. The latter is there to be used.

The benefit of FOSS with respect to eyes is that those eyes are better aligned with the interests of users (since it's the users looking) than the eyes on closed-source code.

[cyphar]

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.

[ranger_danger]

Yes I think privacy and security on the desktop has fallen way behind mobile and we need much stronger protection these days.

[jolmg]

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.

[codedokode]

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.

[jolmg]

What kind of use-case do you have for that? I suppose whatever it is, you could also e.g. write a privileged service that checks those files with whatever security policy you need. Your client wouldn't have direct access to /proc.

Another option may be to set up a container or PID namespace and give your tool direct access to that /proc.

Regarding SELinux, looking at https://unix.stackexchange.com/questions/767564/selinux-deni...

> the entries under /proc/<pidnr>/ are running under the respective pid's domain

It also seems doable, since you can differentiate which PID directory belongs to what by the domain.

[codedokode]

The /proc contains too many unnecessary information, which can be used for fingerprinting or helping an attack. Run `ls /proc` and find yourself surprised. For example, why do applications need to know the kernel command line? What for? Why do they need the list of major and minor device numbers? List of filesystems? Network configuration?

So I want to follow the principle of minimal privileges and only grant access to files needed for running a program. Sadly many programs cannot run without /proc. For example, poorly coded Apple's Grand Central Dispatch library crashes the application (for example, Telegram) if it cannot enumerate the information about threads or processes. It needs this information to calculate how many additional worker threads need to be created, and if it cannot calculate the number, it terminates the application for reasons I do not understand.

There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely. Anyone can create a user namespace nowadays.

> Another option may be to set up a container or PID namespace and give your tool direct access to that /proc.

/proc contains information not only about processes, but a lot of extra information.

[downrightmike]

Mobile has no privacy, devs slap in any old SDK that promises them money. Way worse than desktop. Spyware is the basis for mobile apps.

[its-summertime]

Using it correctly would not solve the issue at hand however.

[cyphar]

It's hard to do a 1-to-1 comparison but if the telemetry also used a masked form of the machine-id with an application ID unique for the telemetry service then you wouldn't be able to correlate them directly.

To be clear, I think this whole story stinks but the issue here is not that OS installations have unique identifiers (machines have lots of unique identifiers -- hardware MAC addresses, peripheral composition and device IDs, screen resolution) -- it's that Windows has an auto-enabled spyware^Wtelemetry system that shares enough data for them to be able to provide that kind of data to law enforcement. This would be a privacy nightmare even in the absence of a unique OS installation identifier. Heck, they could even take regular screenshots of your screen but that would be too obvious[1].

[1]: https://en.wikipedia.org/wiki/Windows_Recall