Difference between revisions of "GDPR"

From XMPP WIKI
Jump to navigation Jump to search
(→‎S2S:: Adding to the preliminary notes of s2s from meeting 4)
(32 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Next meeting ==
== Next meeting ==
Next meeting of the people involved is scheduled on April 22th 2018 at 10:30 UTC in xmpp:xsf@muc.xmpp.org
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 18: Line 18:
# Analyse possible consequences
# 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?
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?
=== Wrap up ===
A structured wrapup in a table is visible here: https://wiki.xmpp.org/web/GDPR/Table


== 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? ==
Line 29: 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 84: 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
* MUC: is this different from plain s2s?
* Remote roster management: the XEP already requires user consent
* Remote roster management: the XEP already requires user consent


Line 96: 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
* MUC: is this different from plain s2s?
* Remote roster management: the XEP already requires user consent
* Remote roster management: the XEP already requires user consent
===== Spam detection =====
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.


==== Q1.1d List legal grounds for the processing ====
==== Q1.1d List legal grounds for the processing ====
''Related articles: 6.1a, 6.1b, 9.1, 9.2a, 13.4, 13''
What legal grounds for the processing are possible partly depends on the question whether user-sent content falls under art. 9.1 or not. We need legal advice here (See LQ1 below)


===== C2S: =====
===== C2S: =====


If user-sent data IS NOT subject to art. 9.1:
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.  
Art. 9.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.  


If user-sent data IS subject to art. 9.1:
MAM and MUC MAM are covered by explicit consent (6.1a)
The ground for processing has to be art. 9.2, explicit consent.


===== S2S: =====
===== S2S: =====
Line 117: Line 137:
** typically just inside of server logs. r49 probably applies                   
** typically just inside of server logs. r49 probably applies                   
* 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          
** 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
* user content (MAM, MUC MAM)


Consent, as in article 6.1a or 9.2 is problematic as giving consent to other servers is harder and not widespread.
Treat all S2S as outside the EU


Can transfer to and processing by an other server also be covered by art. 6.1b? See LQ2 below. Also possibly relevant: 6.1f, see also https://www.gdpreu.org/the-regulation/key-concepts/legitimate-interest/
==== 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.


'''Note by Winfried''': we should here distinguish between the ground for the transfer to the other server itself and the ground for processing by the other server.
===== 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"


==== Q1.1e Analyse possible consequences ====
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.
(Work in progress)
 
'''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.'''


===== C2S: =====
====== limit ======
Preliminary notes:
Any additional processing, not needed for the contract the data subject is engaged in, is not covered.  
* The processing of personal data to the extent strictly necessary and proportionate
* It could be argued that storing very sensitive personal information, albeit for a short time, unencrypted, visible to anyone with access to the backend server (and perhaps more), does not constitute proportional data protection measure, knowing how sensitive the information can be in some cases. It could therefore also be argued, that the processing “reveals” this information to
unauthorized persons, by the way it is implemented. It could therefore be argued, that such processing is contrary to what is required by article 9.
* Even with consent, "proportional means of protection" is required, so encryption (i.e., full-disk) might be necessary to check that box. If user-sent content is subject to art. 9.1, then the "proportional" from "proportional means of protection" becomes harder.
* Article 35?
* Logs
** See [http://www.privacy-regulation.eu/en/recital-49-GDPR.htm recital 49]:
** Data should not be stored for more time than necessary.


===== S2S: =====
===== Data subject rights =====
Preliminary notes:
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.
* I think what we *at the very minimum* learn from this given the technical means in the XMPP network is: you absolutely must not do any kind of data mining on message content which might come from federation.
* What I'd like to know more about is whether we need some explicit legal framework for handing off data, or if this is covered by the user's implicit consent of wanting the message delivered.
* I wonder if we want a way to give consent to the processing done by an s2s domain. then there could be something pubsubby where clients can query which s2s domains the user consented with and show that in the UI. warn the user when sending a message to a non-consented domain with "review the privacy policy" and offer doing the in-band consent thing as per the EULA XEP.
* I’d like to have a status code for [MAM MUC logging] because that could save us from 9.1 trouble (there’s something about "manifestly made public" in there, and if we can get clients to show "THIS ROOM IS PUBLICLY LOGGED", we’re out of trouble there I think), 170 or similar


=== 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 ===
TBD
 
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? ===
TBD
 
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 169: Line 199:
== ToDo's ==
== ToDo's ==
# Link with IETF and other projects with similar issues.
# Link with IETF and other projects with similar issues.
# Read chapter 5 about transfer of personal data
# Read chapter 5 about transfer of personal data to countries outside the EU
# Create document with guidelines for server operators containing:
## 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
## 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
## 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 publishing MUC logs
## 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 ==
                        
                        
# EULA XEP for c2s, but maybe also for s2s?
# EULA XEP for c2s
## Linking to EULA, also with IBR
## versioning
## 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
## JID: contacts, chatrooms and their server operators
## vcard avatar: always visible
## PEP avatar and other PEP things: most likely to your contacts
## PEP items visibility should be made explicit by the client to the user
## last online timestamp, status message, online status, list of online devices: contacts, chatroom participants?
# Add to MAM-XEP:
## 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"
## 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 181: 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 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).
So user content is NOT subject to art. 9.1


=== LQ2 transfer to other controller and art. 6.1b / 6.1f ===
=== LQ2 transfer to other controller and art. 6.1b / 6.1f ===
Can (implicit) consent as in art. 6.1b also apply to transfer to other controllers (as in other XMPP server operators)?
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.
'''Note by Winfried''': see also discussion about art. 6.1f above. Maybe we should rephrase this question.
* The processing on the other server can also be covered by 6.1b, but '''only''' as long as not further processing is done.


== Contributors: ==
== Contributors: ==
Ge0rG, jonasw, pep., peter.waher &  winfried
Ge0rG, jonasw, pep., peter.waher &  winfried

Revision as of 07:18, 9 May 2019

Next meeting

Next meeting of the people involved is scheduled on May 25th 2018 at 10:30 UTC in xmpp:xsf@muc.xmpp.org

Introduction

On may the 25th of 2018 the new EU General Data Protection Regulation (GDPR) will be enforced. This may pose problems for the XSF and for the public federated XMPP network, as discussed in the XSF board: https://trello.com/c/t79C3Yds/307-gdpr-advice

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?

Wrap up

A structured wrapup in a table is visible here: https://wiki.xmpp.org/web/GDPR/Table

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.

Roles and responsibilities

The GDPR knows different roles:

  1. Data Subject - the person who the data is about
  2. 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.
  3. Data Processor - a person (not employee of the controller) or organisation who processes data on behalves of a Data Controller.
  4. 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

C2S:
  • Credentials
  • User metadata
    • IP address
    • presence, 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:
  • s2s meta-data (IPs, hostnames, sessions, server logs?) - GDPR probably doesn't apply
  • user meta-data (presence, subscriptions, message routing)
  • user content (messages, pubsub, etc.)
  • MUC history, MUC MAM
  • Remote components (e.g., roster management)

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

Outbound:

  • s2s meta-data:
    • typically just inside of server logs. covered by r49
  • user meta-data:
    • minimal: handing over to receiving users server
    • typical: stored while receiving user is online (to avoid having to send out probes for new resources).
  • user content:
    • 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
  • Remote roster management: the XEP already requires user consent

Inbound:

  • s2s meta-data:
    • typically just inside of server logs. covered by r49
  • user meta-data:
    • minimal: forwarded to receiving users connections
    • typical: stored while receiving user is online (to avoid having to send out probes for new resources).
  • user content:
    • 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
  • Remote roster management: the XEP already requires user consent
Spam detection

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.

Q1.1d List legal grounds for the processing

C2S:

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.

MAM and MUC MAM are covered by explicit consent (6.1a)

S2S:
  • s2s meta-data:
    • typically just inside of server logs. r49 probably applies
  • 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

Treat all S2S as outside the EU

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

Draft templates available:

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[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?

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. Read chapter 5 about transfer of personal data to countries outside the EU
  3. Create document with guidelines for server operators containing:
    1. Limiting of processing because of limits of art. 6.1b and 49.1b
    2. The risk of 'triggering' art. 9.1 and the consequences of that
    3. 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")
    4. Limits in logging
  4. Create template for EULA
    1. should inform users about possible different privacy policies at different servers
    2. should inform users about different (MAM) setting by different users
    3. should inform users about publishing MUC logs
    4. should include information about S2S and possible jurisdiction changes
    5. quote to use: "by using this server to communicate with third parties you agree that data

will be passed to third parties"


Technical ToDo

  1. EULA XEP for c2s
    1. Linking to EULA, also with IBR
    2. versioning
    3. to be determined: informing about EULA details
    4. create a workflow that allows both 6.1a (explicit permission) and 6.1b (execution of contract)
  2. MUC status code: 170 when MAM enabled. Also something to say if the logs are public or private.
  3. Write about default visibility in data policy
    1. JID: contacts, chatrooms and their server operators
    2. vcard avatar: always visible
    3. PEP avatar and other PEP things: most likely to your contacts
    4. PEP items visibility should be made explicit by the client to the user
    5. last online timestamp, status message, online status, list of online devices: contacts, chatroom participants?
  4. Add to MAM-XEP:
    1. Add a note to the MAM XEP about GDPR consent requirements.
    2. MAM XEP doesn't provide a way to differentiate between "explicitely set" and "enabled by default"
    3. Will MAM auto-purge if you disable? Get a mention of this in the XEP
  5. Add privacy considerations to the XEP-template
    1. Ensure right of deletion is implemented in:
    2. MAM contents
    3. Offline messages (if separate from MAM)
    4. Roster
    5. XML Private Storage
    6. PEP
    7. other custom processing?
    8. (addition) server-side file storage, (e.g., HTTP-upload, jingle-ft)
    9. (addition) private pubsub (223)
    10. Note: Jingle-FT, server-side[0], doesn't support deletion. goffi mentioned he would submit a protoXEP for this.
  6. create a data-download tool
    1. List data types and their means of export, in ways that allow reuploading to other servers.
    2. Provide an xmpp "client" as an export tool?
  7. resurrect the idea of automatic transfer of an account to an other server, see XEP-0227 & XEP-0283.

Lawyer Questions

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?

  1. 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.
  2. 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

LQ2 transfer to other controller and art. 6.1b / 6.1f

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.

Contributors:

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