mxisd and your privacy
NOTE: This page is out of date in some areas, especially regarding MSCs.
Back in 2016, while we were evaluating Matrix use for orgs/corps environments, we saw three big issues:
- An IS spec not aligned with the typical needs of our users.
- While a theoretical care for Identity data privacy was outlined, the reference implementations did not reflect it.
- There was no self-hostable and/or usable Identity server, only a centralized server.
We set on to build mxisd as you know it today, a fully-fledged Identity Server for Matrix with many more features that typically cover what would be expected of what you would call an "Identity server". We spent several years learning the inner workings of the protocol and the various implementations to ensure all we did was 1) in line with the specification for full inter-polarity and 2) aimed towards a privacy-centric behaviour.
Over time, we have added more and more control for users and administrators alike, allowing them things like:
- Choose if their data is sent to the central Matrix.org server or not
- Use 3PIDs for authentication and discovery without adding them to the homeserver ensuring Identity and Home servers are independent, as required by the specification.
Recently, GDPR or similar legislation finally took a stance from an end-user privacy point of view, instead of corporations and service providers. Users must be given the means and rights so their data is safe and private by default. This directly aligns with our goals with mxisd.
We also made hard choices, clearly preferring privacy over convenience by:
- Not including the Matrix.org servers by default in 3PID searches, giving once again choice and explicit consent from administrators on behalf of their users, while remaining compliant with the spec.
- Making Federation opt-in instead of opt-out by not trying to probe HTTP endpoints if a SRV record is not present.
We will keep working on improving how we safeguard your privacy and your Private Identifiable data by:
- Following feedback from the community, improve the whole user experience of being prompted for the choice to add a 3PID on the Matrix.org for discoverability. We will do a better job at the timing of such notifications and also how it is managed so your users can give informed and unambiguous consent for it. This is done as part of issues #93 and #98
- Actively blocking changes from New Vector, the for-profit currently behind Matrix.org and owner of the synapse and Riot projects, that threatens privacy and control, with the possibility to still opt-in to their changes.
mxisd v1.3.0 will contain a lot of those privacy-protecting changes, the most notables being:
- Opt-in to prompt users to publish their 3PID binding to the central server if those are considered remote, making any 3PID acceptable by default. Currently, this is opt-out.
- Aggressively block any 3PID unbind attempts from synapse given MSC1194 at the time of writing (1st Feb 2019).
So why are we aggressively blocking a specific behaviour when we have always tried to be as invisible as possible and providing a better user experience? Because for the first time, your private data are actively at risk.
It is important to clarify that MSC1194/MSC1915 is still open and under review, which means it is not ready, and we have given extensive feedback to it both on how it could be problematic for privacy and not mirroring the other actions where a clear, specific user consent is given. But all would still be well if MSC1194 was just a theoretical thing.
Sadly, synapse has been implementing it with several arbitrary choices which directly lead to your personal identifiable data (Emails, phone numbers, Matrix ID) potentially leaked to an arbitrary 3rd party server which you did not choose, doe not have any control over, and without being informed of such transmission of data - synapse doesn't use the Identity server configured in your Matrix client (the client has no mean to send it either) but picks its own.
We have spent almost a year attempting to discuss this with the New Vector developers but without any success, while the MSC was constantly being de-prioritized regardless of our privacy concerns and its illegality under European GDPR law.
Given privacy is de facto not a priority for them, we have decided to take action by:
- Actively blocking the endpoint, so data that you control cannot be altered by a remote unknown entity
- Warn users about those potential privacy leaks by sending a notification to the 3PID address, if it is present in one of the Identity stores you have configured.
The MSC1915 is labeled as "an alternative proposal to #1194" when it is in fact just the same proposal, just worded differently. It does not taken into account the feedback given on the original MSC (feedback which has yet to receive any acknowledgement on the MSC itself).
The current implementation of it has lead to various reports of breakage but is also illegal under GPDR as your personal and identifiable data can go off to an arbitrary Identity server, which users never chose.
To this day, despite our repeated feedback, comments and several discussions, nothing has been done by the Matrix.org administrators which also are the developers of synapse and Riot. The proposal is rewritten without taking care of the previous one and the reported issues up to now, and only seem to be about damage control rather than fixing existing problems.
Concretely:
- Upon attempting to remove a 3PID from your profile, synapse might send your personal data to an unknown 3rd party server. As a user, this is a leak of your personal and identifiable data without your explicit and unambiguous consent. As a system administrator, this leaves you open to GDPR law suits since you did not safeguard your user private data and potentially shared it with a remote server.
- While there is nothing mxisd can directly do about synapse sending off data to potentially random servers, mxisd can at least take action if such a request is received: it will inform you so that you are aware of those attempts, block those attempts to prevent any abuse from malicious Homeserver owners.
You don't care about this and just need 3PID removal to work in clients/servers that do not respect your privacy
Current MSC 1915 allow for an escape route by sending some specific status codes. The endpoint can therefore be intercepted in the reverse proxy and made to return such value without ever hitting mxisd.
Example with a nginx snippet configuration:
server {
# Rest of config...
location /_matrix/identity/api/v1/3pid/unbind {
return 404;
}
# Rest of config...
}We have opened an issue on the synapse repo and we would appreciate if you could show your support if privacy is important to you and do not want your private data to just be broadcast randomly.
If you would like to request a way to remove 3PIDs binding the same way as you add them, which should have existed in the specification from the start, leave a comment on MSC1194.