[Members] GDPR & XSF 4 - Minutes

Maxime Buquet pep at bouah.net
Mon Apr 9 23:37:54 UTC 2018


# GDPR & XSF 4

At xsf at muc.xmpp.org - 2018/04/09 8:30 UTC
Attendees: winfried, Ge0rG, jonasw, pep.

Date of Next: 2018/04/10 10:30 UTC

https://gdpr-info.eu/

Q1)
 1. What consequences does the GDPR has for the Jabber network?
 2. .. Jabber server operators?
 3. .. what can/should do the XSF with that?
Q2) What consequences does the GDPR has for the XSF running Jabber server?
Q3) What consequences does the GDPR has for the work processes of the XSF
itself (membership, voting, wiki etc)?


## Q1
### Q1.1

#### What processing is being done

S2S:

Inbound:

> Ge0rG > as winfried said last time, this is handing off of data to another
>   controller. The other controller is also bound by GDPR rules, so they can't
>   just do anything they want with the data. In theory
> jonasw > Ge0rG, sooo... if you federate with servers which have users which
>   are inside the EU you’re under GDPR?
> Ge0rG> 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
> Ge0rG> jonasw: basically, yes.


> jonasw > 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.


- s2s meta-data: 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
- MUC: is this different from plain s2s?
> jonasw > I’d like to have a status code for [MAM MUC logging]
> jonasw > 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)
> pep. > jonasw, 170 or similar
- Remote roster management: the XEP already requires user consent


Technical TODO:
- EULA XEP for c2s, but maybe also for s2s?
- MUC status code: 170 when MAM enabled. Also something to say if the
  logs are public or private.

-- 
Maxime “pep” Buquet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/members/attachments/20180410/e8b84aa5/attachment.sig>


More information about the Members mailing list