"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.
kde.org 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 kde.org, that is at the discretion of the distribution.
The wonderful thing for kde.org, there is a solution already available to them: Online surveys at kde.org. 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 kde.org that doesn't negatively impact users in any potential way. In addition, users can vote at bugs.kde.org and provide feedback at forum.kde.org 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.
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
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.
. 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.