Summary: | Violation of KDE Software Privacy Policy | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kuserfeedback | Reporter: | gvgeo <Gvgeo> |
Component: | Telemetry Provider | Assignee: | Volker Krause <vkrause> |
Status: | CLOSED NOT A BUG | ||
Severity: | normal | CC: | 4wy78uwh, ahjolinna, kde, lq1prs+2rm8s1mam7fmjxo0ka2, nate, postix |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
URL: | https://bugzilla.opensuse.org/show_bug.cgi?id=1191806 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
gvgeo
2020-03-18 08:48:20 UTC
This is no different from storing window sizes, recent documents, etc. (In reply to Kai Uwe Broulik from comment #1) > This is no different from storing window sizes, recent documents, etc. I really hope that is different. I really do hope that this info is not uploaded to kde. With the close reason been fundamentally wrong, equalizing telemetry data with configuration properties, and no response, I don't see any reason for this bug to stay closed. Moreover, the given reasoning is not making any sense, as it does not address this bug or the problems created from it; 1. The bug describes exact steps which show, software collecting data that are not needed to function. In contrast to essential properties. 2. Data that are collected while telemetry is 'disabled', are retained and used as telemetry data, if and when user chooses to enable the corresponding telemetry level. The same occurs if a user chooses to stop telemetry for a while; data usage will continue to collected, and will be included when the user raise back telemetry level. Neither of these 2 issues were addressed. They break privacy policy and user expectations, with the potential to hurt kde image(especially the way you are handling it), and the second can create inaccurate data. I'm having a hard time understanding the issue here. You're concerned that while the telemetry system is on, data is still stored locally--even though it's not sent anywhere unless the user opts into that? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! There is no on or off, feedback always collects data locally. The issue is that privacy policy says that software does not do that. It's essentially impossible to not collect at least *some* information locally or else key features of the system break. For example a window's last size is technically locally collected information for the purpose of remembering your preferred window sizes, yet this has been done for years, even decades. Same with recently-opened files, recently-opened apps, and so on. Nobody has ever complained about this. Perhaps we should amend the policy to reflect this (entirely benign) reality. The policy is meant to be about data shared with KDE, ie. data actually sent to the telemetry server, not about what applications do locally. If that is unclear anywhere in the wording we can certainly improve/clarify that. You would be surprised to learn the amount of information that is collected in /var/log, including information which user started which application at what point in time. And no, not by KDE software, but by the Linux base system. As it is, the word "collects" is confusing, as the software collects data locally. "As a general rule, software produced by the KDE Community does not collect, transmit or otherwise transfer information from end-users devices except as a result of an explicit user action." https://kde.org/privacypolicy-apps.php This would also solve typically the issue of uploading previously collected data. Yet I feel it is wrong without clearing the data or something, when the user selects the corresponding telemetry. And please don't compare local data with telemetry data, that is not right. "The policy is meant to be about data shared with KDE, ie. data actually sent to the telemetry server, not about what applications do locally. If that is unclear anywhere in the wording we can certainly improve/clarify that." You can improve the config files instead by counting down instead of up and naming the fields appropriately: ApplicationTimeUntilEncouragement=... ApplicationStartCountUntilEncouragement=... When either of the fields reaches zero, display the encouragement and replace both fields with: EncouragementShown=true Or even better yet, don't use timed encouragements and simply display them at first start (like Firefox and Atom do). what is the current status? as kuserfeedback has been disabled at least on openSUSE for past 7 months now (don't know about other distros) https://build.opensuse.org/request/show/872116 https://build.opensuse.org/package/view_file/KDE:Unstable:Frameworks/plasma5-workspace/plasma5-workspace.spec?expand=1 Not a bug; saving local data that isn't sent anywhere isn't telemetry, it's how your system remembers state and settings. New bug report, because this was locked without addressing the problem. https://bugs.kde.org/show_bug.cgi?id=466888 |