[Members] GDPR & XSF - Minutes

Maxime Buquet pep at bouah.net
Mon Mar 26 15:08:43 UTC 2018


At xsf at muc.xmpp.org - 2018/03/16 12:00CEST
Attendees: winfried, Ge0rG, jonasw, pep.

Date of Next: 2018/03/17 12:15CEST


https://gdpr-info.eu/


Useful pointers (from jonasw):
- Key articles about the rights of the subjects of the data: 13, 14, and
  possibly 7, 15, 12, 16, 17, 21, 20.
- Rights for transfer of data between providers: 20
- Risk management: 5, and consent in 7 and 8, with proof
- Notifying data breaches: 33, 34
- Records of processing activities: 30


Questions

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


Collaboration with IETF was mentioned during previous board meeting. Who is
working on it, (how) should we collaborate with them?


## Q1
### Q1.1 What consequences does the GDPR has for the Jabber network?

winfried > I think we should regard each server as its own legal entity,
  and the federation as a kind of processing (exchanging data)
Ge0rG > I think it makes sense to define the roles as well. An XMPP server
  operator is a "controller", and wohever does the hosting and other services
  for them is a "processor".
winfried > Ge0rG: +1
pep. > winfried: You said "exchanging data", would that fit into
  "transferring data"
winfried > [..] let that discussion dangle for a moment

TODO: confirm ^

#### Who is under GDPR jurisdiction

Anyone offering services from EU, or to EU citizens, paid or non-paid.

#### What data is processed

C2S:

- Credentials
- User metadata
  * IP address
  * 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

#### 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 (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)

Data should not be stored for more time than necessary. See recital 49:
> The processing of personal data to the extent strictly necessary and
> proportionate

TODO: Create a wiki page with all the information above.

winfried > I have a feeling that as long as we don't analyse data (content AND
metadata) on patterns that indicate categories from art. 9.1, 9.2, GDPR is not
applicable.

TODO: ask for legal advice on this.

S2S:

jonasw > I think what we *at the very minimum* learn from this given the
technical means in the Jabber network is: you absolutely must not do any kind
of data mining on message content whih might come from federation.

as giving consent to other servers is harder and not widespread

#### What ground does the processing have

TBD.

#### Possible consequences

TBD.

## Q2 What consequences does the GDPR has for the XSF running Jabber 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;

-- 
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/20180326/f957e565/attachment.sig>


More information about the Members mailing list