Difference between revisions of "GDPR"

Jump to navigation Jump to search
113 bytes removed ,  20:03, 3 May 2018
→‎Q1.1e Analyse possible consequences: overhauling legal analysis
(→‎S2S:: Remove questions on MUC, they are answered, MUC is not different from other traffic)
(→‎Q1.1e Analyse possible consequences: overhauling legal analysis)
Line 121: Line 121:


==== Q1.1e Analyse possible consequences ====
==== Q1.1e Analyse possible consequences ====
(Work in progress)


===== C2S: =====
===== Is the user supplied data of special categories or not? =====
Preliminary notes:
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)
* 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: =====
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.
Preliminary notes:
 
* 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.
====== limit ======
* 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.
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.
* 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
===== 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 jabber 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 ===
71

edits

Navigation menu