The File /var/lib/dbus/machine-id Matters For Your Privacy (and Devuan Fixed It) (devuan.org)
147
Long-time Slashdot reader jaromil (Denis "Jaromil" Roio) writes: A few days ago Devuan ASCII 2.1 was announced and one update has been overlooked by most media outlets: our dbus patch to re-generate machine-id at every boot.
This patch matters for everyone's privacy and I hope more distributions will follow our example, let alone Debian. We are dealing with important privacy implications: non-consensual user tracking is illegal in many countries and is not even mentioned in the machine-id documentation so far.
"In theory, the machine-id should be a persistent identifier of the current host," explains the README documentation. "In practice, this causes some privacy concerns..."
This patch matters for everyone's privacy and I hope more distributions will follow our example, let alone Debian. We are dealing with important privacy implications: non-consensual user tracking is illegal in many countries and is not even mentioned in the machine-id documentation so far.
"In theory, the machine-id should be a persistent identifier of the current host," explains the README documentation. "In practice, this causes some privacy concerns..."
It's not the presence of data: it's the use you do (Score:5, Insightful)
It's not the presence of data: it's the use you do with it.
If you have untrusted software running on your system it will be able to track you in hundreds of ways and exfiltrate much more sensitive data.
OTOH many applications do need a persistent machine ID for legitimate purposes.
Re:It's not the presence of data: it's the use you (Score:4, Insightful)
OTOH many applications do need a persistent machine ID for legitimate purposes.
Many applications have a reason to record an ID unique to their installation. Very few applications have reason to record an ID unique to the machine, so that everything you do can be cross-tracked. Most applications belong in a virtual jail where they should have no idea if you migrated them to different hardware or a different OS installation. And of the rest the vast majority just need a soft reset that any assumptions you might have made should now be re-validated, not a history tracking where they've been. Sure, a global GUID is easy. It's also a really bad idea for everyone who cares the least about their privacy.
Re:It's not the presence of data: it's the use you (Score:2)
Many applications have a reason to record an ID unique to their installation. Very few applications have reason to record an ID unique to the machine, so that everything you do can be cross-tracked.
MachineID is useful to track the image across a cloud computing environment. There's nothing else that really is dependable.
Re:It's not the presence of data: it's the use you (Score:4, Informative)
I see only four uses in entire Debian (thus, excluding proprietary non-packaged software):
* Chromium for an advertising "cloud enrollment"
* Gnome for keeping desktop layout specific to a machine (rather than monitor layout which would make more sense)
* two uses inside systemd itself
Thus: one outright harmful, three misguided, zero good.
Re:It's not the presence of data: it's the use you (Score:3)
Also elogind and NeworkManager (judging from https://codesearch.debian.net/... [debian.net])
Broken not fixed (Score:5, Interesting)
They didn't fix the functionality it provides, they broke it. If they wanted to fix the privacy they would have added access control for applications to the file, not broken the core reason it exists in the first place.
Comment removed (Score:2)
Re:Broken not fixed (Score:2)
Can this even be fixed on Linux?
The solution is to grant access to the identifier on a per application basis, and maybe offer some apps a random one to keep them happy. Linux has no mechanism for that at the moment.
Re:Broken not fixed (Score:3)
Re:Broken not fixed (Score:3)
like that dumbass "Choose a new IPv6 address for every outgoing connection" thing
I have a DSL modem (from the telco, so I can't just replace it at a whim) which caches every fucking one of those IPv6 addresses that it sees, with no TTL, then to do name resolution it roulettes one of them at random. I had to disable it on every computer I have (including OSX and Windows) because of that. It also does screwy stuff that confuses NetInfo from OSX 1.5 and earlier, making old computers go catatonic within a couple of hours of being connected to the LAN. Thank you Arris/Pace for such a high quality networking stack!
Re:Broken not fixed (Score:2)
OK. But for most people I'm aware of it doesn't add any security. If changing it each boot increases privacy, that seems a good move.
OTOH, I tend to avoid software that isn't GPL or equivalent. (E.g., I'll accept BSD code if the source is available.) Anything else is going to run in a virtual machine, if I run it at all...and that usually means I won't bother.
Re:Broken not fixed (Score:2)
Security? What are you talking about? This is for installation identification. It has a purpose. If you are concerned about privacy then limit access, don't break is purpose.
Re:Broken not fixed (Score:2)
Well, no. Most people that I know what OS they are using are using some variety of Linux. Most of the rest are using Apple.
I acknowledge that the value added is, supposedly, privacy. (There's reason to be dubious.) And that that is only indirectly connected to security (i.e., it makes you harder to target).
Still, if it adds at all to security, I'm in favor of it, as it wouldn't inconvenience me at all.
Re:Broken not fixed (Score:2)
What are the core reasons it exists in the first place? They seem likely to be all shit baggy ones ... you know, like how Microsoft invalidates your keys if you hardware changes too much ...
Re:Broken not fixed (Score:2)
To identify an installation or instance in a way the user / admin requires. Nothing more nothing less. Quite important if you're automating VMs and running services that need to identify the installation easily.
chmod 440 /etc/machine-id
create a dedicated group and restrict required access to said group. That's all they had to do.
Incidentally the man page says: "It should be considered "confidential"". So if there was a privacy problem then it was due to Denuvo fucking up, and to try and resolve it they fucked it up further because they can't RTFM (quite fitting for a bunch of people who's list of Systemd complaints could often be fixed by reading that manual too).
Why would it be mentioned in upstream docs? (Score:3, Insightful)
Re:Why would it be mentioned in upstream docs? (Score:4, Insightful)
lololol
Devuan is the one following the Unix standard most closely, not Debian. systemd is not the Unix way.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:3)
Linux is not Unix. DOH!
Indeed. And it becomes less and less like Unix-like all the time.
Whether that is good or bad is debatable.
Re:Why would it be mentioned in upstream docs? (Score:2)
My neighbor has a VW camper van from the 70's. Still works fine.
Too soon to tell if there will be many 50 year old Teslas on the road.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:3)
Yep. So does a C64. Would you rather try to get your work done with it or whatever you are typing with now?
I have a C64 in a box somewhere. If it was internet capable for typing text on /. it would probably be fine, but more likely one day it will find its way to a landfill.
Still, when that time comes the neighbor's VW will probably still be running.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:3)
Yeah. You are completely missing the point. But if you really still think old software is great feel free to install a Linux distribution from the 1990s on your laptop and then let us know how that works out.
I might still have Redhat 4.0 discs somewhere. I liked it better than Windows 95, but nowadays I actually prefer *BSD.
Windows has always been bloatware, and now Linux is joining the club. Whatever works for you makes no difference to me though.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:3)
You are kidding, right? Please tell me you aren't that stupid.
Re:Why would it be mentioned in upstream docs? (Score:2, Insightful)
Re:Why would it be mentioned in upstream docs? (Score:2)
I don't actually subscribe to the more lines of code = better argument.
I subscribe to what you need to do the job school of thought. Not sorry.
Re:Why would it be mentioned in upstream docs? (Score:2)
That is a strawman, but out of curiousity, you do know that most of the "more lines of code" are for device drivers supporting newer devices, right? You can't even compare Windows and Linux since Windows doesn't include all the device drivers for every kind of hardware you can imagine. You also don't have to include most of these "more lines of code" in the build if you don't need them. It's called a kernel config.
Re:Why would it be mentioned in upstream docs? (Score:2)
You can't even compare Windows and Linux since Windows doesn't include all the device drivers for every kind of hardware you can imagine. You also don't have to include most of these "more lines of code" in the build if you don't need them. It's called a kernel config.
I have not actually needed to build a kernel in a long time, but Linux also has a shit ton of driver modules as well as I'm sure you know. I thought we were arguing over systemd/poetteringOS vs sysv/bsd init. Otherwise cheers!
Re:Why would it be mentioned in upstream docs? (Score:2)
>> "Windows has always been bloatware, and now Linux is joining the club."
> You are kidding, right? Please tell me you aren't that stupid.
I run Gentoo linux at home, using gnumeric and other GNOME apps on ICEWM (not a GNOME desktop). When I do system updates every month or so, it seems like there's always a new lib or two that's a new mandatory dependancy. Over the years I've seen stuff added like harfbuzz, dbus, glu, ghostscript, etc, etc, etc. This has nothing to do with new apps being added, just the developers bloating the software with dependencies that were not required before.
Re:Why would it be mentioned in upstream docs? (Score:2)
Over the years I've seen stuff added like harfbuzz, dbus, glu, ghostscript, etc, etc, etc. This has nothing to do with new apps being added, just the developers bloating the software with dependencies that were not required before.
This is because the software developers did not grok the unix way. See, you might say, well, just don't install the updates.
But what if you want some new feature, but not that other one? Okay, we'll add a checkbox.
5,000 checkboxen later: this is a real pain when I need to change configurations, so we'll add some more layers...
Eventually, you get around to scripting, where it's all been decomposed to functions.
You could've just built small simple tools that carefully limited themselves to one problem to maintain composability and features without bloat.
"Those who don't understand unix are doomed to reinvent it." -- some old dude.
See, you can have your nice Integrated Everything Environment, AKA the windows model, but it comes at a cost. Linux is going full Windows right now.
Re:Why would it be mentioned in upstream docs? (Score:2)
A friend added an 8-bit ISA slot to a C64 once. Or maybe it was a VIC20, but it was in that ilk. Then he put a Hercules card in it. It served as an internet kiosk for some years (in the earliest days.) It was modem-connected, though.
Re:Why would it be mentioned in upstream docs? (Score:2)
I remember the C64 keyboard as being pretty good. It could be my memory's not that great, or my comparisons at the time were terrible, but that's what I recall.
A modern C64 with a decent keyboard, plenty of USB ports and a high hackability index would be nice. There's probably an Indiegogo out there for that, I should look around.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
I like the form factor of the C64 and the Amiga 500, and I like the hackability of the architecture. The Apple IIs as well. That's what I mean by a modern C64. The RPi has the same kind of ethos.
Also, you don't remember the C64 keyboard very well
Fair enough. It has been a long time.
Re:Why would it be mentioned in upstream docs? (Score:5)
People that complain that Linux is becoming less like UNIX aren't doing it because it has more technology in it. They are complaining because it's leaving the philosophy of UNIX behind. systemd goes completely against the philosophy of UNIX to keep things small, do one thing, and do it extremely well. There are some other reasons too but that's the main one. There's nothing wrong with having new things. If there was then Linux wouldn't be on laptops and tablets. There wouldn't be drivers for for everything that Linux supports. There wouldn't be the software that runs on Linux.
Re:Why would it be mentioned in upstream docs? (Score:5, Insightful)
Linux is not Unix.
Right, Linux is a Unixlike, and systemd makes it less Unix-like.
DOH!
Yeah, that's what Homer says when he realizes he did or said something stupid. You're showing uncharacteristic self-awareness there.
Re:Why would it be mentioned in upstream docs? (Score:3)
Wow, you are one dumb motherfucker.
Tell me all about it, stable genius.
Re:Why would it be mentioned in upstream docs? (Score:2)
He actually engaged the argument with actual points...
He is correct, Linux is a Unix-like. Systemd does make it less unix-like.
Whether or not that is a good thing is a different debate that he did not enter- but one that you are very sensitive to since you are a systemd sychophant or superfan... I'm not sure we even have the correct word for your rabid defenses of it.
He is also correct that "Doh!" is used by Homer when he does something stupid... And it was fair to point out that your argument was stupid and that Doh! was perhaps the perfect thing for a self-aware person to make.
And you called him a dumb motherfucker.
Truly, your parents must be proud of you.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:3, Interesting)
There's the unix standard, and then there's the so-called "unix way" or philosophy. Which are you referring to? Systemd remains compatible with sysv init, so you can still implement a posix unix system with systemd and expect things like legacy init scripts and even run levels to still work (debian ran init scripts under systemd for a long time during the transition to systemd targets). Even syslog is still supported, although most distros don't enable it by default for whatever reason (likely that no one but system administrators ever really reads the logs).
In many respects systemd follows the unix philosophy more than the various hacks and subsystems that have been employed by init systems and unix systems in general over the last few decades. Systemd is highly modular; you can install and use the parts you need. The individual parts of systemd generally focus on one thing, and those bits can work together. Sounds a lot like the unix philosophy to me. Instead of having lots of services implement (often poorly) daemonization routines internally, you can have systemd do that. Also process supervision was always a hack in the past. Init scripts meant for one distro might not work quite right on another distro.
Re:Why would it be mentioned in upstream docs? (Score:2)
That's why we even had a post [slashdot.org] about it.
Re:Why would it be mentioned in upstream docs? (Score:2)
Even syslog is still supported, although most distros don't enable it by default for whatever reason (likely that no one but system administrators ever really reads the logs).
Please tell me you are not this idiotic in real life?
Re:Why would it be mentioned in upstream docs? (Score:3)
I don't mind the init portion of systemd. But you can't deny there seems to be a movement to shove *everything* into it- and frankly, some of the things it has replaced, it has done a subpar job at, and a lot of that has to do with the fact that Poettering is a fucking asshole.
Pulseaudio sucked for a decade for this same reason.
Re: Why would it be mentioned in upstream docs? (Score:2)
Re: Why would it be mentioned in upstream docs? (Score:2)
On the other hand Mac OS is actually Unix, and Mac OS uses launchd for init. Launchd is the inspiration for systemd, and does a lot of the same things.
Nobody likes launchd. But at least launchd doesn't have a web of interdependencies with other things people don't like.
Re:Why would it be mentioned in upstream docs? (Score:2)
I feel you are praising Debian for an extremely stupid move. I have seen NO, i.e. ZERO, advantages to including systemd. None. The disadvantages haven't been major enough to cause me to switch, but I keep wondering whether it's too much of a hassle to switch to a different distribution. Devuan is one of the main ones I consider switching to.
Re:Why would it be mentioned in upstream docs? (Score:2)
What distribution are you in charge of?
Re:Why would it be mentioned in upstream docs? (Score:2)
What distribution are you in charge of?
It's the people who have to use them that are the most important here, but I'm sure that made you feel clever sweetheart.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
Christ, you need to refrain from using slashdot until you've had some coffee, dude. I apologize if you're on the spectrum.
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
Unix like has never meant "lots of poorly written shell scripts with massive amounts of redundancy to do simple things."
What it has meant is lots of simple utilities, each doing one thing well. What it never anticipated was that some autists would go hunting through various /bin directories and wet their pants every time they found a utility that had command line switches and might be integrated into other utilities as needed.
Want to see a systemd fanboi's head explode? Just tell him you use it. But you just have it call all the /etc/initd shell scripts.
Industry standards (Score:2)
Oh you mean that untested monstrosity that was pushed by a company whose main source of income is support? What about it?
Re:Industry standards (Score:2)
Re:Industry standards (Score:2)
Debian was pretty close to a draw as I recall and someone had to break the tie. Also Redhat is the biggest commercial entity in Linux land so of course everyone will fall behind them. Anyone ever tell you that you're a real cunt?
Re:Industry standards (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
Re:Why would it be mentioned in upstream docs? (Score:2)
man page (Score:5, Informative)
From the manual [freedesktop.org]: "This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm."
Looks like systemd developers have already thought about the implications of having/using/exposing it. Now the real question is how it gets exposed in Debian/Devuan to warrant this attention.
Re:man page (Score:4, Insightful)
"We think this is bad, but we implemented it anyway..."
Re:man page (Score:3, Informative)
lrwxrwxrwx 1 root root 15 May 14 2019 /var/lib/dbus/machine-id -> /etc/machine-id /etc/machine-id
-r--r--r-- 1 root root 33 May 14 2019
Anyone, or process, can read it. Someone failed the confidentiality and 'do not expose' bits.
Tested on GNU/systemd/Ubuntu 18.04.
Re:man page (Score:2)
Yep, machine-id is mainstream... and only this fork is trying to change it.
Re: man page (Score:2)
Re:man page (Score:2)
Re:man page (Score:5, Informative)
Most PCs come with embedded NICs whose unique HW address can be read by any application. I don't understand what's all the fuss about.
And then NVIDIA GPUs have unique IDs as well,
And then we have user-accessible
which uniquely identifies partitions and these UUIDs only change if you reformat the partitions. And then most people have different partition schemes (except the ones who use Windows installed by an OEM).
Then you have a gazillion of unique IDs at
.
And then you can read your monitor information and even its EDID in some cases from /var/log/Xorg.log
In short, if you're obsessed with your PC being as average as possible and not uniquely identifiable by the software you run you should be using a VM.
Re:man page (Score:2)
I noticed the same thing. I guess it's not out of line for me to engage in some serious eye rolling when reading the latest from freedesktop.org.
What purpose is there to this unique identifier if it can be changed by the user? From the manpage:
Oops! More eye roll: Simple emulation of the Devuan patch -> ``cat /dev/null > /etc/machine-id'' during shutdown.
On many of my Linux systems, I rarely do an upgrade from version "N" to version "N+1" [1] opting, instead, for a new install in an unused partition. Same hardware -> New install -> new machine-id. So much for uniqueness.
1 -- Point releases? Sure but that's simply patching.
Re:man page (Score:2)
>"Looks like systemd developers have already thought about the implications of having/using/exposing it. Now the real question is how it gets exposed in Debian/Devuan to warrant this attention."
I didn't even know it was there until now. But it appears all regular users can read the "file" and get the ID (I just did as a regular user). The permissions allow any user to read it, thus ANY program or service on the system running as ANY user can read that ID. So the answer is- it is exposed to everything, at least locally.
There are, of course, other ways to derrive a "fingerprint" from a Linux system as a normal user (host name, IP address, MAC address, CPU model, partition table, OS version, etc). But this certainly simplifies the process, considerably. As to whether that is good or bad, it does depend on your perspective.
Re:man page (Score:3)
There's a reason this is there...
Host name is subject to the user changing it
IP address is subject to DHCP in most cases
MAC address is in the NIC card and that can be swapped
CPU model is not unique
Partition table is the same on fresh installs
OS version is not unique
Re:man page (Score:2)
>[...]is subject to the user changing it"
How is any of that much different than machine-id, which is also subject to the user changing it, if they want to?
https://www.thegeekdiary.com/c... [thegeekdiary.com]
>"is not unique"
Neither is machine-id, not to the world or to all time. It is just a random value. I can pull a sequence from a combination of the stuff I listed with a lot of entropy. It just isn't "standardized" and as easy/convenient or as persistent. (That is what I meant in my first post- not a single factor, but a combination of those values, boiled down to a single value). That is what some license management systems on Unix/Linux has done for countless years (build a fingerprint from several long-lasting system values). That and the older "gethostid()" before it.
My point was that machine-id is not the only way one could track machines with a high degree of "uniqueness" even if they were munging the machine-id regularly.
Re:man page (Score:2)
Re:man page (Score:2)
Freedom 1, Protection 0. Lots of time in the First (Score:2)
Seems like the publishers and spooks love having a machine ID, but true Linux geeks don't like the machine ID citing privacy as their goal. Let's face it, the "free" operating system has been co-opted by the spooks. Linux is tempted to fight back, Windows cites the terms of service, and Mac is for the Steve Jobs Estate to run.
We'll get more secure computing eventually, but it's going to have to leave something for Commission Junction and DoubleClick/Google to trace who got what ad so when you buy, the site you use is paid. Sorry, the WWW is not "free". Now that there's an ID for you, the spooks will, if they're out to get you, find you. It's the only way the WWW works... sites that don't comply always fail.
Now it's broken, and still not private anyway (Score:2)
This is a facepalm on so many levels.
Re:Now it's broken, and still not private anyway (Score:2)
Under the assumption that the machine ID is leaking to the outside, we can suppose that "they" now just need to keep track of machine ID uniqueness over time to gradually, eventually differentiate you from other sources of traffic.
Crap! That means that, despite our best efforts, they'll eventually figure out how to identify and access our web server!
Um ... (Score:2)
What would be the use/value for a machine ID that is re-generated at each reboot? /dev/random? (He said only half jokingly.)
Couldn't I just pull something just as useful from
Re:Um ... (Score:2)
It's a destruction of the machine-id, because that can only be used to track the machine. Huh?
Security (Score:2)
Shouldn't this be fixed with security? Having a stable machine ID is probably useful for something - probably logging. If the only thing that needs it are system daemons, then disallow reading it from userland, and make sure dbus won't report it back to userland.
Re:Security (Score:2)
It's only useful for logging if the log is going to be stored on another machine mixed with the logs of lots of different machines. Otherwise you know it's for the machine that holds the log. (Or that wrote the log, if it's to a removable disk or some such.)
File not found. (Score:2)
I'm sorry. You call yourself a nerd and don't compile your own kernel?
There's only 1 truly safe & private computer (Score:4, Insightful)
Not documented....!!BULLSHIT!! (Score:2)
This patch matters for everyone's privacy and I hope more distributions will follow our example, let alone Debian. We are dealing with important privacy implications: non-consensual user tracking is illegal in many countries and is
so far.
Russian Troll Alert /etc/machine-id
/etc/machine-id.
The machine ID does not change based on local or network configuration or when
hardware is replaced. Due to this and its greater length, it is a more useful
replacement for the gethostid(3) call that POSIX specifies.
This machine ID adheres to the same format and logic as the D-Bus machine ID.
This ID uniquely identifies the host. It should be considered "confidential",
and must not be exposed in untrusted environments, in particular on the
network. If a stable unique identifier that is tied to the machine is needed
for some application, the machine ID or any part of it must not be used
directly. Instead the machine ID should be hashed with a cryptographic, keyed
hash function, using a fixed, application-specific key. That way the ID will be
properly unique, and derived in a constant way from the machine ID but there
will be no way to retrieve the original machine ID from the
application-specific one. The sd_id128_get_machine_app_specific(3) API provides
an implementation of such an algorithm.
demonoid-penguin@wonderland.mil ~ $ man -k machine-id
machine-id (5) - Local machine ID configuration file
systemd-machine-id-commit.service (8) - Commit a transient machine ID to disk
systemd-machine-id-setup (1) - Initialize the machine ID in
The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime during early boot if necessary. The machine ID may be set, for example when network booting, with thesystemd.machine_id= kernel command line parameter or by passing the option --machine-id= to systemd. An ID is specified in this manner has higher priority and will be used instead of the ID stored in
Re:that is only for privacy-fags (Score:2)
There's been many efforts to try to secure Linux... but this is from a rebel fork and I doubt Debian is going to accept this change.
Re: that is only for privacy-fags (Score:5, Insightful)
Which is about as bad an idea as when software licensing was tied to the system's network MAC or IP address. Change/update that network controller? Replace motherboard? Sure, that doesn't happen often but when it does, you're screwed. I still remember having to beg a vendor to re-license an expensive software package when DEC dropped support for an older Ethernet controller and we replaced it with one for which support would be continuing. Legato used to tie their licensing to networking information and all it took was adding a second network controller to the system to invalidate the licensing of your backup software. I lost count of the number of times that the server teams had discussions with the networking team that, because of software licensing, we couldn't be changing IP addresses at the drop of a hat whenever they had some crazy idea about changing the network architecture.
I can see how "machine-id" might have seemed like a great idea to work around problems with licensing based on components that can be replaced but the proponents of that file completely missed the privacy aspect (or didn't care). What's wrong with the host ID?
Re: that is only for privacy-fags (Score:3)
CA lost a customer and a several thousand dollers a year. always wonder how many other customers they lost over their stupidity.
Re:The systemd-assholes strike again (Score:2)
Re:The systemd-assholes strike again (Score:2)
Furthermore, the brain-numbingly overwhelming majority of linux installations on the earth do not use dbus.
Of course- that's because they're not desktop installations.
The quality of the systemd cheerleaders really has gone downhill.
Re:The systemd-assholes strike again (Score:2)
Re:The systemd-assholes strike again (Score:2)
Re:The systemd-assholes strike again (Score:2)
And arrogant in addition. Fits. I bet you are not even capable of understanding why your comment was completely stupid.
Re:The systemd-assholes strike again (Score:2)
Re:The systemd-assholes strike again (Score:2)
Ah, no. You are not capable of understanding my thought processes. Try again.
Re:The systemd-assholes strike again (Score:2)
Re:The systemd-assholes strike again (Score:2)
There have been attempts at moving portions of it into the kernel for performance reasons, but they have all fizzled.
Re:The systemd-assholes strike again (Score:2)
Hmm. Must have confused something there, I though there was already an option in the kernel. Oh, well, no matter, I don't use any software that uses it anyways and I do not start the demon either.
Anyways, thanks for the info.
Re:privacy, shmivacy (Score:2)
Well, if you've got the equipment you could just log all traffic over the ISP link. Unless, of course, you've got built-in WiFi (Bluetooth too, but that has a sharp distance limit).