[Members] GDPR & XSF - Minutes

Peter Waher peterwaher at hotmail.com
Mon Mar 26 16:09:16 UTC 2018


Hello

I applaud the effort to address GDPR & XMPP. I am interested to participate in any discussions relating to the GDPR (in general) & XMPP (in particular). I’ve been dedicated working with the GDPR for close to two years, and I advise companies on this topic. If there’s an interest, I can share any of the experience I’ve gained, as well as hold introductions to anyone not familiar with the topic, or who wants to have a deeper discussion of it.

Some things that I did not see in the document, that are important to consider:

* Giving users access to their data (which is different from exporting personal data that they have provided themselves), including data not provided by themselves, but relating to them.
* Restricting use of data
* Deleting data (or accounts and all related data that can be deleted)
* Correcting data
* Propagating requests/changes (especially important in a federated environment such as an XMPP network)

Reviewing the comments in the mail, I also see that there are several issues that should be addressed:

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

Note that responsibilities in GDPR are not defined on technical grounds, but by who decides the purposes and means of the processing. The same software can therefore be used by both a processor and by a controller, in the same way (technically). Software or servers are never controllers or processors themselves.


> #### What data is processed

Don’t forget Publish/Subscribe items, nodes, etc.

> check user JID against well-known spammer patterns

This is called “profiling” in GDPR. Blocking users based on automatic profiling alone could have consequences in GDPR (if it can have negative legal consequences for the blocked party somehow).

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

Not sure what this relates to, but GDPR is highly relevant to XMPP, since it relates to very sensitive personal data. If the servers analyze the data or not is not relevant (to the applicability of the GDPR or not). GDPR applies, since servers process personal data. Risks are furthermore estimated in the absence of safeguards. Proportional data protection mechanisms have to be in place based on what could happen, not on what was originally intended. Potentially very sensitive information bypass the servers. One of the things servers need to worry about, is how to make sure that data does not end up in places where it does not belong.

> #### What ground does the processing have
> #### Possible consequences

These will probably vary, depending on the use case.

Best regards,
Peter Waher


Från: Maxime Buquet<mailto:pep at bouah.net>
Skickat: den 26 mars 2018 17:09
Till: members at xmpp.org<mailto:members at xmpp.org>
Ämne: [Members] GDPR & XSF - Minutes

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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20180326/97f5ebd8/attachment-0001.html>


More information about the Members mailing list