"Automatic Info Reporting" BoF summary

[Albert Astals Cid]

El Dimecres, 17 de setembre de 2014, a les 10:02:08, Mario Fux va escriure:
> Am Dienstag, 16. September 2014, 00.52:28 schrieb Albert Astals Cid:
> 
> Morning
> 
> 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_Ast
> > a
> > ls_Cid.webm
> > 
> > ############
> 
> [snip]
> 
> > 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.)

That can be done in the kcm as extra opt-in, we don't want to present a scary 
dialog on first boot, otherwise people will just run away.

> 
> > 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.

Problem is if we do change the data too often this may get boring/tiring. 
Solution is not to change the data :D

Cheers,
  Albert

> 
> > 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.
> 
> Thx
> Mario