EU Survey on "Sustainable OSS communities in the public sector"

[Thomas Pfeiffer]

Hey everyone,
The European Commission is currently looking for input on "Sustainable OSS 
communities in the public sector" via an open survey.
I believe it's a great opportunity to show politicians and bureaucrats how to 
collaborate with us in a sustainable way.
Therefore, I'd encourage all KDE projects who have any kind of significant 
touch points with the public sector (e.g. their software being used in public 
schools or universities, government agencies, whatever) to participate in the 
survey.
I'd think it's best to fill the survey out once per public sector project.
You can find it here: 
https://ec.europa.eu/eusurvey/runner/OSORsurvey2020sustainabilitycommunities
Thank you,
Thomas

Re: Regarding KDE Privacy policy

[Volker Krause]

Not publishing the raw data right from the start was mainly a safety measure, 
to give us a chance to review the data and fix de-anonymization issues should 
any have slipped through.

There's also technical limitations, the current system has no fine-grained 
access control, not even read vs write access.

For publishing aggregated data, I think that's already "allowed" right now, 
just nobody has built an automated way of doing that yet.

Given how little practical experience we have with this, I'd be cautious with 
publishing unreviewed raw data though. And that isn't just theoretical. We 
have already fixed overly detailed OpenGL information that were both aiding 
fingerprinting and making the data unnecessarily noisy after a first review. 
Additionally, the data set is still too small to avoid fingerprinting 
entirely, there's at least two criteria in there that allow me to find my own 
record in the Plasma data for example. That's not an entirely fair "attack" 
obviously, but it shows this needs a careful review.

Regards,
Volker

On Tuesday, 25 February 2020 13:44:55 CET Veggero Nylo wrote:
> Hi!
> Currently, data transmitted by KUserFeedback is available only by opening a
> sysadmin ticked explaining why you need access in the first place. I can
> see the reasoning behind this, but I do not think this is a good idea for
> developers and users. I think that releasing the aggregated data under CC0
> license would be better, as also proposed by Martin here:
> https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I think
> this would benefit user trust, as right now they have to trust what the
> KUserFeedback KCM without really being able to see what data KDE developers
> are actually able to see (as most users won't be able to look into the
> code); on the other hand, if the data was publicly released, they would be
> able to see the data themselves and know exactly what developers are going
> to see. I also think this would benefit developers, as there might be a
> significant number of developers who could be interested in looking to the
> data, maybe just a single value, without being able to fully justify access
> to all the data (the fact that you have to write a justification becomes a
> negative factor that makes looking at the data less interesting);
> furthermore, even if they get access to the data, they would be unable to
> discuss it in KDE communication channels as those are public, nor on
> phabricator tasks to support their patches, effectively making the data
> much less useful. Also, the current policy might result in a privacy
> problem, e.g.: I once needed data from stats.kde.org regarding website
> views over time. I was granted access to it, and I now can see every singe
> website viewer, with their country, OS, browser, etc - much more than I
> actually needed. If the aggregated data was to be released publicly, I
> would no longer need for stats.kde.org access, and I would no longer be
> able to access private data that I did not actually need. Finally, I do not
> fully understand why the data needs to be kept private in the first place,
> since it is supposed to be anonymous and contain no user content.
> What's your opinion on this?
> ~ Niccolò Venerandi (aka veggero/niccolove)



signature.asc
Description: This is a digitally signed message part.

Re: Regarding KDE Privacy policy

[Kai Uwe Broulik]

Hi,


just start with the basics


I also have yet to see a migration path for when we add new stats. From 
what I can tell a user gets presented what will be collected in a UI 
that isn't very good and once user enables, we can just add stuff 
without the user every having to re-consent or get told about it?


Right now we e.g. log panel count. If user then updates the system, 
suddenly we might log all kinds of additional stuff. What's the upgrade 
plan for this?


Cheers
Kai Uwe

Re: Regarding KDE Privacy policy

[Christoph Cullmann]

On 2020-02-25 19:22, Albert Astals Cid wrote:
El dimarts, 25 de febrer de 2020, a les 18:47:16 CET, Nate Graham va 
escriure:

I find myself in agreement.

