Re: Telemetry Policy - Remaining Questions

[Jaroslaw Staniek]

On 31 October 2017 at 11:56, Sebastian Kügler  wrote:
> On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote:
>> On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote:
>> > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause
>> > va
>> > > 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.
>>
>> > I'm confused, is that a workaround so that it doesn't apply to Kexi
>> > by implying Kexi isn't released by KDE?
>>
>> That sounds a bit convoluted to me, I was more thinking about making
>> it a direct exception to the policy, e.g. like this:
>>
>> "These rules apply to all products released by KDE (with the
>> exception of Kexi, which uses a telemetry system predating this
>> policy)."
>
> This will make the communication downright awful, as people will
> concentrate on the exception, not the rule.
>

I am sure energy would be concentrated on exception and
nonconstructive activities (from 3rd parties?) because... please read
below:

> I'm thinking along the lines of require code released by KDE to adopt
> the policy and even add it to the manifesto as requirement to make it
> easier to enforce. Kexi can always make it opt-in, and could be given
> some time to do so before we officially adopt and require this
> telemetry policy.
> Jaroslaw, would that work for you?

because... one thing is apparently missed even in this internal thread:
IIRC Kexi apps have never offered opt-out policy even for anonymous telemetry.
I blogged about that as soon as the feature landed [1].
Users pick level of involvement, zero by default, and telemetry is
presented as a way
for involvement in the project not as a threat.

[1] https://blogs.kde.org/2013/12/09/usage-stats

-- 
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

Re: Telemetry Policy - Remaining Questions

[Sebastian Kügler]

On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote:
> On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote:
> > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause
> > va
> > > 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.
> 
> > I'm confused, is that a workaround so that it doesn't apply to Kexi
> > by implying Kexi isn't released by KDE?
> 
> That sounds a bit convoluted to me, I was more thinking about making
> it a direct exception to the policy, e.g. like this:
> 
> "These rules apply to all products released by KDE (with the
> exception of Kexi, which uses a telemetry system predating this
> policy)."

This will make the communication downright awful, as people will
concentrate on the exception, not the rule.

I'm thinking along the lines of require code released by KDE to adopt
the policy and even add it to the manifesto as requirement to make it
easier to enforce. Kexi can always make it opt-in, and could be given
some time to do so before we officially adopt and require this
telemetry policy.

Jaroslaw, would that work for you?
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Telemetry Policy - Remaining Questions

[Volker Krause]

On Monday, 30 October 2017 11:27:58 CET Jaroslaw Staniek wrote:
> On 30 October 2017 at 09:56, Volker Krause  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.

We can obviously drop the exception as soon as it's no longer necessary. I'm 
not sure I fully understand the proposed implementation, but I do see local 
storage (via cookies or otherwise) as a way to address some of the unique 
identification use-cases, such as aggregating data from the same user.

The comparison to KDE Identity is a bit confusing though, as the objective of 
that is unique identification for authorizing access, which inherently 
conflicts 
with anonymity.

> 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.

Right, we cannot ultimately enforce this due to the free software licenses. 
While we can only ask external distributors to follow the same rules, we are 
also a distributor in a number of cases (Windows, Android, Linux app bundles, 
Neon, etc), and can apply the rules there too.

I agree that there is a communication/marketing aspect to this as well, and a 
policy document is not the right tool for that, especially when things get 
complicated.

Regards,
Volker

> > 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 

Re: Telemetry Policy - Remaining Questions

[Volker Krause]

On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote:
> El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause va
> 
> escriure:
> > 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.
> 
> I'm confused, is that a workaround so that it doesn't apply to Kexi by
> implying Kexi isn't released by KDE?

That sounds a bit convoluted to me, I was more thinking about making it a 
direct exception to the policy, e.g. like this:

"These rules apply to all products released by KDE (with the exception of 
Kexi, which uses a telemetry system predating this policy)."

Regards,
Volker

> > 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?
> > 
> > Regards,
> > Volker
> > 
> > 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



signature.asc
Description: This is a digitally signed message part.