Difference between revisions of "GDPR"

From XMPP WIKI
Jump to: navigation, search
m
(Add results of first discussion)
Line 15: Line 15:
  
 
== Q1: What consequences does the GDPR has for the XMPP network, XMPP server operators and what can/should the XSF do with that? ==
 
== 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.1: What consequences does the GDPR has for the XMPP network? ===
  
=== Q1.2: What consequences does the GDPR has for the XMPP network, XMPP server operators ===
+
==== 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
 +
** 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: =====
 +
TBD
 +
 
 +
==== 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 (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: =====
 +
TBD
 +
 
 +
==== Q1.1d List legal grounds for the processing ====
 +
TBD
 +
 
 +
==== Q1.1e Analyse possible consequences ====
 +
 
 +
winfried > I have a feeling that as long as we don't analyse data (content AND
 +
metadata) on patterns that indicate categories from art. 9.1, 9.2, GDPR is not
 +
applicable.
 +
 
 +
jonasw > I think what we *at the very minimum* learn from this given the
 +
technical means in the Jabber network is: you absolutely must not do any kind
 +
of data mining on message content whih might come from federation.
 +
 
 +
 
 +
 
 +
 
 +
Logs
 +
Data should not be stored for more time than necessary. See recital 49:
 +
> The processing of personal data to the extent strictly necessary and
 +
> proportionate
 +
 
 +
as giving consent to other servers is harder and not widespread
 +
 
 +
 
 +
=== Q1.2: What consequences does the GDPR has for the XMPP server operators ===
 +
TBD
  
 
=== Q1.3: What can/should the XSF do with it? ===
 
=== Q1.3: What can/should the XSF do with it? ===
 +
TBD
  
 
== Q2: What consequences does the GDPR has for the XSF run XMPP server? ==
 
== 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)? ==
 
== 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 ==
 
== ToDo's ==
 
# Link with IETF and other projects with similar issues.
 
# Link with IETF and other projects with similar issues.
 
+
# ask for legal advice on art. 9.1
  
 
== Contributors: ==
 
== Contributors: ==
 
Ge0rG, jonasw, pep., peter.waher &  winfried
 
Ge0rG, jonasw, pep., peter.waher &  winfried

Revision as of 13:56, 29 March 2018

Introduction

On may the 25th of 2018 the new EU General Data Protection Regulation (GDPR) will be enforced. 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
    • 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:

TBD

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 (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:

TBD

Q1.1d List legal grounds for the processing

TBD

Q1.1e Analyse possible consequences

winfried > I have a feeling that as long as we don't analyse data (content AND metadata) on patterns that indicate categories from art. 9.1, 9.2, GDPR is not applicable.

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



Logs Data should not be stored for more time than necessary. See recital 49: > The processing of personal data to the extent strictly necessary and > proportionate

as giving consent to other servers is harder and not widespread


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. ask for legal advice on art. 9.1

Contributors:

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