[Members] GDPR & XSF - Minutes

Peter Waher peterwaher at hotmail.com
Mon Mar 26 17:00:41 UTC 2018

Hello Jonas

Unfortunately, I’m not available tomorrow (Tuesday). On Wednesday, I’m available all day. So, if you can reschedule to Wednesday, I’d be happy to join. If not, I can also provide input on-list, or in a later meeting.

Regarding Article 9: Key Word here is ”revealing”. So, any processing that reveals such sensitive information is prohibited. Since very sensitive information can bypass the server, it is important to not reveal it (without permission):

  1.  Limit access to data through encryption and/or strict authorization.
  2.  Make sure everyone is aware that this can actually happen, if the data is processed in unencrypted form (transparent information). Personal chat logs can contain exceptionally personal and sensitive information.
  3.  Transparently describe what happens to their data (in clients, en-route, on brokers, etc.), so that users have a chance to adapt.
  4.  Transparently describe who has access to your personal data. (If data is not encrypted, and if operators can read it, this should be described so that users have a chance to moderate the sensitivity of their information.)
  5.  Use end-to-end encryption to protect very sensitive information, to avoid any processing that could reveal such data by accident or purposefully.

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.

There are two safe options to choose from:

  1.  Use end-to-end encryption for sensitive data. Processing of end-to-end encrypted data does not reveal special categories of information as described in article 9.
  2.  Be transparent to the end user, that data is processed unencrypted in portions of the process, and that users therefore should refrain from posting anything they do not want others to see.

Best regard,


Från: Members <members-bounces at xmpp.org> för Jonas Wielicki <jonas at wielicki.name>
Skickat: Monday, March 26, 2018 6:17:06 PM
Till: XSF Members
Ämne: Re: [Members] GDPR & XSF - Minutes

Hi Peter,

Thank you very much for chiming in. Any chance you can attend the meeting
tomorrow? If not, maybe your expertise would be a valid reason to reschedule.
Alternatively, we can try to work out arguments for the other points and you
can provide input on-list or in a later meeting.

On Montag, 26. März 2018 18:09:16 CEST Peter Waher wrote:
> > 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.

This quote is a bit unclear. In context, it was meant that Article 9.1 would
not be applying. The GDPR itself (for personal data) of course still applies,
but winfried was arguing that 9.1 does not apply if you don’t analyze the

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

I tried to make a similar argument to that, becaues Art. 9.1 talks about
"processing" and "processing" includes "storage" (which will be true for
messages with MAM). So I’m not sure how "analysis" is required for 9.1 to

This might mean that we need consent from users across federation boundaries,
for things like MAM, if I’m not mistaken?

kind regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20180326/c7b591f4/attachment.html>

More information about the Members mailing list