I have access to the kuserfeedback data and to be honest I'm rather
dissatisfied with its actionability. There's nothing detailed like "x
percentage of users change the default wallpaper" or "y percentage of
users switch to double-click" that we could actually use to inform our
UI design--let alone anything that could be used to personally 
identify

anyone. The actual data set is so tame and uninteresting that I agree
that we could change our policy and release the stats just to show
everyone that we have nothing to hide.


You can log anything you want, if you think knowing users that have
non default wallpapers or that switch to double click, log that.


That is totally correct, guess the Plasma developers did just start with 
the

basics (like Kate, too).

But given we praise our self that the data we collect is properly 
anonymized
and doesn't contain any private stuff, having it available for the 
public

would make this even more transparent.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Regarding KDE Privacy policy

[Albert Astals Cid]

El dimarts, 25 de febrer de 2020, a les 18:47:16 CET, Nate Graham va escriure:
> I find myself in agreement.
> 
> I have access to the kuserfeedback data and to be honest I'm rather 
> dissatisfied with its actionability. There's nothing detailed like "x 
> percentage of users change the default wallpaper" or "y percentage of 
> users switch to double-click" that we could actually use to inform our 
> UI design--let alone anything that could be used to personally identify 
> anyone. The actual data set is so tame and uninteresting that I agree 
> that we could change our policy and release the stats just to show 
> everyone that we have nothing to hide.

You can log anything you want, if you think knowing users that have non default 
wallpapers or that switch to double click, log that.

Cheers,
  Albert

> 
> Nate
> 
> 
> 
> On 2/25/20 5:44 AM, Veggero Nylo wrote:
> > Hi!
> > Currently, data transmitted by KUserFeedback is available only by 
> > opening a sysadmin ticked explaining why you need access in the 
> > first place. I can see the reasoning behind this, but I do not think 
> > this is a good idea for developers and users. I think that releasing the 
> > aggregated data under CC0 license would be better, as also proposed by 
> > Martin here: 
> > https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I think 
> > this would benefit user trust, as right now they have to trust what the 
> > KUserFeedback KCM without really being able to see what data KDE 
> > developers are actually able to see (as most users won't be able to look 
> > into the code); on the other hand, if the data was publicly released, 
> > they would be able to see the data themselves and know exactly what 
> > developers are going to see. I also think this would benefit developers, 
> > as there might be a significant number of developers who could be 
> > interested in looking to the data, maybe just a single value, without 
> > being able to fully justify access to all the data (the fact that you 
> > have to write a justification becomes a negative factor that makes 
> > looking at the data less interesting); furthermore, even if they get 
> > access to the data, they would be unable to discuss it in KDE 
> > communication channels as those are public, nor on phabricator tasks to 
> > support their patches, effectively making the data much less useful. 
> > Also, the current policy might result in a privacy problem, e.g.: I once 
> > needed data from stats.kde.org  regarding website 
> > views over time. I was granted access to it, and I now can see every 
> > singe website viewer, with their country, OS, browser, etc - much more 
> > than I actually needed. If the aggregated data was to be released 
> > publicly, I would no longer need for stats.kde.org 
> >  access, and I would no longer be able to access 
> > private data that I did not actually need. Finally, I do not fully 
> > understand why the data needs to be kept private in the first place, 
> > since it is supposed to be anonymous and contain no user content.
> > What's your opinion on this?
> > ~ Niccolò Venerandi (aka veggero/niccolove)
> 
> 

Re: Regarding KDE Privacy policy

[Paul Brown]

On martes, 25 de febrero de 2020 19:06:27 (CET) Christoph Cullmann wrote:
> On 2020-02-25 18:47, Nate Graham wrote:
> > I find myself in agreement.
> > 
> > I have access to the kuserfeedback data and to be honest I'm rather
> > dissatisfied with its actionability. There's nothing detailed like "x
> > percentage of users change the default wallpaper" or "y percentage of
> > users switch to double-click" that we could actually use to inform our
> > UI design--let alone anything that could be used to personally
> > identify anyone. The actual data set is so tame and uninteresting that
> > I agree that we could change our policy and release the stats just to
> > show everyone that we have nothing to hide.
> 
> +1 from me. (e.g. for the Kate stats)

+1 from Promo, even if it is only used to give us a vague idea of how the size 
of the userbase changes over time.

Cheers

Paul

> 
> Greetings
> Christoph
> 
> > Nate
> > 
> > On 2/25/20 5:44 AM, Veggero Nylo wrote:
> >> Hi!
> >> Currently, data transmitted by KUserFeedback is available only by
> >> opening a sysadmin ticked explaining why you need access in the
> >> first place. I can see the reasoning behind this, but I do not think
> >> this is a good idea for developers and users. I think that releasing
> >> the aggregated data under CC0 license would be better, as also
> >> proposed by Martin here:
> >> https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I
> >> think this would benefit user trust, as right now they have to trust
> >> what the KUserFeedback KCM without really being able to see what data
> >> KDE developers are actually able to see (as most users won't be able
> >> to look into the code); on the other hand, if the data was publicly
> >> released, they would be able to see the data themselves and know
> >> exactly what developers are going to see. I also think this would
> >> benefit developers, as there might be a significant number of
> >> developers who could be interested in looking to the data, maybe just
> >> a single value, without being able to fully justify access to all the
> >> data (the fact that you have to write a justification becomes a
> >> negative factor that makes looking at the data less interesting);
> >> furthermore, even if they get access to the data, they would be unable
> >> to discuss it in KDE communication channels as those are public, nor
> >> on phabricator tasks to support their patches, effectively making the
> >> data much less useful. Also, the current policy might result in a
> >> privacy problem, e.g.: I once needed data from stats.kde.org
> >>  regarding website views over time. I was
> >> granted access to it, and I now can see every singe website viewer,
> >> with their country, OS, browser, etc - much more than I actually
> >> needed. If the aggregated data was to be released publicly, I would no
> >> longer need for stats.kde.org  access, and I
> >> would no longer be able to access private data that I did not actually
> >> need. Finally, I do not fully understand why the data needs to be kept
> >> private in the first place, since it is supposed to be anonymous and
> >> contain no user content.
> >> What's your opinion on this?
> >> ~ Niccolò Venerandi (aka veggero/niccolove)


-- 
Promotion & Communication

www: http://kde.org
Mastodon: https://mastodon.technology/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde

Re: Regarding KDE Privacy policy

[Christoph Cullmann]

On 2020-02-25 18:47, Nate Graham wrote:

I find myself in agreement.

I have access to the kuserfeedback data and to be honest I'm rather
dissatisfied with its actionability. There's nothing detailed like "x
percentage of users change the default wallpaper" or "y percentage of
users switch to double-click" that we could actually use to inform our
UI design--let alone anything that could be used to personally
identify anyone. The actual data set is so tame and uninteresting that
I agree that we could change our policy and release the stats just to
show everyone that we have nothing to hide.


+1 from me. (e.g. for the Kate stats)

Greetings
Christoph



Nate



On 2/25/20 5:44 AM, Veggero Nylo wrote:

Hi!
Currently, data transmitted by KUserFeedback is available only by 
opening a sysadmin ticked explaining why you need access in the 
first place. I can see the reasoning behind this, but I do not think 
this is a good idea for developers and users. I think that releasing 
the aggregated data under CC0 license would be better, as also 
proposed by Martin here: 
https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I 
think this would benefit user trust, as right now they have to trust 
what the KUserFeedback KCM without really being able to see what data 
KDE developers are actually able to see (as most users won't be able 
to look into the code); on the other hand, if the data was publicly 
released, they would be able to see the data themselves and know 
exactly what developers are going to see. I also think this would 
benefit developers, as there might be a significant number of 
developers who could be interested in looking to the data, maybe just 
a single value, without being able to fully justify access to all the 
data (the fact that you have to write a justification becomes a 
negative factor that makes looking at the data less interesting); 
furthermore, even if they get access to the data, they would be unable 
to discuss it in KDE communication channels as those are public, nor 
on phabricator tasks to support their patches, effectively making the 
data much less useful. Also, the current policy might result in a 
privacy problem, e.g.: I once needed data from stats.kde.org 
 regarding website views over time. I was 
