"Automatic Info Reporting" BoF summary

Mario Fux kde-ml at unormal.org
Wed Sep 17 09:02:08 BST 2014

Am Dienstag, 16. September 2014, 00.52:28 schrieb Albert Astals Cid:


Thanks a lot for bringing this forward. IMHO it's a very important topic and 
future communication channel with our users but I think as well that it's a 
multi-year thing before we can earn the first fruits. So let's start early 

See some comments below.

> BoF that that is a follow up of
> https://conf.kde.org/system/attachments/45/original/spyware.pdf?1410020392
> and
> http://files.kde.org/akademy/2014/videos/The_case_for_spyware_-_Albert_Asta
> ls_Cid.webm
> ############


> What kind of data may we want?
> - Version number
> - Distro
> - uname -a
> - KConfig, GPU, which kind of hardware
> - SSD vs rotational media
> - Language + locale
> - RTL
> - Bluetooth usage - who sends files
> - Usability stuff - order of menu items. When a user opens something, have
> they tried other menus. Maybe this should be more opt-in because this is a
> usability study. Investigate more.
> - Usage data as to how frequently stuff is run on KDE
> - Favorite applications
> - Frequency of configuration changes
> - support info hooks and dbus
> - Filter the data vs users and developers.  Some strange heuristics to
> determine this.
> - Number of users on the system --> System Info. Are they using systemd?
> - Input devices? More hardware info.
> - Geolocation data?

Please add as well:
- Ask user about their email address (stored separately of course) so we can 
contact them! Ask if they are interested in something special (quarter mails, 
new app version information, fundraiser, events in the neighbourhood, other 
KDE people near them, etc. pp.)

> Server - needs awesome visaulization. Maybe this could be done in the KCM
> as well.
> It is very important to show what we are tracking and WHY. With pretty
> pictures.
> Gamification?
> We need to start small. We cannot send 1.5 Gb of data.
> How often should this be sent? Maybe weekly or monthly?
> Server Side
> -------------
> * Keep people's ID for a while.
> * Maybe we do it per IP, but then we have NAT.
> * Malicious people can send private info so that they can incriminate KDE.
> * The RAW data can be dangerous.
> * Some kind of data validation? Some users may trick the data.
> * Make it hard to troll the server.
> * We can publish public data as long as there are no private strings. And
> the data is validated.
> -> How do we handle updates where we keep collecting more data each update?
> Might put off some users.

Tell them which data is newly collected and opt-out of an automatic update.

> Consensus -
> * We should always ask the users if we can / can not track stuff.
> * Should not be a passive notification?
> * Maybe have a "Ask me Later", but keep collecting data during that time,
> but don't send the data.


More information about the kde-core-devel mailing list