On 30 October 2017 at 09:56, Volker Krause <vkra...@kde.org> wrote: > Let's try to finally get this finished :) > > The only remaining blocker is the unique identification used by Kexi. There > was > some discussion about this around QtWS, and it seemed like there was consensus > on having a strong policy on this topic would be a good thing for KDE, as > opposed to e.g. turning this into just recommendations, or opening it up to > unique identification. The suggested solution for Kexi was to add a special > exception for it to the "These rules apply to all products released by KDE." > statement of the policy. > > That would still leave us with a strong policy on this subject, while solving > the conflict with Kexi's current way of collecting telemetry. Would that work > for everyone?
Hello Thanks for pushing this forward Volker. In the meantime I got an inspired idea to behave no different than KDE web browsers do with unique cookies e.g. wrt the KDE Identity accounts. Namely there would be zero logic for IDs in Kexi itself but a cookie feature with its standard behavior. As it's the case, it's opt-in. For now I hope this is technically feasible and the result equivalent of the previous solution if not even more flexible. I would appreciate pointing flaws in my assumption. Timeline for that can be connected to development of sign-in features. Unless there is desire to discuss exceptions for a range of KDE software that implements client side for web technologies maybe there is no need for adding specific exception for Kexi or having it communicated by Kexi itself. I'd like to also mention apparent lack of clarity for the outside user wrt what "products released by KDE" mean. What are the defaults in deployed software is a decision of those who deploy the software; legal modifications are allright. KDE "only" releases the source code. So I would not place such a stamp "These rules apply to all products released by KDE" e.g. in About boxes because this has low info value for the actual user or can truly confuse. I am mentioning this here to emphasize that I see telemetry more as a part of the software deployment and support, not a part of the actual "source code product". Decoupling any logic from the source code is part of that. > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: >> Hi, >> >> as not everyone follows long threads, let's start again for the remaining >> issues. >> >> https://community.kde.org/Policies/Telemetry_Policy >> >> The following questions were left unanswered in the previous thread (see >> there for the full arguments if needed): >> >> (1) Should we allow opt-in tracking of unique identifiers? >> >> This was requested by Jaroslaw, as Kexi has this right now and the policy as >> written right now would thus conflict with it. >> >> (2) Should we require/allow/forbid publication of the raw data? >> >> Publication was suggested by Martin F. Practically, this would have to allow >> for a certain delay, we can't have public access to live data. Suitable >> licensing options of the data would probably be CC0 or CC-BY-SA. >> >> (3) Should we require a revocation feature? >> >> That is, allow the user to "delete" the data they submitted from the server. >> This was also suggested by Martin F, and is technically possible without >> compromising anonymity. >> >> (4) Should we define limits on how long we store the raw data? >> >> Brought up by Bhushan. >> >> (5) Should we require an "audit log" feature? >> >> Thas is, allow the user to see a detailed record of what has been submitted >> so far? Martin S suggested this (and it has been meanwhile implemented in >> KUserFeedback). >> >> Not from the previous thread, but from a discussion in Randa: >> (6) What is the "lower bound" of where we consider this policy to apply? >> >> That is, does checking for application updates/news (and possibly tracking >> that on the server) already count as "telemetry" in this context? See e.g. >> the current practice in Akregator or KDevelop. >> >> >> Allowing (1) might conflict with (2) allowing publication, unique >> identification brings us in personal data territory. Publication might also >> conflict with (3) and (4). >> >> So, what's your view on those issues? :) >> >> Thanks! >> Volker > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek