[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Telemetry Policy - Remaining Questions
From: Jaroslaw Staniek <staniek () kde ! org>
Date: 2018-04-04 10:49:48
Message-ID: CAOj7QQ1edY6zAR8=vkFxfT98iffhsDZr0nPBdgaftN5LTvC_Vg () mail ! gmail ! com
[Download RAW message or body]
On 4 April 2018 at 12:37, Ben Cooksley <bcooksley@kde.org> wrote:
> On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek <staniek@kde.org> wrote:
> >
> >
> > On 3 April 2018 at 10:17, Ben Cooksley <bcooksley@kde.org> wrote:
> >>
> >> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek <staniek@kde.org>
> wrote:
> >> >
> >> >
> >> > On 2 April 2018 at 22:56, Lydia Pintscher <lydia@kde.org> wrote:
> >> >>
> >> >> Hey Jaroslaw :)
> >> >>
> >> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <staniek@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
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_extra"><br><div class="gmail_quote">On 4 April 2018 at 12:37, Ben \
Cooksley <span dir="ltr"><<a href="mailto:bcooksley@kde.org" \
target="_blank">bcooksley@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On \
Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek <<a \
href="mailto:staniek@kde.org">staniek@kde.org</a>> wrote:<br> ><br>
><br>
> On 3 April 2018 at 10:17, Ben Cooksley <<a \
href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>> wrote:<br> >><br>
>> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek <<a \
href="mailto:staniek@kde.org">staniek@kde.org</a>> wrote:<br> >> ><br>
>> ><br>
>> > On 2 April 2018 at 22:56, Lydia Pintscher <<a \
href="mailto:lydia@kde.org">lydia@kde.org</a>> wrote:<br> >> >><br>
>> >> Hey Jaroslaw :)<br>
>> >><br>
>> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <<a \
href="mailto:staniek@kde.org">staniek@kde.org</a>><br> >> >> \
wrote:<br> >> >> > Thanks for reminding me Lydia<br>
>> >> ><br>
>> >> > I've not forgotten this. While there's progress I do \
still see this<br> >> >> > as a<br>
>> >> > pilot stage and do not think we're in a hurry given \
telemetry is<br> >> >> > something<br>
>> >> > "extra" for a project development, not a core \
feature of any product.<br> >> >><br>
>> >> We are in a hurry now. We're waiting for projects to be able to \
start<br> >> >> using it and get us valuable insights about how our \
software is used.<br> >> >> We've been on it since last Akademy. \
Let's get it finished :)<br> >> >><br>
>> >> > Below I am referring to this version:<br>
>> >> ><br>
>> >> ><br>
>> >> > <a \
href="https://community.kde.org/index.php?title=Policies/Telemetry_Policy&oldid=78057" \
rel="noreferrer" target="_blank">https://community.kde.org/<wbr>index.php?title=Policies/<wbr>Telemetry_Policy&oldid=78057</a><br>
>> >> ><br>
>> >> > tl;dr: Why discussing: Any deep change and limitation to \
projects'<br> >> >> > freedom<br>
>> >> > needs to bring substantial benefits over drawbacks. Level \
of<br> >> >> > complexity<br>
>> >> > of<br>
>> >> > the contract for a project or individual developer needs to \
be<br> >> >> > balanced<br>
>> >> > by<br>
>> >> > real (not hypothetical) benefits.<br>
>> >><br>
>> >> The benefits here for KDE are:<br>
>> >> * we have a<br>
>> >> better understanding of our userbase leading hopefully to<br>
>> >> better software<br>
>> >> * we have a better understanding of our userbase leading hopefully \
to<br> >> >> better marketing<br>
>> >> * we have a clear policy we can point our users to that explains \
how<br> >> >> we are handling their data and that is in line with our \
vision/what we<br> >> >> stand for.<br>
>> >><br>
>> >> > I've studied the wiki page more in depth and I have these \
points<br> >> >> > where<br>
>> >> > I'd<br>
>> >> > like to see improvement. This is based on my experience, not a \
list<br> >> >> > of<br>
>> >> > quick<br>
>> >> > ideas.<br>
>> >> ><br>
>> >> ><br>
>> >> <a href="https://community.kde.org/Talk:Policies/Telemetry_Policy#" \
rel="noreferrer" target="_blank">https://community.kde.org/<wbr>Talk:Policies/Telemetry_<wbr>Policy#</a><br>
>> >><br>
>> >> Thank you! Volker is probably best equipped to answer these.<br>
>> >><br>
>> >> > That said: I will nod to the concept of \
"Minimalism", it is all<br> >> >> > classic<br>
>> >> > property of telemetry. I think I've seen them in other \
projects too.<br> >> >> > I'd just say, let's not make all \
this more limited than anyone wants<br> >> >> > it<br>
>> >> > to<br>
>> >> > be.<br>
>> >><br>
>> >> Where is it too limited? Please keep in mind that we've set<br>
>> >> privacy as<br>
>> >> a core part of our vision and the current goals.<br>
>> ><br>
>> ><br>
>> > Lydia,<br>
>><br>
>> Hi Jaroslaw,<br>
>><br>
>> > It's a core part but still a part and can't contradict, say, \
with the<br> >> > Freedom part.<br>
>> ><br>
>> > Please see the list of limitations:<br>
>> > <a href="https://community.kde.org/Talk:Policies/Telemetry_Policy#" \
rel="noreferrer" target="_blank">https://community.kde.org/<wbr>Talk:Policies/Telemetry_<wbr>Policy#</a><br>
>> > (in my opinion that's not a "nice to haves" but \
requirements needed so<br> >> > we<br>
>> > can even call the whole thing "telemetry")<br>
>> ><br>
>> > I am asking for an alternative approaches, Volker once mentioned \
there<br> >> > are<br>
>> > some.<br>
>> > We need them to we move forward.<br>
>> ><br>
>> > In the meantime my stack runs just well, people that use IDs are \
even<br> >> > given<br>
>> > right to remove their data, something that's *not* going to be \
possible<br> >> > with<br>
>> > the proposed vision. Someone would convince me otherwise.<br>
>><br>
>> Please don't drag our websites ability to have people login to them<br>
>> into your argument here.<br>
>> Cookies as used by websites are quite different to Telemetry on many<br>
>> points.<br>
><br>
><br>
> Dear Ben, based on your experience I'd like to hear your voice how web \
apps<br> > of any kind are different or are special cases, compared to apps that \
happen<br> > to do the same but do not use the "web" stamp so discussed \
data collection<br> > features are delegate to 3rd-party clients called web \
browsers.<br> > How an OPT-IN ID like 2a7c819f-636c-403e-afa1-<wbr>c9e37031c1de \
based on random<br> > generator[1] is more serious privacy concern than \
required<br> > (login+email+password) non-anonymized tuple for web accounts of web \
apps of<br> > any kind. Please do not take this as pointing to any core \
infrastructure, I<br> > am pointing to specific established technology and \
practices.<br> <br>
</div></div>Web applications (as we deploy anyway) are a bit different as the<br>
action of registering, and then logging in, requires specific and<br>
deliberate engagement on the users part while the Opt-In process used<br>
by applications could be as simple as a popup on first startup, or a<br>
checkbox in it's configuration (therefore making the required effort<br>
much lower). If at any point a user is not logged in, we have no idea<br>
who they are until they login (and many of our sites do not send any<br>
cookies until you try logging in)<br>
<br>
Additionally, the only information we collect from users is that which<br>
they deliberately enter in (and have therefore chosen to provide to<br>
us). We also don't record any viewing activity on our sites - only<br>
actions which change the site (such as posting a bug, editing a wiki<br>
page or commenting on a code review) are recorded against your profile<br>
(another decision you've had to consciously make). Application<br>
telemetry on the other hand is automatically transmitted, either on a<br>
time running basis or on application startup/shutdown and the user has<br>
limited involvement in the actual information being transmitted.<br>
<br>
The only exception to this is our web statistics, which are completely<br>
disconnected from all the login systems, and have sufficient fuzzing<br>
applied at the time of being recorded to be useless for identifying<br>
the user in question (it also respects do not track headers and the<br>
like)<br>
<span class="gmail-"><br>
><br>
> Then do we agree that the purpose of random ID collection is secondary as<br>
> long as both sides know it and agree on the terms of collaboration? And<br>
> even: can pull the data out.<br>
><br>
> I am calling functional web sites as apps, produced by any KDE projects,<br>
> hoping that's not seen as dragging. Please do not look at my concern as \
a<br> > criticism towards the web apps because in my opinion apps of any \
technology<br> > have right to use anonymized unique IDs at user's consent for \
purposes<br> > clearly stated to the user to achieve openly explained goals \
welcomed by the<br> > users. Or from a different angle, I see nothing in Freedom \
that prohibits<br> > Free projects to offer such features to Free users \
unconditionally[2].<br> ><br>
> [1] If separating of independent aspects measured is a concern (e.g. [screen<br>
> size] from [locale]) unique user can have multiple IDs generated, one per<br>
> single analyzed group of aspects, to fully decouple one area from another in<br>
> the raw data (as in example: separating screen size analysis from locale<br>
> analysis).<br>
> [2] Unconditionally == as stated by the Policy point "applications \
can't tie<br> > the availability of unrelated aspects of the application to \
telemetry being<br> > enabled" that looks good to me and is needed. \
Applications designed to work<br> > offline are still 100% functional when run \
offline right after installation.<br> <br>
</span>I would rather that we do not have any form of unique identifier<br>
associated with the information, due to the GDPR compliance risks it<br>
imposes.<br>
<br>
We need to be careful enough as it is with the types of telemetry data<br>
we do collect, as it could still be considered personally identifying<br>
information.<br>
People have already done research into this space - see<br>
<a href="https://panopticlick.eff.org/" rel="noreferrer" \
target="_blank">https://panopticlick.eff.org/</a> - therefore careful consideration \
should<br> be made as to the device characteristics we do collect.<br>
<br></blockquote><div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline"><br></div></div><div><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">Thanks for the \
​thorough info Ben.</div></div><div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">I understand \
that admins of the data (from the legal POV) have the last \
say.</div></div></div><div><br></div>-- <br><div class="gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div>regards, Jaroslaw Staniek<br><br>KDE:<br>: A \
world-wide network of software engineers, artists, writers, translators<br>: and \
facilitators committed to Free Software development - <a href="http://kde.org" \
target="_blank">http://kde.org</a><br>KEXI:<br>: A visual database apps builder - <a \
href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br> \
<a href="http://twitter.com/kexi_project" \
target="_blank">http://twitter.com/kexi_project</a> <a \
href="https://facebook.com/kexi.project" \
target="_blank">https://facebook.com/kexi.project</a><br>Qt Certified \
Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" \
target="_blank">http://www.linkedin.com/in/jstaniek</a></div></div></div></div></div> \
</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic