Summary: | I see you're already losing users' trust over this... Here are some suggestions. | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kuserfeedback | Reporter: | Someone Concerned <lq1prs+2rm8s1mam7fmjxo0ka2> |
Component: | Telemetry Provider | Assignee: | Volker Krause <vkrause> |
Status: | RESOLVED NOT A BUG | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | All | ||
Latest Commit: | Version Fixed In: |
Description
Someone Concerned
2020-08-05 18:54:23 UTC
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. |