Difference between revisions of "GDPR"

Jump to navigation Jump to search
2,722 bytes added ,  13:56, 29 March 2018
Add results of first discussion
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
62

edits

Navigation menu