See for instance: - Why is kuserfeedback telemetry a required package ? (https://bbs.archlinux.org/viewtopic.php?id=252844) - KDE Plasma "kuserfeedback" collecting telemetry data even when disabled (https://www.reddit.com/r/kde/comments/f7ojg9/kde_plasma_kuserfeedback_collecting_telemetry/) - KDE Is Censoring Users Reporting Spyware in KDE (https://www.phoronix.com/forums/forum/phoronix/general-discussion/1176049-kde-is-censoring-users-reporting-spyware-in-kde) Here are my suggestions: - Don't censor users, duh... Censorship will only make it worse. - To address the perception of telemetry being mandatory, simply use two shared libraries: an interface library with only pure virtual interfaces, and an optional dynamically-loaded implementation library. This way, users can simply remove the implementation library to ensure that the code for logging and sending telemetry data is physically not present on their computers. - Make it clear that, when user feedback is disabled, usage time and startup count are only used to display delayed notifications by counting backwards instead of forwards and naming the configuration keys appropriately: ApplicationTimeUntilEncouragement = ... ApplicationStartCountUntilEncouragement = ... - For additional transparency, add an option to log every report that's been sent and allow users to review *actual telemetry data* straight from the *application's user feedback configuration dialog*. Field names should ideally be translated into the user's native language. - Even better, add an option to disable automatic reports. This way, users will be able to review telemetry report *before* they get sent and cancel them if they somehow happen to contain personal information. Sure, most people will quickly get tired of reviewing everything, and either re-enable automatic reports or turn user feedback off entirely, but the very fact that such an option exists will *tremendously* increase perceived trustworthiness of KUserFeedback.
I can only comment on this as far as the KUserFeedback framework is concerned (which is what this ticket is reported for), not packaging, use or integration in individual applications, or stuff that happens on some forum somewhere. (1) that's an issue of either a specific application using the framework or its packaging, nothing the framework can influence. (2) seems to refer to #418981 (3) claims something happened on Reddit -> not a framework issue (4) we don't (5) see #420955 (6) there are internal names, changing them will not change anything apart from causing effort better spent elsewhere (7) that exists, there is the "audit log" feature in the framework, see ~/.local/share/<vendor>/<application>/kuserfeedback/audit/*.log. The reference config dialog of the framework also offers UI access to that if data has already been submitted ("View previously submitted data..." link below the list of submitted data). (8) the reference config dialog of the framework offers raw data preview, although a bit hidden (the small icon in the bottom right corner of the list with the human-readable transmitted information) So all of this is either already covered, for different components, or a duplicate of other reports.
I found the original post in the Internet Archive (https://bit.ly/33xZguw), and yeah, somebody found the notification timer, got a tad too suspicious, and jumped to premature conclusions... There's an interesting quote in there though: "[...] No one can resist once they have their fingers in the cookie jar. [...] We'll just be the frogs being brought up to a slow boil. We know this tune, have seen this show many times before. There's always a plan. The time for naivety on this has passed, years ago." You might be tempted to dismiss this person as overly distrustful, but such distrustfullness is actually an extremely healthy attitude to have in this day and age. Look around! Governments and corporations plan to enslave us, exploit us, they dream of replacing us with machines or turning us into mindless cyborg drones! This is secular damnation. We must defend our privacy, remain ever vigilant, and, most important of all, keep dissent and resistance possible. Please don't alienate distrustful people, listen to them instead. (5) "I have tried replacing kuserfeedback with a dummy package on Arch Linux. Plasma simply freezes during startup." "[...] allow us to nuke this thing from orbit." "[...] it's just one little "oopsie" away from behind transmitted wholesale to KDE." - that's what the split library proposal aims to address concerns like this - allow users to remove the code responsible for data logging and transmission from their computers without breaking applications. (6) "there are internal names, changing them will not change anything" - except that these names are a grade A bad rumor material... (7) Nice! The "View previously submitted data..." link should probably be simply disabled rather than hidden in order to make it immediately clear that you'll be able to do so. (8) I meant like manual crash reports. Once a report is generated, a "User Feedback" system tray icon should appear, and the user should be able to click it, review the report, and then either send it or cancel it.
(5) see #420955, this would retain the majority of the telemetry code, at best the submission code could be broken out. So this will bring little gain at a huge extra complexity. IMHO the more viable approach in case of such fundamental concerns is rather to convince a distro to not include KUserFeedback in applications where it's build-time optional, and patch it out from applications where it's not. (7) That could make it more discoverable indeed, let's put that into a separate specific ticket though, so it's not getting lost between the various other points in here. (8) As you said yourself, this is likely going to be way too bothersome to use. If you just have the slightest concerns about participating in that, just don't and disable it. Even the existing sharing controls actually turned out to be overkill, in practice the vast majority of people have this either set to all or nothing, the gain of adding even more fine-grained controls therefore doesn't seem to be worth the effort.
(5) Fair point. (7) Done: https://bugs.kde.org/show_bug.cgi?id=425114 (8) The point of adding an option to review data *before* it's submitted is to increase perceived trustworthiness of KUserFeedback, not to provide any actual protection. Perception != reality, especially when it comes to super-distrustful people whom you've alienated... We need such people more than ever now.