416
edits
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Next meeting == | == Next meeting == | ||
Next meeting of the people involved is scheduled on May | 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 where 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 an other 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 144: | Line 165: | ||
=== 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 176: | Line 210: | ||
## should inform users about publishing MUC logs | ## 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 206: | Line 244: | ||
## '''Note:''' Jingle-FT, server-side[0], doesn't support deletion. goffi mentioned he would submit a protoXEP for this. | ## '''Note:''' Jingle-FT, server-side[0], doesn't support deletion. goffi mentioned he would submit a protoXEP for this. | ||
# create a data-download tool | # create a data-download tool | ||
# resurrect the idea of automatic transfer of an account | ## 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 == |
edits