Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dbkr opened this issue May 9, 2018 · 19 comments

Comments

Projects
None yet
@dbkr
Copy link
Member

commented May 9, 2018

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.

@matrix-org matrix-org deleted a comment May 10, 2018

@ara4n ara4n added the proposal label May 15, 2018

@dbkr dbkr changed the title A way for HSes to remove bindings from ISes A way for HSes to remove bindings from ISes (aka unbind) Jun 5, 2018

@turt2live turt2live added this to To do: proposals (prioritized) in August 2018 r0 Aug 14, 2018

turt2live added a commit to turt2live/matrix-doc that referenced this issue Aug 30, 2018

Remove mentions of identity services from /3pid/delete
This will be covered by matrix-org#1194

For now, we can accept that homeservers may try to unbind, however clients should not rely on it.

@turt2live turt2live removed this from To do: proposals (not overly prioritized) in August 2018 r0 Aug 30, 2018

@maxidorius

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

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

@maxidorius

This comment has been minimized.

Copy link
Contributor

commented Nov 17, 2018

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

@schiessle

This comment has been minimized.

Copy link

commented Nov 17, 2018

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.

@turt2live turt2live added the T-Core label Dec 24, 2018

@anoadragon453 anoadragon453 removed the T-Core label Jan 4, 2019

@ara4n

This comment has been minimized.

Copy link
Member

commented Jan 5, 2019

@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

This comment has been minimized.

Copy link
Member

commented Jan 5, 2019

(@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

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2019

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

This comment has been minimized.

Copy link

commented Jan 6, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Jan 31, 2019

@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

This comment has been minimized.

Copy link

commented Feb 1, 2019

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

This comment has been minimized.

Copy link

commented Feb 1, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 9, 2019

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.

@matrix-org matrix-org locked and limited conversation to collaborators Feb 9, 2019

@turt2live

This comment has been minimized.

Copy link
Member

commented Feb 9, 2019

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

@mscbot fcp merge

@mscbot

This comment has been minimized.

Copy link
Collaborator

commented Feb 9, 2019

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

Concerns:

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

This comment has been minimized.

Copy link
Member

commented Feb 13, 2019

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

@erikjohnston

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

@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

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

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

@turt2live

This comment has been minimized.

Copy link
Member

commented Mar 18, 2019

@mscbot fcp cancel

Obsoleted by #1915

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.