KDE Plasma 5.18 has just joined the growing band of “telemetry collectors”, with the deployment of “KUserFeedback” which is a “Framework for collecting feedback from application users via telemetry and targeted surveys.” It was rolled out to TW users with 20200229.
When disabled (from System Settings -> User Feedback) it seems that (limited?) telemetry data is still collected in files located at “~/.config/kde.org/” with names of the form "UserFeedback.org.kde.‘module name’.conf.
For example “ApplicationStartCount”, “ApplicationTime”, and the rather intriguingly named “LastEncouragement” date/time stamp…
Sigh. I really hope those who choose to not opt in aren’t subject to periodic “Encouragement” nags… (How to lose trust and alienate your user base).
Data is submitted to “telemetry.kde.org” so for those who don’t entirely trust kde, one could add “127.0.0.1 telemetry.kde.org” to “/etc/hosts” …
Unfortunately it’s also impossible to completely remove the telemetry without recompiling at least parts of KDE as they are required as shared libraries.
If you install KDE from the repos containing the latest version, the following packages will also get installed:
I don’t like the idea either, but … KDE eV is German, and hence has to stick to GDPR, which means that opt-in should be default and nothing may be collected without that.
Maybe, but once you lost trust in the product/producer one gets paranoia and wants to be sure to have it switched off/blocked technicaly on ones systems. I have no doubt people will come up with the way how to frustrate this.
As I wrote in the initial post, it is opt-in, with the default setting for userfeedback of disabled.
Although, even when disabled, some telemetry data is stored locally: number of times an application is started and the duration the application is open, but that data is not submitted to kde until user feedback is enabled.
At the moment there doesn’t appear to be any way of preventing the local storage…
This is still in the early stage of development, at the moment very few kde applications are utilising it. Here’s a quite descriptive post by Christoph Cullmann:
describing how telemetry will be implemented in “kate”
I’m not overly keen on the idea myself, and have currently left userfeedback disabled.
Again, as I wrote earlier, if one really doesn’t want to submit telemetry data and doesn’t entirely trust kde, then add “127.0.0.1 telemetry.kde.org” to one’s hosts file…
It seems that, initially, they’re concentrating on:
How many users?
Which platform?
Multi-Screen?
Time spent per session?
In the case of Kate, is the thing being used – if at all – for serious software development – sessions last a long time – or, intermittently – system administration tasks?
[HR][/HR]Yes, for someone maintaining an Open Source package, these statistics are nice to know – “Is my effort worth anything?”.
For anyone offering something, even in a virtual fuzzy world, it’s nice to know if, the effort expended had some value …
I prefer privacy, but the data they’re collecting isn’t attached to a specific user, so I’m not concerned about the disclosure (yet I’m not opting in).
After they start receiving the data, they have a lot of it, some information and hardly any knowledge at all. Start with product-focused questions, then dive down to specific data to collect.
They can collect data about how many Wayland users, but what it really have to say about how many users want to use Wayland? What about those who want to use but it just doesn’t work for them?
And does multi-screen leads to a good experience? Does it take telemetry to fix this couple-year old bug https://bugs.kde.org/show_bug.cgi?id=390503? Which I gather from the source code it wasn’t an issue in kde4.
Is there anything that Kate users would like to perform which isn’t currently possible? Which telemetry data would provide that info?
On a positive note, I like the “Minimalism” section in the Telemetry Policy document. I hope they work towards fulfilling this pledge. As I said, the current questions are so low-level that they’re not adhering to this document, I’m afraid.
Same here. And also very aware that developers have no other way to get the numbers they’re interested in. Not for themselves, but f.e. also towards sponsors.
But,
The applications installed in your phone vs those installed in your laptop/workstation would likely be different (one for core work, the other for personal or mobile work).
The privacy problem with a cell phone, is that it tracks my location. And the cell phone cannot work without tracking my location to at least as close as the nearest cell tower.
The KDE people apparently only want statistical usage information. And that is not as threatening as location information.
Just checked on one of my LXQt machines (default repos, immediately updated),
Neither of those two packages are installed.
So, at least for today LXQt is not implementing the User telemetry described in this thread.
The reason why LXQt can be an alternative is that LXQt is built on the exact same KDE Qt framework, which means that every preferred app that installs on KDE should also be able to install on LXQt with minimal pain. This contrasts with for instance a DE with first preference for Gnome’s GTK framework, those apps would require plenty more packages and perhaps the entire GTK framework to be installed.
Although LXQt installs with its own set of preferred apps, I can envision anyone with a strong dislike for this new KDE telemetry apps might prefer to run LXQt instead with any favorite KDE apps and using LXQt substitutes. Of course, if you install an app that requires telemetry, it will pull in those telemetry libraries and related functionality.
Every person can evaluate whether it’s something important and how important.
And, this seems to be early so it’s unknown which apps will want to gather that information and how intrusive it might become.
KDE doesn’t ordinarily run on a phone today (unless you’re using a Pine phone).
…