Telemetry Policy - Remaining Questions

Jaroslaw Staniek staniek at kde.org
Wed Apr 4 10:49:48 UTC 2018


On 4 April 2018 at 12:37, Ben Cooksley <bcooksley at kde.org> wrote:

> 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.
>
>
Thanks for the ​thorough info Ben.
I understand that admins of the data (from the legal POV) have the last say.

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


More information about the kde-community mailing list