Telemetry Policy - Remaining Questions

Ben Cooksley bcooksley at kde.org
Wed Apr 4 11:37:40 BST 2018 

On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek <staniek at kde.org> wrote:
>
>
> On 3 April 2018 at 10:17, Ben Cooksley <bcooksley at kde.org> wrote:
>>
>> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek <staniek at kde.org> wrote:
>> >
>> >
>> > On 2 April 2018 at 22:56, Lydia Pintscher <lydia at kde.org> wrote:
>> >>
>> >> Hey Jaroslaw :)
>> >>
>> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <staniek at kde.org>
>> >> wrote:
>> >> > Thanks for reminding me Lydia
>> >> >
>> >> > I've not forgotten this. While there's progress I do still see this
>> >> > as a
>> >> > pilot stage and do not think we're in a hurry given telemetry is
>> >> > something
>> >> > "extra" for a project development, not a core feature of any product.
>> >>
>> >> We are in a hurry now. We're waiting for projects to be able to start
>> >> using it and get us valuable insights about how our software is used.
>> >> We've been on it since last Akademy. Let's get it finished :)
>> >>
>> >> > Below I am referring to this version:
>> >> >
>> >> >
>> >> > https://community.kde.org/index.php?title=Policies/Telemetry_Policy&oldid=78057
>> >> >
>> >> > tl;dr: Why discussing: Any deep change and limitation to projects'
>> >> > freedom
>> >> > needs to bring substantial benefits over drawbacks. Level of
>> >> > complexity
>> >> > of
>> >> > the contract for a project or individual developer needs to be
>> >> > balanced
>> >> > by
>> >> > real (not hypothetical) benefits.
>> >>
>> >> The benefits here for KDE are:
>> >> * we have a
>> >> better understanding of our userbase leading hopefully to
>> >> better software
>> >> * we have a better understanding of our userbase leading hopefully to
>> >> better marketing
>> >> * we have a clear policy we can point our users to that explains how
>> >> we are handling their data and that is in line with our vision/what we
>> >> stand for.
>> >>
>> >> > I've studied the wiki page more in depth and I have these points
>> >> > where
>> >> > I'd
>> >> > like to see improvement. This is based on my experience, not a list
>> >> > of
>> >> > quick
>> >> > ideas.
>> >> >
>> >> >
>> >> https://community.kde.org/Talk:Policies/Telemetry_Policy#
>> >>
>> >> Thank you! Volker is probably best equipped to answer these.
>> >>
>> >> > That said: I will nod to the concept of "Minimalism", it is all
>> >> > classic
>> >> > property of telemetry. I think I've seen them in other projects too.
>> >> > I'd just say, let's not make all this more limited than anyone wants
>> >> > it
>> >> > to
>> >> > be.
>> >>
>> >> Where is it too limited? Please keep in mind that we've set
>> >> privacy as
>> >> a core part of our vision and the current goals.
>> >
>> >
>> > Lydia,
>>
>> Hi Jaroslaw,
>>
>> > It's a core part but still a part and can't contradict, say, with the
>> > Freedom part.
>> >
>> > Please see the list of limitations:
>> >  https://community.kde.org/Talk:Policies/Telemetry_Policy#
>> > (in my opinion that's not a "nice to haves" but requirements needed so
>> > we
>> > can even call the whole thing "telemetry")
>> >
>> > I am asking for an alternative approaches, Volker once mentioned there
>> > are
>> > some.
>> > We need them to we move forward.
>> >
>> > In the meantime my stack runs just well, people that use IDs are even
>> > given
>> > right to remove their data, something that's *not* going to be possible
>> > with
>> > the proposed vision. Someone would convince me otherwise.
>>
>> Please don't drag our websites ability to have people login to them
>> into your argument here.
>> Cookies as used by websites are quite different to Telemetry on many
>> points.
>
>
> Dear Ben, based on your experience I'd like to hear your voice how web apps
> of any kind are different or are special cases, compared to apps that happen
> to do the same but do not use the "web" stamp so discussed data collection
> features are delegate to 3rd-party clients called web browsers.
> How an OPT-IN ID like 2a7c819f-636c-403e-afa1-c9e37031c1de based on random
> generator[1] is more serious privacy concern than required
> (login+email+password) non-anonymized tuple for web accounts of web apps of
> any kind. Please do not take this as pointing to any core infrastructure, I
> am pointing to specific established technology and practices.

Web applications (as we deploy anyway) are a bit different as the
action of registering, and then logging in, requires specific and
deliberate engagement on the users part while the Opt-In process used
by applications could be as simple as a popup on first startup, or a
checkbox in it's configuration (therefore making the required effort
much lower). If at any point a user is not logged in, we have no idea
who they are until they login (and many of our sites do not send any
cookies until you try logging in)

Additionally, the only information we collect from users is that which
they deliberately enter in (and have therefore chosen to provide to
us). We also don't record any viewing activity on our sites - only
actions which change the site (such as posting a bug, editing a wiki
page or commenting on a code review) are recorded against your profile
(another decision you've had to consciously make). Application
telemetry on the other hand is automatically transmitted, either on a
time running basis or on application startup/shutdown and the user has
limited involvement in the actual information being transmitted.

The only exception to this is our web statistics, which are completely
disconnected from all the login systems, and have sufficient fuzzing
applied at the time of being recorded to be useless for identifying
the user in question (it also respects do not track headers and the
like)

>
> Then do we agree that the purpose of random ID collection is secondary as
> long as both sides know it and agree on the terms of collaboration? And
> even: can pull the data out.
>
> I am calling functional web sites as apps, produced by any KDE projects,
> hoping that's not seen as dragging. Please do not look at my concern as a
> criticism towards the web apps because in my opinion apps of any technology
> have right to use anonymized unique IDs at user's consent for purposes
> clearly stated to the user to achieve openly explained goals welcomed by the
> users. Or from a different angle, I see nothing in Freedom that prohibits
> Free projects to offer such features to Free users unconditionally[2].
>
> [1] If separating of independent aspects measured is a concern (e.g. [screen
> size] from [locale]) unique user can have multiple IDs generated, one per
> single analyzed group of aspects, to fully decouple one area from another in
> the raw data (as in example: separating screen size analysis from locale
> analysis).
> [2] Unconditionally == as stated by the Policy point "applications can't tie
> the availability of unrelated aspects of the application to telemetry being
> enabled" that looks good to me and is needed. Applications designed to work
> offline are still 100% functional when run offline right after installation.

I would rather that we do not have any form of unique identifier
associated with the information, due to the GDPR compliance risks it
imposes.

We need to be careful enough as it is with the types of telemetry data
we do collect, as it could still be considered personally identifying
information.
People have already done research into this space - see
https://panopticlick.eff.org/ - therefore careful consideration should
be made as to the device characteristics we do collect.

Regards,
Ben

>
>>
>> Regards,
>> Ben
>>
>> >
>> > --
>> > regards, Jaroslaw Staniek
>> >
>> > KDE:
>> > : A world-wide network of software engineers, artists, writers,
>> > translators
>> > : and facilitators committed to Free Software development -
>> > http://kde.org
>> > KEXI:
>> > : A visual database apps builder - http://calligra.org/kexi
>> >   http://twitter.com/kexi_project https://facebook.com/kexi.project
>> > Qt Certified Specialist:
>> > : http://www.linkedin.com/in/jstaniek
>
>
>
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> KEXI:
> : A visual database apps builder - http://calligra.org/kexi
>   http://twitter.com/kexi_project https://facebook.com/kexi.project
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek

More information about the kde-community mailing list