A way for HSes to remove bindings from ISes (aka unbind)

[dbkr]

Documentation: https://docs.google.com/document/d/1uDY__XA87VZDnJAzewfxGEVKxLW0KgDWg2oPqM4Ej80/edit#

Matrix room: #msc1194:t2bot.io

Original Documentation: https://docs.google.com/document/d/135g2muVxmuml0iUnLoTZxk8M2ZSt3kJzg81chGh51yg/edit?usp=sharing

We need a way for HSes to be able to remove bindings pointing to their matrix user IDs.

[maxidorius]

@dbkr Ping - I have provided extensive feedback and no further work has been done on this proposal even though it is implemented in synapse and sydent and is currently in production and shipped with releases, leading to production breakage. Technical replies to my technical points would be appreciated, taking into consideration all the discussions that took place until now with @ara4n

[maxidorius]

@dbkr @ara4n further ping as another user gets bitten by the lack of interest in this.

[maxidorius]

@dbkr @ara4n Possibly yet another user gets bitten by this.

[schiessle]

It seems like I have exactly the same problem. The homeserver is matrix.org and the identity server is vector.im and I can't remove any email address or phone number I added. I always get the "Failed to remove threepid" error message. Any idea how this could be solved? This looks really bad if you can't remove personal information you added once to your matrix.org account.

[ara4n]

@dbkr, having read through all this again, i suggest that we should just ditch having the HS try to guess/track which IS it should be unbinding the 3PID on, and instead make it the user's problem to unbind themselves.

We could avoid the user having to reauth themselves by making the lifetime of the bind session infinite, such the HS could remember the secret used to bind in the first place and use it to unbind subsequently without reauth. However, this feels like a bit of a premature optimisation, given the act of GDPR erasure is pretty rare, and in retrospect it's probably not a disaster for the user to go through manually confirming that they really do want their 3PIDs unbound.

wdyt?

[ara4n]

(@schiessle i think your issue was unrelated to this; it should work fine with the vector.im IS; the problem should only happen if you're using an alternative IS like mxisd which doesn't implement the unbind requests)

[maxidorius]

it should work fine with the vector.im IS; the problem should only happen if you're using an alternative IS like mxisd which doesn't implement the unbind requests

@ara4n We already know it is irrelevant of using mxisd given the PR made to synapse to not fail on 404. The problem is in synapse and the cause is already known: it all depends on the order that IS domains are listed in the config file.

[schiessle]

@ara4n indeed, I just tested it again and I could remove a email address just fine. Don't know what happened back then when I tried it and it didn't worked. Maybe just a server hiccup at the same time.

[dbkr]

@dbkr, having read through all this again, i suggest that we should just ditch having the HS try to guess/track which IS it should be unbinding the 3PID on, and instead make it the user's problem to unbind themselves.

We could avoid the user having to reauth themselves by making the lifetime of the bind session infinite, such the HS could remember the secret used to bind in the first place and use it to unbind subsequently without reauth. However, this feels like a bit of a premature optimisation, given the act of GDPR erasure is pretty rare, and in retrospect it's probably not a disaster for the user to go through manually confirming that they really do want their 3PIDs unbound.

wdyt?

Having to guess what IS to unbind from is terrible, but is essentially a synapse bug due to the fact it doesn't track what IS it bound 3pids to.

Extending the lifetime of the bind session to be infinite could be problematic since the owner of a 3pid may not own it 2 years from now.

Basically the advantage is that it allows the owner of an mxid to stop a 3pid pointing at their mxid even if they don't, or no longer, own the 3pid. Eg. making a user confirm the email address to remove it doesn't work if you're trying to remove your work email address for a company you just left. Having a say in what 3pids point at your mxid is also an advantage (if we used the same thing when a 3pid was bound).

So yep, it doesn't seem too unreasonable to make users re-auth their email addresses when removing them, as long as accept that any you no longer own would be stuck there for good (or until you pleaded with your IS/HS admins to remove them).

[abeluck]

It seems to me that this entire proposal is based off a false premise:

We need a way for HSes to be able to remove bindings pointing to their matrix user IDs.

Why?

I believe the users should initiate account/data deletion from their own client by (1) making a request to the HS to delete data and (2) making a request to the IS to unbind their 3PIDs. The IS can confirm using the medium verification method.

[sparky8251]

3PIDs are arguably the most sensitive of information people will put on the greater Matrix network. It can be used to identify you quickly and easily using leaks from other large service providers and various free/purchasable data sets.

I would prefer that ALL 3PIDs can be asked of my IS directly, such that if I redact it on my IS it vanishes from the network. BUT if this is not possible we need a proper way of redacting.

I don't know enough about riot and synapse to have an opinion on the best way to achieve it, but if data must be copied to the network at large to be usable, there must be a way to delete it.

There need not be much consideration for malicious actors other than attempting to make it so more and more can be asked directly of my IS rather than copied to a 3rd party IS.

Please, seriously consider adding this in some shape or form. I want to see Matrix succeed, but when it can't even live up to some of its own promises like being fully federated and privacy focused it seems like it'll have a hard time fighting off detractors.

What difference is there between the way Matrix handles 3PID and most other chat platforms now? Seems like once something is out there it can never go away, despite 3PID being theoretically the most simple to remove without impacting anything about the wider network (since it just maps to a matrix ID right?).

It's the small things that will make or break this protocol. This, message editing, etc.

[turt2live]

I've updated the proposal to match what was discussed - please see the top comment for references.

I'm also locking this conversation - please direct feedback to the proposal. I've unlocked it as some concerns were raised to having a locked conversation (also github blocks reactions, which is annoying). Please direct feedback to the actual proposal document, however.

[turt2live]

and because this has been hashed out quite a lot between the major players and agreement is imminent...

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• @KitsuneRal
• @anoadragon453
• @ara4n
• @dbkr
• @erikjohnston
• @richvdh
• @turt2live
• @uhoreg

Concerns:

• can we not just add an id_server param for now (A way for HSes to remove bindings from ISes (aka unbind) #1194 (comment))

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[uhoreg]

lgtm, modulo answering the question of how /requestToken needs to change

[erikjohnston]

I approve of the fact that we add a id_server to the /delete API, it makes a lot of sense.

I'm far less convinced about adding breaking changes to enforce that a user has proven they own the threepid before a call to /delete. I vote we just add the id_server param, and then we can revisit all this when we come to do it properly?

[turt2live]

@erikjohnston can that be written up on the google doc please? We don't have threading here because legacy proposal, and I'd like to maintain feedback on the proposal itself.

[erikjohnston]

@mscbot concern can we not just add an id_server param for now

[turt2live]

@mscbot fcp cancel

Obsoleted by #1915