181
edits
Difference between revisions of "GDPR"
Jump to navigation
Jump to search
→Lawyer Questions
(→ToDo's: expand ToDo with information about art 9.1) |
|||
| (20 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
== Next meeting == | == Next meeting == | ||
Next meeting of the people involved is scheduled on | Next meeting of the people involved is scheduled on May 25th 2018 at 10:30 UTC in xmpp:xsf@muc.xmpp.org | ||
== Introduction == | == Introduction == | ||
| Line 32: | Line 32: | ||
==== Q1.1a Check if the GDPR is applicable (jurisdiction) ==== | ==== 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. | 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. | ||
===== Roles and responsibilities ===== | |||
The GDPR knows different roles: | |||
# Data Subject - the person who the data is about | |||
# 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 another Controller. This transfer of Data is a processing on its own within the GDPR. | |||
Within the XMPP network the following roles can be found: | |||
Sending a message: | |||
* Data Subject: the sender of the message | |||
* Data Controller: the operator of the XMPP server of the sender of the message | |||
* Data Processor: can be several, e.g. the internet hoster of the XMPP server operator | |||
* 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. | |||
* Data Subject: the person initiating the storage | |||
* Data Controller: the XMPP server performing the storage | |||
* Data Processor: can be several, e.g. the internet hoster of the XMPP server operator | |||
==== Q1.1b List what data is processed ==== | ==== Q1.1b List what data is processed ==== | ||
| Line 87: | Line 108: | ||
** minimal: handing over to receiving users server if online; storage of roster-related things with account. | ** minimal: handing over to receiving users server 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 | ** typical: minimal + offline-storage if offline or even MAM for undefined period of time for messages | ||
* Remote roster management: the XEP already requires user consent | * Remote roster management: the XEP already requires user consent | ||
| Line 99: | Line 119: | ||
** minimal: forwarded to receiving users connections if online; storage of roster-related things with account. | ** 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 | ** typical: minimal + offline-storage if offline or even MAM for undefined period of time for messages | ||
* Remote roster management: the XEP already requires user consent | * Remote roster management: the XEP already requires user consent | ||
| Line 119: | Line 138: | ||
* user meta-data: | * user meta-data: | ||
** all transfer requires (implicit) user consent - by joining a MUC or sending a messages to somebody or accepting a subscription (art. 6.1b), outside the EU by 49.1b | ** all transfer requires (implicit) user consent - by joining a MUC or sending a messages to somebody or accepting a subscription (art. 6.1b), outside the EU by 49.1b | ||
Treat all S2S as outside the EU | Treat all S2S as outside the EU | ||
==== Q1.1e Analyse possible consequences ==== | ==== Q1.1e Analyse possible consequences ==== | ||
===== | ===== Is the user supplied data of special categories or not? ===== | ||
For the legal status of the processed data it matter a lot if it is of one of the special categories as described in art. 9 or not. (LQ1) | |||
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. | |||
====== limit ====== | |||
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. | |||
===== Legal grounds for processing ===== | |||
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.''' | |||
====== limit ====== | |||
Any additional processing, not needed for the contract the data subject is engaged in, is not covered. | |||
===== | ===== Data subject rights ===== | ||
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. | |||
=== Q1.2: What consequences does the GDPR has for the XMPP server operators === | === Q1.2: What consequences does the GDPR has for the XMPP server operators === | ||
Draft templates available: | |||
* [[GDPR/ToS_Template|Tos template]] | |||
* [[GDPR/Privacy_Policy_Template|Privacy Policy template]] | |||
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? === | === 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[0]. Do we want local law requirements | |||
to appear in protocol specifications. | |||
Is the question of deletion | |||
[0]: https://mail.jabber.org/pipermail/standards/2018-April/034827.html | |||
== 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? == | ||
| Line 170: | Line 203: | ||
## Limiting of processing because of limits of art. 6.1b and 49.1b | ## Limiting of processing because of limits of art. 6.1b and 49.1b | ||
## The risk of 'triggering' art. 9.1 and the consequences of that | ## The risk of 'triggering' art. 9.1 and the consequences of that | ||
## | ## Inform that their EULA should contain something about: "messages sent to other users are subject to policies those users agreed to" should be included in EULA during registration (TODO: probably s/messages/stanzas, and find end-user speak for "stanza") | ||
## Limits in logging | |||
# Create template for EULA | # Create template for EULA | ||
## should inform users about possible different privacy policies at different servers | ## should inform users about possible different privacy policies at different servers | ||
## should inform users about different (MAM) setting by different users | ## should inform users about different (MAM) setting by different users | ||
## should inform users about publishing MUC logs | |||
## should include information about S2S and possible jurisdiction changes | ## should include information about S2S and possible jurisdiction changes | ||
## quote to use: "by using this server to communicate with third parties you agree that data | |||
will be passed to third parties" | |||
== Technical ToDo == | == Technical ToDo == | ||
| Line 183: | Line 220: | ||
## versioning | ## versioning | ||
## to be determined: informing about EULA details | ## to be determined: informing about EULA details | ||
## create a workflow that allows both 6.1a (explicit permission) and 6.1b (execution of contract) | |||
# MUC status code: 170 when MAM enabled. Also something to say if the logs are public or private. | # MUC status code: 170 when MAM enabled. Also something to say if the logs are public or private. | ||
# Write about default visibility in data policy | # Write about default visibility in data policy | ||
| Line 194: | Line 232: | ||
## MAM XEP doesn't provide a way to differentiate between "explicitely set" and "enabled by default" | ## MAM XEP doesn't provide a way to differentiate between "explicitely set" and "enabled by default" | ||
## Will MAM auto-purge if you disable? Get a mention of this in the XEP | ## Will MAM auto-purge if you disable? Get a mention of this in the XEP | ||
# Add privacy considerations to the XEP-template | |||
## Ensure right of deletion is implemented in: | |||
## MAM contents | |||
## Offline messages (if separate from MAM) | |||
## Roster | |||
## XML Private Storage | |||
## PEP | |||
## other custom processing? | |||
## (addition) server-side file storage, (e.g., HTTP-upload, jingle-ft) | |||
## (addition) private pubsub (223) | |||
## '''Note:''' Jingle-FT, server-side[0], doesn't support deletion. goffi mentioned he would submit a protoXEP for this. | |||
# create a data-download tool | |||
## 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. | |||
== Lawyer Questions == | == Lawyer Questions == | ||
| Line 199: | Line 252: | ||
=== LQ1 user-sent content and art. 9.1 === | === 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? | 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? | ||
# Lawyer 1: Message content is similar to picture uploads. As long as we treat it as an | # Lawyer 1: Message content is similar to picture uploads. As long as we treat it as an 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. | ||
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). | # Lawyer 2: 9.1 is not applicable because it is revealed by the user (9.2e). | ||
So user content is NOT subject to art. 9.1 | So user content is NOT subject to art. 9.1 | ||