Telemetry Policy - Remaining Questions
staniek at kde.org
Tue Apr 3 08:57:57 UTC 2018
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>
> >> > 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/
> >> >
> >> > tl;dr: Why discussing: Any deep change and limitation to projects'
> >> > freedom
> >> > needs to bring substantial benefits over drawbacks. Level of
> >> > of
> >> > the contract for a project or individual developer needs to be
> >> > 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
> >> > 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
> >> > 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
> > some.
> > We need them to we move forward.
> > In the meantime my stack runs just well, people that use IDs are even
> > right to remove their data, something that's *not* going to be possible
> > 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
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 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.
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
 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).
 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
> > --
> > regards, Jaroslaw Staniek
> > KDE:
> > : A world-wide network of software engineers, artists, writers,
> > : and facilitators committed to Free Software development -
> > 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
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-community