GDPR

Next meeting

Next meeting of the people involved is scheduled on April 6th 2018 at 11:15 UTC in xmpp:xsf@muc.xmpp.org

Introduction

On may the 25th of 2018 the new EU General Data Protection Regulation (GDPR) will be enforced. This may pose problems for the XSF and for the public federated XMPP network, as discussed in the XSF board: https://trello.com/c/t79C3Yds/307-gdpr-advice

This page is a growing page, collecting the research done on the consequences of the GDPR for XMPP and the XSF. There are three fields where the GDPR probably will have an impact and that will be of concert to the XSF:

1. The public (federating) XMPP network
2. The XSF run XMPP server
3. The functioning of the XSF, like the membership applications and the voting

Methodology

We decided to roughly follow the lines of the Data Protection Impact Assessment (DPIA) as mandated by the GDPR:

1. Check if the GDPR is applicable (jurisdiction)
2. List what data is processed
3. List what processing is done
4. List legal grounds for the processing
5. Analyse possible consequences

Collaboration with IETF was mentioned during previous board meeting that started this ad-hoc group. Who is working on it, (how) should we collaborate with them?

Q1: What consequences does the GDPR has for the XMPP network, XMPP server operators and what can/should the XSF do with that?

General note: The legal entity (person, company) that is responsible for a XMPP server is a 'Controller' of data. A hosting service (or other services) are 'processors'.

When federating, data is transferred from one controller to an other.

Q1.1: What consequences does the GDPR has for the XMPP network?

Q1.1a Check if the GDPR is applicable (jurisdiction)

The GDPR is applicable to anyone offering services from EU, or to EU citizens, paid or non-paid and to anyone explicitly targeting EU inhabitants.

Q1.1b List what data is processed

C2S:

• Credentials
• User metadata
  • IP address
  • presence, timestamp of last available presence
• User content:
  • roster content (with names)
  • bookmarks
  • offline/MAM history
  • server-side file storage (http-upload, etc.)
  • PEP
• Server logs

S2S:

• s2s meta-data (IPs, hostnames, sessions, server logs?) - GDPR probably doesn't apply
• user meta-data (presence, subscriptions, message routing)
• user content (messages, pubsub, etc.)
• MUC history, MUC MAM
• Remote components (e.g., roster management)

Q1.1c List what processing is done

Note: Storage is considered as processing under art. 4.2.

C2S:

Common use cases:

• Credentials:
  • minimal: stored as long as the account exists
  • typical: check user JID against well-known spammer patterns
• User metadata:
  • minimal: stored during connection
  • typical: stored with account, spam detection, expose to other users (presence, last activity)
• User content:
  • minimal: roster/bookmarks with account, PEP in RAM only, offline messages until first client connects
  • typical: with account, MAM/files for a given amount of time
• Server logs:
  • minimal: no logs
  • typical: some days / weeks of logrotate, maybe with IP addresses / message metadata (spam detection)

S2S:

Inbound:

• s2s meta-data:
  • typically just inside of server logs. covered by r49
• user meta-data:
  • minimal: forwarded to receiving users connections
  • typical: stored while receiving user is online (to avoid having to send out probes for new resources).
• user content:
  • minimal: forwarded to receiving users connections if online; storage of roster-related things with account.
  • typical: minimal + offline-storage if offline or even MAM for undefined period of time for messages

Q1.1d List legal grounds for the processing

Related articles: 6.1a, 6.1b, 9.1, 9.2a, 13.4, 13

What legal grounds for the processing are possible partly depends on the question whether user-sent content falls under art. 9.1 or not. We need legal advice here (See LQ1 below)

C2S:

If user-sent data IS NOT subject to art. 9.1: Art. 9.1b can be used as ground for processing, so the permission is implicitly granted when signing up for the XMPP service. The EULA must then contain information about the information processed.

If user-sent data IS subject to art. 9.1: The ground for processing has to be art. 9.2, explicit consent.

S2S:

Consent, as in article 6.1a or 9.2 is problematic as giving consent to other servers is harder and not widespread.

Can transfer to and processing by an other server also be covered by art. 6.1b? See LQ2 below. Also possibly relevant: 6.1f, see also https://www.gdpreu.org/the-regulation/key-concepts/legitimate-interest/

Note by Winfried: we should here distinguish between the ground for the transfer to the other server itself and the ground for processing by the other server.

Q1.1e Analyse possible consequences

(Work in progress)

C2S:

Preliminary notes:

• The processing of personal data to the extent strictly necessary and proportionate
• It could be argued that storing very sensitive personal information, albeit for a short time, unencrypted, visible to anyone with access to the backend server (and perhaps more), does not constitute proportional data protection measure, knowing how sensitive the information can be in some cases. It could therefore also be argued, that the processing “reveals” this information to

unauthorized persons, by the way it is implemented. It could therefore be argued, that such processing is contrary to what is required by article 9.

• Even with consent, "proportional means of protection" is required, so encryption (i.e., full-disk) might be necessary to check that box. If user-sent content is subject to art. 9.1, then the "proportional" from "proportional means of protection" becomes harder.
• Article 35?
• Logs
  • See recital 49:
  • Data should not be stored for more time than necessary.

S2S:

Preliminary notes:

• I think what we *at the very minimum* learn from this given the technical means in the XMPP network is: you absolutely must not do any kind of data mining on message content which might come from federation.

Q1.2: What consequences does the GDPR has for the XMPP server operators

TBD

Q1.3: What can/should the XSF do with it?

TBD

Q2: What consequences does the GDPR has for the XSF run XMPP server?

TBD

Q3: What consequences does the GDPR has for the work processes of the XSF itself (membership, voting, wiki etc)?

Personal data the XSF holds:

• Email of wiki users (for account creation)
• Voting results, that could be considered as "political opinions".

The rest of the information given when applying for membership, (fullname, jid/email, employer, etc.) like everything else on the wiki, as well as messages on public MUCs, falls under art. 9.2 e):

Processing relates to personal data which are manifestly made public by the data subject;

ToDo's

1. Link with IETF and other projects with similar issues.
2. Read chapter 5 about transfer of personal data

Lawyer Questions

LQ1 user-sent content and art. 9.1

Does 9.1 automatically apply to all (not e2e encrypted) user-sent content, or only if we are analyzing it for profiling/other purposes? Does using e2e encryption change this?

LQ2 transfer to other controller and art. 6.1b / 6.1f

Can (implicit) consent as in art. 6.1b also apply to transfer to other controllers (as in other XMPP server operators)?

Note by Winfried: see also discussion about art. 6.1f above. Maybe we should rephrase this question.

Contributors:

Ge0rG, jonasw, pep., peter.waher & winfried