granted access to it, and I now can see every singe website viewer, 
with their country, OS, browser, etc - much more than I actually 
needed. If the aggregated data was to be released publicly, I would no 
longer need for stats.kde.org  access, and I 
would no longer be able to access private data that I did not actually 
need. Finally, I do not fully understand why the data needs to be kept 
private in the first place, since it is supposed to be anonymous and 
contain no user content.

What's your opinion on this?
~ Niccolò Venerandi (aka veggero/niccolove)


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Regarding KDE Privacy policy

[Nate Graham]

I find myself in agreement.

I have access to the kuserfeedback data and to be honest I'm rather 
dissatisfied with its actionability. There's nothing detailed like "x 
percentage of users change the default wallpaper" or "y percentage of 
users switch to double-click" that we could actually use to inform our 
UI design--let alone anything that could be used to personally identify 
anyone. The actual data set is so tame and uninteresting that I agree 
that we could change our policy and release the stats just to show 
everyone that we have nothing to hide.


Nate



On 2/25/20 5:44 AM, Veggero Nylo wrote:

Hi!
Currently, data transmitted by KUserFeedback is available only by 
opening a sysadmin ticked explaining why you need access in the 
first place. I can see the reasoning behind this, but I do not think 
this is a good idea for developers and users. I think that releasing the 
aggregated data under CC0 license would be better, as also proposed by 
Martin here: 
https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I think 
this would benefit user trust, as right now they have to trust what the 
KUserFeedback KCM without really being able to see what data KDE 
developers are actually able to see (as most users won't be able to look 
into the code); on the other hand, if the data was publicly released, 
they would be able to see the data themselves and know exactly what 
developers are going to see. I also think this would benefit developers, 
as there might be a significant number of developers who could be 
interested in looking to the data, maybe just a single value, without 
being able to fully justify access to all the data (the fact that you 
have to write a justification becomes a negative factor that makes 
looking at the data less interesting); furthermore, even if they get 
access to the data, they would be unable to discuss it in KDE 
communication channels as those are public, nor on phabricator tasks to 
support their patches, effectively making the data much less useful. 
Also, the current policy might result in a privacy problem, e.g.: I once 
needed data from stats.kde.org  regarding website 
views over time. I was granted access to it, and I now can see every 
singe website viewer, with their country, OS, browser, etc - much more 
than I actually needed. If the aggregated data was to be released 
publicly, I would no longer need for stats.kde.org 
 access, and I would no longer be able to access 
private data that I did not actually need. Finally, I do not fully 
understand why the data needs to be kept private in the first place, 
since it is supposed to be anonymous and contain no user content.

What's your opinion on this?
~ Niccolò Venerandi (aka veggero/niccolove)

Regarding KDE Privacy policy

[Veggero Nylo]

Hi!
Currently, data transmitted by KUserFeedback is available only by opening a
sysadmin ticked explaining why you need access in the first place. I can
see the reasoning behind this, but I do not think this is a good idea for
developers and users. I think that releasing the aggregated data under CC0
license would be better, as also proposed by Martin here:
https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I think
this would benefit user trust, as right now they have to trust what the
KUserFeedback KCM without really being able to see what data KDE developers
are actually able to see (as most users won't be able to look into the
code); on the other hand, if the data was publicly released, they would be
able to see the data themselves and know exactly what developers are going
to see. I also think this would benefit developers, as there might be a
significant number of developers who could be interested in looking to the
data, maybe just a single value, without being able to fully justify access
to all the data (the fact that you have to write a justification becomes a
negative factor that makes looking at the data less interesting);
furthermore, even if they get access to the data, they would be unable to
discuss it in KDE communication channels as those are public, nor on
phabricator tasks to support their patches, effectively making the data
much less useful. Also, the current policy might result in a privacy
problem, e.g.: I once needed data from stats.kde.org regarding website
views over time. I was granted access to it, and I now can see every singe
website viewer, with their country, OS, browser, etc - much more than I
actually needed. If the aggregated data was to be released publicly, I
would no longer need for stats.kde.org access, and I would no longer be
able to access private data that I did not actually need. Finally, I do not
fully understand why the data needs to be kept private in the first place,
since it is supposed to be anonymous and contain no user content.
What's your opinion on this?
~ Niccolò Venerandi (aka veggero/niccolove)