SoylentNews is people
SoylentNews
KDE's Telemetry: The Tip Of The Iceberg?:
Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's implementation of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it without any collateral effects to the system, while other users reported that doing the same in other distros (like Debian 11) results in the complete removal of KDE Plasma! Why force such an implementation, if, as KDE's developers say, it is just an innocuous, privacy-respecting measure?
Coincidence or not, in the past years many popular Linux distributions started rolling out optional telemetry. Then it was the time of computer programs: news broke out in May regarding Audacity, a popular audio editing app, which announced it was starting the use of telemetry. The move was finally pushed back after users revolted against it.
While many point out that the data collection is by opt-in and entirely anonymous, others have found that, even if you don't activate telemetry, data is still collected, using computer resources, registering "apps and boot, number of times used and duration in /home/user/telemetry folder." As such, they argue that, because of the way Linux permissions work, other programs could have access to these log files. KUserFeedback's FAQs page confirms this:
"KUserFeedback is designed to be compliant with KDE Telemetry Policy, which forbids the usage of unique identification. If you are using KUserFeedback outside of the scope of that policy, it's of course possible to add a custom data source generating and transmitting a unique id."
Do any Soylentils have opinions about this, or experiences with it?
(Score: 5, Informative) by Marand on Friday October 01 2021, @09:10AM (10 children)
Yeah, this "aritcle" reads like the same kind of nutjob fearmongering that the Dihydrogen Monoxide - the Invisible Killer [dhmo.org] joke page satirizes.
So what if KDE applications depend on the libkuserfeedback library? That doesn't mean it's automatically using it, just that the library's available for if it's enabled and used. There was a similar outcry because some applications had libsystemd0 as a dependency, because the morons thought that meant they were having systemd "forced on them". No, dumbasses, it just means that application has the ability to interact with systemd if it's available, and those applications kept working just fine without systemd installed.
Furthermore, I just checked a couple KDE applications to see what this awful telemetry actually is, and it's a joke. Some applications have an extra sub-section of their "Settings" area named "User Feedback", and it has sliders for two options: "Contribute Statistics" and "Participate in Surveys". Both default to off and have multiple options ranging from "off" to "give them everything". The setting immediately after "don't share anything", meaning the lowest possible "enabled" setting, says it shares the following:
and the highest in the application I tested says this:
with two more choices in between. They even have a little icon in the corner that you can click and see exactly what it's sending at each level to verify you're not sharing something you don't want to. Each application has different things it can request, but in all cases it defaults to off. This matches what's said in the KDE Telemetry Policy [kde.org], as does the claim that there's no sort of user ID or other identifiable information (like IP addresses) present. The most identifying thing I've seen in any application I've checked is the number of physical displays I have and their resolutions/DPI.
The "article" is even outright false with this part:
No, it's not. I have not enabled the feedback shit in any application and there's no such telemetry folder. That bullshit shouldn't even pass the sniff test, considering nobody stores shit like that directly in $HOME. KDE used to put everything into $HOME/.kde once, long ago, but more recently anything KDE-related follows XDG guidelines and goes into $HOME/.local/ and $HOME/.config/ by default. Dumping shit directly into $HOME is not something that has ever happened with KDE applications. And just to verify, I enabled the user feedback at the lowest level in one application (RSS reader, akregator). ONLY AFTER DOING SO, it created a folder named "kuserfeedback" inside akregator's data location, which means the telemetry log was stored in $HOME/.local/share/akregator/kuserfeedback/. In that directory there's a log file showing exactly what was sent and when.
If you're going to lie, at least try to make it believable.
Oh, and this is just the telemetry nonsense. The second portion of this "article" is making baseless accusations about KDE's non-profit structure and being in bed with Google for data harvesting. Fucking LOL WHAT. That's a major stretch that's completely ignoring the presence of verifiable information. The whole thing reads like conspiracy nutjob fanfic from somebody that had a fever dream that the KDE illuminati wants our data after taking too much of whatever the current popular anti-vax pseudo-science COVID cure of the month is.
This "article" shouldn't have been posted and never should have made it to SN. Its only purpose is fearmongering and a poor attempt at generating rage-bait arguments.
(Score: 2) by Reziac on Friday October 01 2021, @02:13PM
Thanks for the detailed info. I admit I was kinda scratching my head because one of the points made was to check how many people are using which applications and versions, lest they drop support for something still in use. How is that not a user-centric approach?
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by acid andy on Saturday October 02 2021, @03:19AM (1 child)
I take your point. All the same, the direction of travel makes me a little uncomfortable. They obviously want the full data, otherwise they wouldn't have spent time coding options to enable its collection. I remember back when M$ used to ask whether you wanted to share details of your "setup experiences". Look at them now.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 3, Informative) by Marand on Saturday October 02 2021, @05:31AM
Sure, but wanting something if you're willing to give it doesn't mean you only want that and don't get value from anything else. I want someone to give me a billion dollars, but I wouldn't scoff at somebody handing me $100. The idea here is that anything you offer helps them, so share only what you're comfortable with, including nothing. They don't even ask you about it at launch or anything, it's just tucked away in the settings, waiting to be enabled if you choose to. In fact, it's so unobtrusive that I literally had no idea it existed until I started fact-checking this article, because I haven't looked in the settings of any of the relevant applications in a while and they did nothing to even indicate the existence of this new feedback feature. It just sits there waiting in case you want to use it.
To look at it another way, a lot of people use FOSS software and would like to give back, but don't feel qualified to contribute in the normal ways. These kinds of reporting options are presented in a way that lets them do something for a project without putting any pressure on anybody, without being obtrusive or invasive to others.
Also, it doesn't even seem to be the kind of data that leads to bad telemetry-based decision making. Everything I checked just had basic stuff like "how many displays are you using? Do you use this program often? What version and OS are you using?" kind of metrics. That stuff is legitimately useful as a gauge of things like how much focus you should spend on high-DPI or multi-monitor worflows, whether you have enough users on 720p-ish resolutions to be concerned about dialogues being too large by default, and how long you should be willing to support older versions of software. If you have a disproportionately large number of users on Debian stable, you're going to want to keep that in mind when dealing with bug reports and backporting fixes, for example.
Slippery slope fallacy. Just because it's possible to go from A to B doesn't mean that's the only possibility, and the fact that KDE itself built this feature with end-user privacy and choice in mind from the start is a good sign that it won't happen that way just because someone else with completely different motives went that route. Rather than judging their actions based on those of a completely unrelated entity, we should be judging them based on what they did and their own track record in the past. There's no reason to be assuming the worst here when they've done nothing even slightly bad with it so far.
If anything, the way they've done it helps give some measure of trust to the process. If an application is using the official KUserFeedback mechanism you have a reasonable idea of what's going to happen because it all works the same and falls under the same standards. Any KDE application that chooses to not use it and instead provide its own appears shady in comparison, because it indicates they want extra data and less oversight with how it can be used.
Also, it's been done in a way that should make it fairly easy to do an LD override with a stub library if you really want to get rid of it. They aren't hiding it or doing anything remotely like forcing it on people here.
If it starts becoming more forceful, then that is the time to start fighting back, but until then it's about as harmless as it can get.
(Score: 0) by Anonymous Coward on Saturday October 02 2021, @06:03AM (6 children)
>There was a similar outcry because some applications had libsystemd0 as a dependency, because the morons thought that meant they were having systemd "forced on them". No, dumbasses, it just means that application has the ability to interact with systemd if it's available, and those applications kept working just fine without systemd installed.
An installation of either kde or gnome desktop has a hard dependency on either systemd or elogind -- both of which are part of systemd. So right now to even install either one i have two choices: systemd or a part of systemd.
I'm not against systemd, nor I am against such a dependency -- I run it on a few servers. However, the fact remains that systemd is forced on the user (the software *does not* work without some parts of systemd installed, which makes it a hard dependency).
(Score: 3, Interesting) by Marand on Saturday October 02 2021, @10:25AM (5 children)
I don't know if you are familiar with this and remember it, but the outcry I was referring to was when Debian first started defaulting to systemd a few years ago. At the time, not using systemd was as simple as just not installing it and sticking with the sysv-init package, but there were still people having ridiculous freak-outs over the fact that some software had some libsystemd dependency listed because they were conflating "software uses a library that makes it compatible with systemd when present" with "OMG SYSTEMD GOT INSTALLED AGAINST MY WISHES WTF THIS IS HORRIBLE". I continued to use Debian systemd-free well past the supposed systemd-apocalype without issue because all those libsystemd dependencies were the same non-issue as the kuserfeedback is: just a library to work with it if it's available.
It was overblown histrionics that did the anti-systemd group (myself included) no favours, because the shrill screeching about a non-issue undermined and obscured better arguments against it. It just made us easier to ignore as a group because a vocal subset at the time was laser-focused on something that literally did not matter (because it wasn't actually systemd being installed); they were helping construct their own strawman arguments for the pro-systemd people to refute. :/
That's what I was talking about in the part you quoted: a very specific situation during the early systemd adoption phase, not the current state of things.
Going a bit off topic:
For what it's worth, I believe it's still possible to go systemd-less on Debian even now, even with KDE or GNOME desktop, but it's slightly less simple than it was. The problem, IIRC, is that some of the higher-level desktop packages like KDE rely on something lower-level (PAM? Not sure) that, in turn, relies on systemd's cgroups management capability. There used to be a shim package that provided that feature, which let everything work simply, but it's not included with Debian anymore so you have to find it from another source. Once you do, though, it's just like before.
I'm still not a fan of systemd, but after systemd-shim got removed from Debian itself I finally gave it a chance. I figured the few years I managed to put it off gave it enough time to mature a bit and get past most of the buggy, broken shit (aka Poettering syndrome) I was avoiding, so I'd let it go a bit before fighting it and going back to sysv-init. At this point it's, well, still not the best but not unusable and has just enough useful features (like systemd-nspawn, which is way more convenient than normal chroot creation) to be worth the headaches in some situations. It also helps that Debian keeps sysv-init helpers around and still retains a high degree of sysv-init compatibility even when it's installed, too: all the /etc/init.d/ scripts are still there and runnable so my muscle memory still works, logging's still in the usual files, etc.
(Score: 2) by Reziac on Sunday October 03 2021, @01:16AM (4 children)
PCLOS does not use systemd but KDE is our flagship desktop... apparently whatever dependency exists can still be worked around.
I don't have a hard stance either way; when I was using Fedora, systemd never gave me any grief and was sometimes convenient, but I also grok the problem of too many tentacles. Just happenstance that I prefer a distro without it, for other reasons entirely. If we had to switch to systemd, I'd shrug and keep using PCLOS.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 3, Interesting) by Marand on Sunday October 03 2021, @02:57AM (3 children)
Yeah, and I've heard that even GNOME can still work without it, though they've tried to make it a hard dependency so I don't know how that works out in practice.
Aside from that, the main issue is needing a shim to deal with the cgroups stuff because something lower in the stack than KDE itself relies on that functionality, so distros like Debian have it listed as a dependency. However, it's still possible to provide that functionality without it (that's what systemd-shim does), and any package system today should (well, .deb does at least) offer a way to say "this other package here also provides this feature". With .deb it's the "Provides:" field, which is how systemd-shim works at a package level: it claims it provides the same feature as the other package, making itself an alternative that satisfies the dependency tree so nothing gets removed when you swap systemd out for it.
The problem if you want to do that for Debian right now is that it's not part of the repos any more, so you have to find a third-party repo that's still maintaining it. There are some around, but I haven't bothered to do it myself so I don't want to name any because I don't know offhand what's current and trustworthy.
Though, it's worth noting that one distinction between GNOME and KDE with regard to systemd is that KDE still tries to be relatively init-agnostic and capable of working on other OSes like the BSDs, whereas GNOME (or perhaps more accurately, Redhat) has, as I briefly mentioned above, doubled down on absorbing the entire software stack and treating it as a single entity under their purview. GNOME devs have been obsessed with branding and the idea of a "GNOME OS" where they control everything. They don't really care about whether GNOME works on BSDs, or with non-GNOME applications, or anything that isn't GNOME, and are actively hostile to interopability with others.
One of the reasons systemd adoption happened the way it did, and as quickly as it did, was because GNOME took a hard stance on "use systemd or fuck off" as part of its GNOME OS vision. Distros were faced with a choice of "remove or maybe even fork GNOME, or use systemd" which helped push people toward systemd that were on the fence; I remember the Debian discussion over systemd adoption being brigaded by GNOME folks who attempted to (and succeeded at) swaying the decision.
That's more or less where I'm at with it right now. Initially I didn't want to deal with it because, in addition to technical complaints about its design, it was still too buggy and unreliable. I don't want my system crashing or failing to boot because an overly-ambitious PID 1 fails to work properly.
I still think it's too ambitious, tries to do too many things, and makes it more likely PID1's going to explode as a result, but I waited long enough that most of the problems got ironed out. Since then, most of my issues haven't been with systemd-the-init, it's been with other parts outside of that. Like having five minutes added to bootup and shutdown every time because my network was configured through /etc/network/interfaces, so systemd's networking bullshit would sit there for five minutes waiting on shit it had no control over every time, despite having the timeout for it set to like 5s which was supposed to fix that problem. The solution, according to everyone: "just give systemd what it wants, stop configuring your network that way". No, fuck you random internet guy, that's precisely why people get pissed about systemd's feature creep.
For what it's worth, I eventually got that mostly dealt with somehow, but it's an example of the kind of weird tangential breakage that still occurs. But luckily the init itself has been pretty stable, at least once it had some time to mature and everyone else did free beta testing for a few years before I switched :)
That's what happened with me and Debian. They kept the shim around long enough that I didn't have to deal with the rough edges, so rather than make extra work for myself fighting to keep it removed, I shrugged and gave it a shot, knowing I could still go back to being systemd-free if I needed. So far, I haven't, but the option's still on the table if I change my mind.
That's why I use Debian and tend to stick to the stable repo. It's conservative about pushing major changes on people, and even now it continues to work with people that don't want to use systemd, still providing alternate inits and desktop options that don't need it. Though, like with anything else, some choices may restrict availability of some software on the system. But despite making systemd the default, they still provide sysv-init rc files, other init systems, etc. in an effort to provide choice instead of forcing one solution on everyone. Sure, it gets new software and feature updates of stuff slower than Ubuntu or Arch, but I don't care. I want most of my system to be boring and unchanging; the few things I want newer I can compile myself or get from another source, like nixpkgs, a third-party repo, or I can use an appimage or flatpak.
(Score: 2) by Reziac on Sunday October 03 2021, @04:06AM (2 children)
Heh, totally agreed on the value of the boring system. Mine take a while to mature, then remain set in stone for years, because I bloody want them that way, dammit! PCLOS is pretty much a one-man band, so it gets whatever pleases the maintainer. But for the most part that's choices I find agreeable, and we're generally pretty much up-to-date, not that I'd especially care (my main box still runs XP!)
Hadn't heard about Gnome playing little tin god, but it gives me hives and makes me long for Windows 10, and mostly I avoid it (when I'm touring new distros, I don't even bother looking at the Gnome-centric). If a person has to be in that ecosystem, well, that's why we have Mate. KDE is sufficiently agnostic to build K-apps for other platforms; somehow I can't imagine Gnome doing that.
I don't really have anything intelligent to add, but thanks for all the info, made for an interesting read.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 4, Interesting) by Marand on Sunday October 03 2021, @02:15PM (1 child)
Worse: they're playing at being Apple.
It's nothing new, though, this shit has been happening slowly since GNOME 3 first appeared, and like I said it's not just GNOME, it seems to be a common view of things from various Redhat people. Poettering has written before, long ago, about wanting to basically destroy the concept of Linux distributions by creating a standard Linux core that's the same for every Linux user, so that distros have no value. Systemd brings Linux part of the way there because, in a way, it's a lot like how BSDs have a central chunk of software that gets updated in lockstep and acts as the core OS, with extra software provided outside of that in some form. That's precisely what systemd is, just for Linux, though it's still handled by distros which is undesirable (to him). The talk about GNOME, branding, and unified look and feel has been happening as long as GNOME 3 has been around, too, and keeps coming up in various ways. They don't care about breaking extensions because, since extensions mess with the GNOME L&F, breaking them is a good thing, and every so often talk about making extensions impossible so that GNOME can't be moved away from their vision happens Same with themes, and now there's some more drama with that because they decided to merge their Human Interface Guidelines library (libhandy) with their UI theme (adwaita) into a single library, libadwaita, that enforces theming and makes it non-modifiable for GNOME applications.
Non-GNOME Gtk applications can still do CSS themes when that change hits, but it means using GNOME applications on, say, KDE is probably going to look even more out of place unless something changes there. It's even led to some GNOME-adjacent DEs looking into alternatives, like Solus with their Budgie desktop, because they're losing the ability to theme their applications while also following GNOME HIG for consistency. So they gave up and decided to rewrite for Enlightenment instead of moving to Gtk 4.
Gtk used to just be a general FOSS toolkit, back when it was the Gimp Toolkit, and even past that for a while when it was Gtk+, but ever since Gtk3 it's basically been the "GNOME Toolkit" in all but name: the tail wags the dog and everyone else has to live with it. You can tell they share devs, too, because they both have the same asshole NOTABUG WONTFIX attitude toward anyone outside of GNOME having issues or reporting bugs. When Gtk3 was newer, MyPaint (an infinite canvas art program) devs ported it to Gtk3 and it had some horrible bugs with pressure-sensitive pens because they removed the Gtk2 menu configuration in favour of auto-configuration that "does the right thing". Since MyPaint was basically the first project to actually use this stuff, it uncovered some fun bugs, and I remember how Gtk devs handled it. I reported a bug to MyPaint, we confirmed it was an issue for others and not just something weird with me, figured out where the problem was and how to repeat it, and the MyPaint devs took the bug to Gtk because it was a Gtk problem. Gtk dev immediately declared it "not a bug" with barely a glance, told the MyPaint devs their program was wrong, and ignored it. Then like six months later, a GNOME program hits the same bug, reports it, and suddenly it's a bug now and worth fixing. That showed me what dealing with GNOME and Gtk is like, and I've avoided interacting with them since.
You'd think as difficult as dealing with Gtk and GNOME is, people would jump ship. They keep breaking things for their own benefit and treating non-GNOME projects like second-class citizens (including one terminal, roxterm, being abandoned for years over annoyance at their treatment), but people keep putting up with it because it just kind of sucks to use other stuff. A big part of why it's tolerated is because it's made in C, which makes bindings for various languages easier and thus ubiquitous. Qt and KDE have a better user experience, but Qt's entire toolchain and the fact that it uses C++ makes providing bindings for other languages a pain in the ass, so there aren't bindings for many languages and they tend to be massively outdated and often broken. As a result, it gets a lot less use outside of dedicated "I want to make KDE software" devs or proprietary devs that license it from the Qt Company. Similar issue for wxWidgets, which is also C++, except it doesn't even have the KDE angle going for it so it has even fewer language bindings than Qt usually.
So Gtk gets used despite it and GNOME pissing everyone off just because it's the easier option to deal with unless you want to use C++.
(Score: 2) by Reziac on Sunday October 03 2021, @04:28PM
I remember the uproar about how Gnome3 utterly ignored what users want and you will like it or else, but by then I'd stopped paying much attention to what they did. And when I did check out the shiny new Gnome3, it was everything I hate about cellphones, Win10, and MacOS, all in one handy package!
However, what you say explains a lot. I noticed a long time ago that Gtk apps frequently would not play nice with system settings, were my-way-or-the-highway, and whatever bugs they had went on forever; meanwhile, Qt apps gracefully adapted to user preferences, and bugs seemed to go away before I could get around to reporting them. And that generally speaking, Gtk apps were designed for programmers, while Qt apps were designed for users.
Developer attitude matters. The Mozilla codebase has NOTABUG WONTFIX issues that go back over 15 years, and despite reams of reproducible bug reports, for those of us who are not coders it's just tough shit.
BTW thanks for reminding me about MyPaint, which I had somehow completely forgotten exists.
And there is no Alkibiades to come back and save us from ourselves.