[Pkg-privacy-maintainers] Fwd: Retrospective on the privacy BoF and going forward

Sat Aug 11 13:50:00 BST 2018

It seems this message never reached our list, so forwarding it.

-------- Forwarded Message --------
Subject: Retrospective on the privacy BoF and going forward
Resent-Date: Sat,  4 Aug 2018 14:42:50 +0000 (UTC)
Resent-From: debconf-discuss at lists.debian.org
Date: Sat, 4 Aug 2018 22:42:01 +0800
From: Nicolas Braud-Santoni <nicoo at mur.at>
To: debconf-discuss at lists.debian.org, pkg-privacy at alioth.debian.org
CC: ulrike at debian.org, delib at debconf.org

Hi everyone,

I wanted to take the time to recap the spirited discussions during the
BoF, and thank you all for taking the time to attend and contribute.
There were very diverse viewpoints represented, and a large number of
concerns were raised, and we were able to propose solutions for some.

I also wanted to thank Ulrike for proof-reading and completing this fairly
sizable retrospective; sorry for the verbosity, there was quite a lot to
summarize :)

As a reminder, the BoF's agenda was on the wiki [0], and I will add this
summary to it; fairly extensive notes are available on Gobby, and
attached here in plain text.

The pkg-privacy mailing list is in Cc:, as Ulrike invited all of us to
continue the work and discussion there, because it is currently the only
point of contact for such issues.

Generally, it seemed consensual that there are cases where a privacy
issue can be fixed without an adverse impact on usability, that we
should treat such issues as bugs. The collective experience indicates
package maintainers tend to take those bugs seriously and fix them or
report them upstream.

In those cases, Ian and Ulrike suggested having a “standard-ish” usertag
we can use to track this set of bugs (get notifications, let people
search for them, ...). We suggest using the same set of tags as for
debtags (see below).

In other cases it is less clear whether a privacy issue is a bug or a
feature, especially in cases where a feature involves an intrinsic
privacy/usability trade-off.

Gunnar suggested using debtags for labeling software that falls into
those cases; we discussed this later with Enrico, who was
super-enthusiastic about it, and we implemented it early in the evening
[2] (yay!). We used a set of defined anti-features from F-Droid for now,
minus those that do not make sense in Debian, and plus a “uses insecure
crypto” tag. (See list of tags below.)

The next steps there would be to add support for displaying those tags
more explicitly in apt & co (Gnome software), and potentially warning
users when they install potentially-undesirable software, similar to
what F-Droid does. (Volunteers needed!)

A wiki.d.o page was created during the BoF [1] to categorize privacy
issues (both bugs and “anti-features”); the goal is both to share
individual issues, but also build up a more systematic understanding of
what is going on: “Does my issue belong with issues of the same kind?
Does that kind of issue exist in my application? Are there common remedies?”

I would like to invite you all to contribute to it, and once we have
more understanding of the current issues, we can improve the debtags and
BTS (user)tags, look for more packages where those issues exist, find
systematic solutions and more!

Best,

  nicoo

Footnotes
=========

[0] https://wiki.debian.org/DebianPrivacy/BoF201807
[1] https://wiki.debian.org/PrivacyIssues
[2]
https://salsa.debian.org/debtags-team/debtags-vocabulary/commit/656dfc95a90ead38bb304c3e2c7447cf7f3f4ac0

Tag list (currently used for debtags)
=====================================

Facet: privacy
Description: Privacy issues or anti-features
 See https://f-droid.org/wiki/page/Antifeatures

Tag: privacy::no-known-issues
Description: No known issues
 The package has been checked and no known privacy issues or
anti-features were
 found

Tag: privacy::ads
Description: Advertisement
 The software contains advertising

Tag: privacy::tracking
Description: Tracking
 The software tracks and/or reports your activity to somewhere, either
 without your permission, or by default (i.e. you’d have to actively
disable it)

Tag: privacy::network-traffic
Description: Network traffic
 The software reveals information about the user activity by accessing
assets
 or other information over the network without asking for the user's
permission

Tag: privacy::non-free-service
Description: Non-free Network Services
 The software promotes or depends entirely on a non-Free network service

Tag: privacy::non-free-addons
Description: Non free Addons
 The software promotes other non-Free apps or plugins

Tag: privacy::deprecated-crypto
Description: Deprecated crypto
 The software needs deprecated, known to be insecure, cryptographical
 algorithms and protocols

-------------- next part --------------
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 backing" 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 (FIXME nicoo!)
  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