Modify kate and plasma-workspace to have an optional dependency for kuserfeedback

kate and plasma-workspace are currently packaged with a requirement for kuserfeedback.

I'm told by KDE that kuserfeedback telemetry is an optional application and is not required to be installed in a distribution.

Would Manjaro consider not installing the package kuserfeedback by default and change the kuserfeedback to an optional dependency of kate and plasma-workspace.

Are inherited from Arch Linux, packaged by Arch ... By default User Feedback is disabled.


As @bogdancovaciu pointed out, those packages aren't managed by Manjaro but come in from upstream Arch. The changes would need to be made there.

That being said, why should this change be made?

The telemetry is off by default and if you look at what data is being written locally is very minimal and not really much different than all the other data your DE writes to your local drive.

There is a lot of internet FUD and alarmism over this but I haven't seen anyone demonstrate any any actual data leakage or other issues caused by this. People seem to not like it simply because it is part of the telemetry subsystem.

I want to be clear, I am avid privacy supporter and don't like any kind of telemetry or tracking but I have investigated what is being written when telemetry is off and it is extremely minor. More importantly, it doesn't get sent anywhere so it stays private.

1 Like

There is maybe a distinction that need to be done .
Is it optional at build time.. meaning you can "disable" it at built time and then don't need it.. but can't use it at all..

Or really "optional" in the sense is "modulable" And have it has and optional dependency.

With the statement you stay we can't be sure..

"There are known knowns.
There are known unknowns.
There are unknown unknowns."

Currently there appears to be two parts: the collection of user data and push-surveys.

Manjaro is used by multiple user types. And some of those users may work in sensitive environments: Work, Nonprofits, Legal, Auditors, Research, Scientific.

No KDE user is alienated if kuserfeedback telemetry is an optional package. response has been that the software itself is optional and that the System Setting is disabled/off by default. If it is installed at all, it is how the distribution chose to set it up.

If one errs on the side of privacy/security, the best solution, where everyone wins, is to make the installation of kuserfeedback telemetry itself optional. And according to, that is at the discretion of the distribution.

The wonderful thing for, there is a solution already available to them: Online surveys at This is an option for kde to obtain user feedback and get "data necessary to answer specific questions". This is a non-invasive method that a user can use that benefits that doesn't negatively impact users in any potential way. In addition, users can vote at and provide feedback at or participate in discussions on the kde community email list.


Some of the issues, but not limited, are:

It isn't just KDE Plasma, it is every KDE QT application that implements the API.

There is a world of difference between "off by default" and "installed as a requirement", as it is currently being distributed. The later burdens the user with the constant task of watching and taking preventative actions, and the consumption of computer resources. The former is freedom from concern and time saved, and no computer resources being used. Typically telemetry once added increases.

Data is stored in plain text.

All programs can access the information.

Some program could potentially use the data without permission.

Data is not managed. Does the database(s) continue to grow. When does data get removed. Looking forward towards Manjaro's rolling release, however, KDE may make it more difficult because there are already locations with orphaned and duplicated data.

Computer resources are used (memory, cpu, storage), even if disabled. If not installed it is just a check.

Every KDE application that incorporates the kuserfeedback telemetry API will have additional overhead (instantiate an object) to setup, track, and communicate with the application chosen datasource. Applications "are not bound by the KDE telemetry policy".

"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."

There is nothing stopping our contacts or other data characteristics from being captured and transmitted, some of this information can be client data or other sensitive data.

Time will be consumed to review and compare Privacy Policy for changes.

Every application, before every update, will have to be checked to verify how it uses the API. API, itself, will have to be checked.

Will surveys be pushed. How will surveys be offered. Will they interrupt the user. How will users be "encouraged ... to contribute in the first place". Every KDE application could potentially display "encouragement message" after so many starts.

If surveys are targeted based on telemetry data, how is a machine identified.

Not everyone uses most recently used (MRU) lists. There are GUI applications that have worked with individuals, in specific professions, to make their application more private/secure by not retaining a most recently used (MRU) files or thumbnails. Plain Emacs, Vim, Nano, do not have or do not have by default MRU lists. I personally do not use MRU lists. Most projects are organized in a tree hierachy and most GUI editors have a tree view. Kate has a plugin Document Tree View. No need for MRU's. In KDE, if there isn't a setting, I remove the files.

Current settings are not obeyed by all applications: Setting > Workspace Behavior > Activities > Privacy > Keep History: Can't set to 0 & > Remember opened documents: Do not remember

For completeness, some work arounds:

.noop library stub ??

. Clear sql tables
cd $HOME/.local/share/kactivitymanagerd/resources/
sqlite3 database <<EOF
delete from ResourceEvent ;
delete from ResourceScoreCache ;
delete from ResourceInfo ;

If you don't mind your menu losing Favorites, just delete database.
There are other data sources.

. Firewall

. /etc/hosts

. For completeness, another desktop, like XFCE or Trinity, but I want to stay focused on KDE and my chosen distribution.

There are valid beliefs when it comes to privacy/security, as described here.

If you need additional information, details, just let me know.

Did you raise your concerns with the Arch Linux package maintainers for those packages?

I wanted to do some more testing, so I got a fellow linux user to help :slight_smile:

I went to archlinux packages and entered kate and selected kate in the Extra repo. On the upper right, I selected source files.

In git, I backed up from svntogit-packages/trunk/ to svntogit-packages/ and selected the Code button. I grabbed the url and ran:

git clone

I entered the trunk directory for both kate and plasma-workspace and modified the PKGBUILD file to remove kuserfeedback as a runtime dependency.

For example:

depends=(knewstuff ktexteditor threadweaver kactivities hicolor-icon-theme)
optdepends=('kuserfeedback: test'

I then ran

makepkg --skippgcheck

I went to a virtual terminal and changed to, installed kate and plasma-workspace, and rebooted. Everything seemed fined. I again went to a virtual terminal and uninstalled kuserfeedback and rebooted. This time plasma did not start. I started them from konsole, and both kate and plasma-workspace got an error complaining about

In the PKGBUILD filed the build is simply:

cmake -B build -S $pkgbase-$pkgver
cmake --build build

Snippet of kate/CMakeLists.txt file:

# optional KUserFeedback integration
if (TARGET KUserFeedbackWidgets)
target_link_libraries(kate-lib PUBLIC UserFeedbackWidgets)
target_compile_definitions(kate-lib PUBLIC -DWITH_KUSERFEEDBACK)

  • I don't know how KUserFeedbackWidgets gets set.

If the above procedure is incorrect (to get the source), let me know. When I find out more, I'll update.

Because you still had KUserFeedback installed when you built the kate and plasma-workspace packages, unless you built them in a clean chroot.

It seems it's this then.. optional at build time and won't be able to use it at all.
The the distro can effectively disable kuserfeedback (it's optional) but can't let the final user choose.

Forum kindly sponsored by