Ai on its own makes mediocre (or bad) outputs. But humans using Ai get improved returns. This doesn't show that Ai is bad, only that it's being used inefficiently.
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.
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.
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.
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.
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.
On most distributions I've seen, SELinux is configured to automatically label /proc files with labels based on fairly granular roles, so that setup already exists.
If you want to completely remove the global information in /proc you can do so by mounting it with subset=pid (and extra points for hidepid=4). This was added to improve container runtime security but unfortunately a lot of programs still depend on reading global procfs files so we can't enable it by default.
As for why all this information exists in /proc, procfs has historically been a bit of a dumping ground. There is an argument for "everything is a file" and so on, but having had to deal with all sorts of insane bugs related to procfs I'm less sympathetic to that argument than I used to be.
> 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.
There actually are some restrictions, if the process doesn't have access to an unmasked procfs mounting /proc will fail, though a recent patch[1] finally made it so that subset=pid works in this case. (And most sandboxes disallow unprivileged CLONE_NEWUSER with seccomp.)
I also wanted to limit access to files/directories inside /proc/PID, or provide fake data. The /proc/PID also contains too many data.
Also, I might want to provide some fake data, for example, if app relies on reading /proc/cmdline or /proc/cpuinfo. So the app should be able to read the files, but not the real data.
> And most sandboxes disallow unprivileged CLONE_NEWUSER with seccomp
I ma worried that some applications (like Chrome, Electron-based apps) might not work without user namespaces. GTK uses "glycin" library, it launches subprocesses for handling images in a bwrap-based sandbox, and it broke inside my sandbox, so I had to do quick fixes for it.
No, sandboxing in Linux is not easy. Just look at "man capabilities" or "man user_namespaces" and see how many rules and exceptions from rules are there. You need to understand it if you write a sandbox, but it is so complicated. And obviously AI cannot be trusted with such a responsible task.
By the way I just read about OpenAI model breaking into Hugging Face and it used "cat /proc/self/mountinfo" to collect information about third-party sandbox it wanted to break from [1]. So my intuition that these files should not be accessible to the sandboxed program, was correct.
It sounded like your problem was restricting access to some /proc/<pid>/ dirs and not others without knowing the PIDs ahead of time:
> How do you [...] allow reading only certain files in /proc, where process IDs are not known ahead?
Such things like /proc/cmdline should be even easier. You can just set regular DAC permissions and ownership on such files. You can just set ACLs on such files.
> There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely.
You don't get the ability to mount just because you created an unprivileged user namespace.
> 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?
Because you might ask them to get that info. If you wouldn't have a use for that, you prevent that using one of a number of security mechanisms, including writing your own SELinux policy where you don't whitelist that access, setting DAC permissions and ownership as such, ACLs as such, etc.
Applications compose and are heavily configurable, and they include such things like language interpreters. You may want to write a script that uses any of that info for whatever. You may want e.g. your window manager to show that info on a statusbar periodically. That info can also be useful for conky or htop, etc.
Vim is a text editor, but you can e.g. have it make a call with ssh to get info from wherever and put that info into the buffer. You can say that a text editor doesn't have a need to read network configurations, but maybe by composing with ssh it does, and it does something useful with it.
I am not sure if I can set ACL or ownership on /proc files, it is not a disk-based filesystem.
> You don't get the ability to mount just because you created an unprivileged user namespace.
Please consult "man user_namespaces", section "Effect of capabilities within a user namespace". It clearly says that one can mount /proc inside a mount namespace governed by a user namespace without being root. The reason why you weren't aware is probably because the rules related to namespaces and capabilities are extremely complicated.
> Vim is a text editor, but you can e.g. have it make a call with ssh to get info from wherever and put that info into the buffer.
I definitely do not want proprietary applications running ssh on my system without me knowing.
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].
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
The trick is to combine it all, which is what MS is doing. For example your MS account stores any GDIDs that you've logged in with.
If you use a different identifier to track changes in a GDID/machine-id/etc., that means you can continue tracking using mainly just the new machine-id, but you should always keep trying to correlate it with other things in case it changes.
Detecting Ai use based on "how many keystrokes did you type and when" doesn't solve the problem, because someone can just write a program to mimic human typing in the words.
So the issue isn't "did a human write something", it's what the actual content is
Have you seen the near daily complaints about how Claude is getting worse or more expensive? I feel like there have been many recent posts like that, but it’s not limited to just here either. It seems like a lot of people are feeling like Anthropic is at least being not transparent, although many would say deceitful.
reply