Debian Privacy BoF
==================

Presenter: W. Martin Borgert (debacle)
https://wiki.debian.org/DebianPrivacy/BoF201807 random notes :)

Does have Debian privacy issues?
--------------------------------

- some applications do homephoning or do not respect privacy in any other sense
- different users & usecases: from paranoid to don't care spectrum…
- no common rule about privacy in Debian

What kind of problems did we encounter in the past?

- ian: if you file a bug the maintainer will fix it
- ian: Policy documents standard practice. If there is an expectation of privacy, Policy can be used to "nudge" in this direction.
  - u: We have to _know_ that applications "phone home" in order to be able to answer to it, be aware of it, and file a bug.
 - Jonas Smedegard: purism is tracking down such issues for work. The problem is that bugs are features at the same time (Gnome calculator's download of currency rates is a good example). Let's collect these privacy issues on a wiki page. Make it visible so that users can choose if they want to use a certain software. This should be the first thing we should do. Maybe Tails already does such a thing (yes; their wiki is quite good on that)?

  Exists *now*: https://wiki.debian.org/PrivacyIssues

- martin: let's not only focus on home phoning, also "user is typing", and abuser's surveillance
- gunnar: dkg proposed a similar BoF before: quit logging ⇒ https://summit.debconf.org/debconf14/meeting/70/quit-logging-or-data-minimization-in-debian/
- fdroid approach: tell the user what an application does when they download/install it
- ian: let's use the bugsystem (and use a new usertag?): we need "institutional backup" from debian policy

- u: Tails has submitted several bugs upstream as part of its normal workflow when packages are discovered to be leaking information. 
- u: Debian is lacking default firewalling, and more importantly, default GUI for managing firewall rules to ensure users are at minimum risk of unintentional leaking.
- $anonymous: no logging at workplace. how can we reach a consensus at distribution level about logging? maybe logging should be handled like debug symbols? off by default, if you want to debug something, turn on the logging.
- martin: we should have a low logging default. But it's very hard to get this "right", as users might want the capabilities firewalling would deny. It's a UX pattern. intrigeri's idea: good UX means in the GUI of Gnome calculator we need an option that tells users "Hey, do you want me to download currency rates every day?"
- nicoo proposes to resolve such a thing at a packaging level
  by finding common phone-home data (exchange rates, ...) and create common packages
  for it
- gunnar: getting the issues (nicoo: and patches) upstream is important
- pabs: social contract is one of the rules we can use to convince people. make things opt-in.
- u: When there are BTS bugs, we need a usertag
- gunnar: doesnt agree with pabs ⇒ Social Contract does not mention privacy. "user interest" is too squishy... many developers will oppose that view
- martin: for end applications this is doable.- debtags-based: Create a "privacy" category, with tags outlining issues with privacy for each package
- u: Who is responsible for distro-wide privacy issues?  Who is notified when there is a new issue?
  → to give it the recognition it deserves/requires, use debian/control with e.g. X-Privacy: $values, then the maintainer ensure quality/accurateness/up2date-ness of the field.
  → u likes that idea :)
  → g: If we use debtags, we can notify apt users, and email whoever is interested

- ian: We are talking at cross-purposes:
  - bugs we want to fix/act on
  - things we want to notify users about
  
  Debtags are easier and more lightweight than debian/control
- sean: we are trying to move metadata out of packages, so let's not do that anymore
  → counter-argument: it's about quality ensurance, hence a bit more 'controlable' process seems reasonable to me (less of a "wiki"-approach).
- u: Privacy should be enabled by default, the system should be privacy-respecting by default
  - jonas: People in this room can be persuaded of that, but, Debian as a whole? Not likely. Suggests: Has to be asked (talked about debconf as a mechanism). Privacy can be a friction point.
- nicoo: we can certainly improve on privacy without impacting user experience. it's easy to opt-out, but we cannot expect from users that once they've sent the data they can ask people to delete it. We cannot assume that users don't want privacy because there is no recovery from a privacy leakage.
- ian: in the EU legislators are taking care of that. Machines that phone home without consent of users is now illegal in the EU, so we should disable such feautres by default if we cannot fix them.
- xxx: we need to be careful about privacy leakage. version check: bug, in an application this is not a bug. turning off things by default = protecting the user.
- jonas: added a privacy page on the wiki.
- how do we find such issues?
- ian: autopkgtest → network restrictions could be detected for example