Source: https://wiki.xmpp.org/web/index.php?title=GDPR&printable=yes
Timestamp: 2019-04-19 08:14:55+00:00

Document:
3 Q1: What consequences does the GDPR has for the XMPP network, XMPP server operators and what can/should the XSF do with that?
3.1 Q1.1: What consequences does the GDPR has for the XMPP network?
3.1.5.1 Is the user supplied data of special categories or not?
3.3 Q1.3: What can/should the XSF do with it?
4 Q2: What consequences does the GDPR has for the XSF run XMPP server?
5 Q3: What consequences does the GDPR has for the work processes of the XSF itself (membership, voting, wiki etc)?
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?
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.
Data Controller - a person or organisation who collects, stores or processes data about a natural person and who determines the goals and the means of the processing of the data.
Data Processor - a person (not employee of the controller) or organisation who processes data on behalves of a Data Controller.
Third Party - a Data Controller that receives data from an other Controller. This transfer of Data is a processing on its own within the GDPR.
Third Party: the XMPP server of the receiving person.
Message storage (MAM, offline storage): Note: the data here is a personal conversation, this conversation contains messages from one or more other users but these are stored under the responsibility of and as personal from the user using the storage.
Note: Storage is considered as processing under art. 4.2.
typical: stored while receiving user is online (to avoid having to send out probes for new resources).
minimal: handing over to receiving users server if online; storage of roster-related things with account.
minimal: forwarded to receiving users connections if online; storage of roster-related things with account.
Spam detection is not standardized, so hard to assess here. There are also many thin lines, like reading messages for manual tweaking of spam-rules, using machine learning and filtering on words that may indicate content from art. 9.1. Therefore we can not give a general answer about spam detection, but we do need to give some guidance on it.
Art. 6.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.
Is the user supplied data of special categories or not?
Though most servers do process messages that contain data like that, it is not processing, analogue to the status of pictures. Though it contains such sensitive data, as long as it is not analysed and categorized on those categories, it is not subject to art. 9.
As soon as such analysis is done, e.g. for spam filtering, it is not covered any more by the legal framework sketched here. Processing such data for spam filtering for example mus have explicit consent.
Processing is done for the performance of a contract with the data subject (art. 6.1b). The contract (does not have to be an explicit contract) would then be: "to take care of the communication"
Message Archive Management (MAM) is not obvious a service when signing up with a XMPP server. So it can not be covered by the same legal ground for processing, it should be off by default and the user should turn it on manually. The ground for processing is here article 9.1a.
Q. by Winfried: is this indeed 6.1a or a second 6.1b? By requesting the archiving service, the user has second(ary) service he wants to perform. Art. 6.1a is problematic, because it brings in the permission question as described in art 7.
Any additional processing, not needed for the contract the data subject is engaged in, is not covered.
The structure of XMPP ensures that all data subject rights are guaranteed, except for the right of deletion and the right to transfer the data. The right of deletion is not implemented in all standards. The right to transfer, though only applicable to data that is processed under art 6.1a, not 6.1b, is also not guaranteed. Two elements would help to ensure the right tot transfer is ensured correctly: a 'download client' and automatic transfer to an other server.
These are WIP and will be moved to git(hub), under some template form, to allow for server operators to benefit from last changes directly.
Q1.3: What can/should the XSF do with it?
Should changes required for GDPR compliance be mentioned directly into the XEPs we want to modify, or should they be mentioned in another XEP proper to GDPR, as discussed in standards@ thread. Do we want local law requirements to appear in protocol specifications.
Q2: What consequences does the GDPR has for the XSF run XMPP server?
Q3: What consequences does the GDPR has for the work processes of the XSF itself (membership, voting, wiki etc)?
Voting results, that could be considered as "political opinions".
Link with IETF and other projects with similar issues.
will be passed to third parties"
MUC status code: 170 when MAM enabled. Also something to say if the logs are public or private.
last online timestamp, status message, online status, list of online devices: contacts, chatroom participants?
Add a note to the MAM XEP about GDPR consent requirements.
MAM XEP doesn't provide a way to differentiate between "explicitely set" and "enabled by default"
Note: Jingle-FT, server-side, doesn't support deletion. goffi mentioned he would submit a protoXEP for this.
List data types and their means of export, in ways that allow reuploading to other servers.
Provide an xmpp "client" as an export tool?
resurrect the idea of automatic transfer of an account to an other server, see XEP-0227 & XEP-0283.
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?
opaque blob and don't analyse it, art9 doesn't apply, (See r51). Not sure how this plays with mod_firewall processing, spam filtering etc.
Lawyer 2: 9.1 is not applicable because it is revealed by the user (9.2e).
Can (implicit) consent as in art. 6.1b also apply to transfer to other controllers (as in other XMPP server operators)?
The transfer to the other itself can be covered by 6.1b (and 49.1b when transfer outside the EU), because it is necessary to deliver the service the user requested.
The processing on the other server can also be covered by 6.1b, but only as long as not further processing is done.
This page was last modified on 22 May 2018, at 12:37.

References: art. 4
 art. 9

Art. 6
 art. 9
 Art. 6
 art 7
 art 6
 art9
 art. 6