Received-SPF: pass
    (kde.org: 46.4.96.248 is authorized to use 'kde-community-bounces@kde.org' in 'mfrom' identity (mechanism 'mx' matched))
    receiver=mx1.messagingengine.com;
    identity=mailfrom;
    envelope-from="kde-community-bounces@kde.org";
    helo=postbox.kde.org;
    client-ip=46.4.96.248
Received-SPF: Neutral (access neither permitted nor denied) identity=mailfrom;
 client-ip=85.214.75.115; helo=h2670809.stratoserver.net;
 envelope-from=vkrause@kde.org; receiver=kde-community@kde.org 
From: Volker Krause <vkrause@kde.org>
To: kde-community@kde.org
Subject: Re: Telemetry Policy
Date: Wed, 16 Aug 2017 14:13:48 +0200
Message-ID: <1942419.JquqIjZoWq@vkpc19>
Organization: KDE
In-Reply-To: <CACpu024EH1OeDqwL94QK33eq4sCGjKjwedcQDR_PWjprBevzfg@mail.gmail.com>
References: <2048912.XfIJe3ZSdj@vkpc5> <2990543.KVDkBByYO0@minixfox>
 <CACpu024EH1OeDqwL94QK33eq4sCGjKjwedcQDR_PWjprBevzfg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3633370.DIlRsSa6NW";
 micalg="pgp-sha1"; protocol="application/pgp-signature"
Precedence: list
Reply-To: informing about and discussing non-technical community topics
 <kde-community@kde.org>
Errors-To: kde-community-bounces@kde.org
Sender: "kde-community" <kde-community-bounces@kde.org>

--nextPart3633370.DIlRsSa6NW
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

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? 

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


--nextPart3633370.DIlRsSa6NW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCWZQ2/AAKCRB/lszWTRLS
R+niAKCpVjpRVPq455bnZlAVxpARkGWE/gCcCaBN1QAFz8Da6XIKJGY7iukaS3A=
=ZSiq
-----END PGP SIGNATURE-----

--nextPart3633370.DIlRsSa6NW--