Telemetry Policy - Remaining Questions

[Jaroslaw Staniek]

On 30 October 2017 at 09:56, Volker Krause <vkrause at 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