Removing an administrative 3PID also attempts to remove the IS 3PID mapping without user consent

[maxidorius]

Synapse is currently implementing matrix-org/matrix-spec-proposals#1194 in production systems even with the MSC still under review with several privacy concerns and GDPR illegalities.

This issue represent the community request for this behaviour to be removed for the following reasons:

1. Current C2S API is clear that [contact information] is independent of any information kept by any identity servers.
2. Current IS API is clear that for privacy reasons access should be restricted to avoid leaking potentially sensitive data.
3. The Identity servers are made independent from Homeservers, allowing a user to choose an Identity server across several servers if they so wish. This means they might not want a 3PID to be removed from their IS if they remove a specific 3PID from one of the HS they use. They are never given any choice on the matter.
4. The process by which a 3PID is removed is not a mirror of the process by which a 3PID is added. Adding is done under user's consent with at least one confirmation needed from the user while removing is done in a totally invisible manner without even informing the user.
5. The user does not give informed and unambiguous consent for their personal data to be sent to a potentially independent 3rd party service, being illegal under GDPR.

We have added a link to this issue in mxisd notification upon blocking any attempt from synapse to make our users aware of the lack of concern for privacy and GDPR user consent when dealing with personal data.

[abeluck]

The 5 points raised by @maxidorius are serious, which is despite the fact that synapse is rolling out an under-review proposal to production systems (and that the proposal as it stands has severe outstanding issues).

Points 1 and 2 demonstrate that synapse is breaking from the matrix protocol spec. I can't find any discussion where this deviation was justified or considered.

In NV's own post on GDPR compliance they state:

Consent requires that our users are fully informed as to exactly how their data will be used, where it will be stored, and (in our case) the specific caveats associated with a decentralised, federated communication system. They are then asked to provide their explicit approval before using (or continuing to use) the service.

The synapse implementation of revealing the personally identifiable information to the first IS clearly violates this principal of consent, particularly when the user specified their own IS when registering the 3PID in the first place. The fact that synapse has no memory of the user's chosen IS should be considered a bug, and addressed accordingly.

[sparky8251]

This definitely needs addressing. I don't have much to add other than:

This doesn't feel much like a decentralized, federated, and privacy respecting communications protocol if it just shoots off incredibly sensitive and very identifiable information with wanton disregard for the user.

Data leaks of such incredibly personally identifiable information should be treated as a serious security risk and addressed as soon as possible.

[maxidorius]

For the sake of transparency, there was a closed door Jitsi meeting to re-discuss MSC1194 and solve this issue. For the record, here are the minutes which I have accepted in case those get edited: PDF.

The outcome is to fix it by following my original counter-proposal which was mentioned at several places in my original review of the MSC and remove the current behaviour of synapse.

[maxidorius]

FYI such requests are now actively blocked in stable releases of mxisd, starting from v1.3.0 with a notification sent to the 3PID owner informing them about this issue.

[erikjohnston]

MSC1915 has now been implemented

[rubo77]

If I'm not wrong, it seems like not all of the 5 paragraphs are fixed in MSC1915

[ethindp]

I fully agree with this. Removing 3PID without user concent is a direct and deliberate violation of the GDPR, specifically article 6, paragraph 1 and Article 7 at least, as consent is not being acquired. (And no, "installing" the server does not count as consent; the GDPR specifically classifies "consent" as "any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her". As users of the server are not notified in any manner that this is occurring before it actually happens, this is not consent.)

[ethindp]

Update: just noticed that this was closed. Was reading this article, forgot that some of that was out of date.