Telemetry Policy

[Volker Krause]

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
- hosted on KDE infrastructure
- Kexi seems to (optionally?) contain a unique identifier

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170816/e42b00d3/attachment.sig>