71
edits
Difference between revisions of "GDPR"
Jump to navigation
Jump to search
→S2S:: Adding to the preliminary notes of s2s from meeting 4
(→S2S:: add inbound/outbound distinction from meeting 4) |
(→S2S:: Adding to the preliminary notes of s2s from meeting 4) |
||
| Line 143: | Line 143: | ||
Preliminary notes: | 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. | * 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 === | ||