"Automatic Info Reporting" BoF summary

[Albert Astals Cid]

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

############

Albert's plan.
1. Have a KDED.
--- On First Run -> Show "Dialog"
--- Send data every week

2. KCM + Widget
--- Disable Sending
--- What has been sent
--- The widget can be added to apps to see what data is being sent

3. Library for App developers
--- ::sendInfo(..)

Millian - Why put it into a daemon?
Albert - So that you can batch changes.

Discussion - Is a daemon really required?

--- Marco - PR Disaster --
He says it is really dangerous. And is a spyware.
There was a discussion about it being opt-in or opt-out.
Some stuff about German law being a problem and someone might sue us. Except
we have no money so meh.
Loads of other apps do it
* Firefox is enabled by default
* Canonical package popularity is default by default after popcon is installed
* Canonical crash reporting is enabled by default
* Kexi is disabled by default

German Jurisdiction Paragraph 15 TMG Sentence 3

A discussion about how anonymous the data is. Is a unique random ID per
person enough.
Jos - Some stuff about Netherlands and about how the IDs have to be
eventually removed

Open Data
- How should the data be published? Should the IDs be published?

Opt-In vs Opt-Out
--> Maybe the decission should be made per application
--> This might be worse
--> Maybe this discussion should happen in the e.V?
--> Someone needs to figure out the liability for the e.V?

Millian would like to see this in many many applications. But he would like
to go one step at a time.
- Maybe we start with Plasma? It's arguably the most important - David E.

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?

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.

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.