Telemetry Policy

Wed Aug 16 19:35:59 BST 2017

On 16 August 2017 at 18:56, Volker Krause <vkrause at kde.org> wrote:

> On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote:
> > On 16 August 2017 at 14:13, Volker Krause <vkrause at kde.org> wrote:
> > > On Wednesday, 16 August 2017 09:33:02 CEST Valorie Zimmerman wrote:
> > > > Hi all, Mozilla has done a lot of work on telemetry, and we might be
> > > > able to use some of their findings. On this page:
> > > > https://wiki.mozilla.org/Firefox/Data_Collection they break down the
> > > > data they might possibly collect into four buckets - technical (such
> > > > as crashes), user interaction, web activity, and sensitive (personal
> > > > data).
> > >
> > > without making it that explicit, we basically have the same four
> > > categories of
> > > data too, and explicitly exclude the use of category 3 and 4, ie user
> > > content/
> > > activity and personal data, only technical and interaction data are
> > > allowed to
> > > be used (category 1 and 2).
> > >
> > > > This bit might be relevant to our discussion: "Categories 1 & 2
> > > > (Technical & Interaction data)
> > > > Pre-Release & Release: Data may default on, provided the data is
> > > > exclusively in these categories (it cannot be in any other category).
> > > > In Release, an opt-out must be available for most types of Technical
> > > > and Interaction data. "
> > > >
> > > > I think the entire page might be enlightening to this discussion. I
> > > > believe our analysis of needs should be more fine-grained, and that
> > > > some parts of what we need can be "default on" especially for
> > > > pre-release testing. For releases, we can provide an opt-out.
> > > >
> > > > Other more sensitive data will need to be opt-in. I think it's a
> > > > mistake to treat all the data we might want all in the same way.
> > >
> > > This again brings up opt-out, which so far doesn't seem to have a
> chance
> > > for
> > > consensus. Can we defer this to when we have some more experience with
> the
> > > opt-in approach and how much participation we get with that? Or are
> people
> > > feeling this would too strongly limit what they are allowed to do in
> their
> > > applications?
> >
> > In addition maybe distributors can 
> > 
> > sometimes make the decision based on opinions from given subprojects.
> > For example
> > the option would be pre-set to ON in KEXI's installer for Mac and
> Windows
> > itself and for Linux AppImages, not in the source code.
> > Just saying, KEXI has not yet switched to the new framework :)
>
> The policy we are discussing here is (and is supposed to be) independent of
> the implementation. And that's not just theoretical, Kexi is one prominent
> case for an alternative implementation, and the Krita GSoC also seems to
> contain some alternative server code for example. So input in particular
> from
> those teams matters a lot for me, as this policy in its current form would
> affect them too.
>
> And a policy we only adhere in code and work around in the end by putting
> on a
> distributor hat (which we can in many places, as your examples show) isn't
> really helping, I'd much rather have it reflect what we actually do :)
>
> From having read the code of both, I think the only possible points of
> conflict with the policy draft might be:
> - opt-in
>

Source code has 100% of opt-in (grep for
'areas(KexiUserFeedbackAgent::NoAreas)'). Anyone is free to change this
default and create distribution under his name and I understand this will
not be a "distribution by KDE".

> - hosted on KDE infrastructure
>

My assumption: As KEXI is an open-core+whatever-license-for-plugins
architecture, ultimately the telemetry information from KEXI users would be
better hosted by KDE. Any extra information retrieved by plugins (if that
even exists) can be hosted elsewhere but and this is a responsibility of
plugin developers.

> - Kexi seems to (optionally?) contain a unique identifier
>

This is mostly related to cases when any kind of cloud storage is used.
These cases involve unique accounts already so users can be identified very
well even without having telemetry functionality.

KEXI installations limited to open-core, used away from a cloud, do not
need identifiers.
However I understand that identifiers, independent of network or host ID
(basically a random-generated QUuids) are useful for even basic telemetry
needs. Without them it's easy to abuse the system using any kind of bots to
trick us that e.g. 99% of sessions happen on KDE 1.0 or that given Linux
distro has 90% of the global market :)

Similarly app projects may need the IDs to answer question about most and
least used features. Most used as in "most users found it, understood it
and use it", not "most usage reports has been delivered for it (maybe
coming from a single user -- maybe even my very own co-developer). There
are many other examples probably already discussed.

Thus I would see the Anonymity is covered by KEXI's approach except that it
offers opt-in tracking of unique user for unique installations. KEXI
currently does not track unique installations at all until the user agrees
for any telemetry (the KexiUserFeedbackAgent::AnonymousIdentificationArea
value). This is required by nature of stats computed (and abuses mentioned
above are the reason).

Is this a big deal? We're close to philosophy area here. Before designing
the stats engine I guessed: not more than installing an email app or buying
a SIM card and starting to use them; they allow me to send email or make a
call using protocols that disclose quite a bit about me. I would respect
users that disagree with that but they are unlikely to become KEXI users.
For in my book anonymous users less likely receive support from me in the
MLs or forums.

> Regards,
> Volker
>
> > > Seeing yesterday's blog from the Krita team (
> https://akapust1n.github.io/
> > > 2017-08-15-sixth-blog-gsoc-2017/), I'd particularly be interested in
> their
> > > view on this.
> > >
> > > Regards,
> > > Volker
> > >
> > > > On Sun, Aug 13, 2017 at 3:18 AM, Christian Loosli
> > > >
> > > > <christian.loosli at fuchsnet.ch> wrote:
> > > > > Hi,
> > > > >
> > > > > thank you very much for this work, sounds great!
> > > > >
> > > > > Only point I have: maybe make sure that the opt-in / default
> settings
> > >
> > > are
> > >
> > > > > not only mandatory for application developers, but also for
> packagers
> > > > > /
> > > > > distributions.
> > > > >
> > > > > Some distributions have rather questionable views on privacy and by
> > > > > default
> > > > > sent information to third parties, so I would feel much more safe
> if
> > >
> > > they
> > >
> > > > > weren't allowed (in theory) to flick the switch in their package by
> > > > > default to "on" either.
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Christian
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170816/b5f66b49/attachment.htm>