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

Unable to disconnect from IS if the server is unavailable #10909

Open
jryans opened this issue Sep 18, 2019 · 5 comments · May be fixed by matrix-org/matrix-react-sdk#3549

Comments

@jryans
Copy link
Member

commented Sep 18, 2019

We've added too many helpful steps to the disconnect from IS flow which try to list existing 3PIDs that may be bound. Unfortunately, this leads to an error case where you can't disconnect if the IS is unavailable.

Riot should improve messaging and error handling for this case, as it's possible your IS could be permanently unavailable, for example.

@lampholder

This comment has been minimized.

Copy link
Member

commented Oct 1, 2019

We just want to warn users when this occurs so that they can make an informed decision within the limitations of Matrix.

I'd suggest:

  • If the user chooses to disconnect from identity server X, and
  • Identity server X is at that point in time unavailable (meaning we cannot check to see whether the user has published any third party identifiers to identity server x

then we pop up a warning saying something like:

You should remove your personal data from **identity server X** before disconnecting. Unfortunately, **identity server X** is currently offline or cannot be reached, so we can't check if it is currently processing your personal data.

We recommend that you:
- check your browser plugins for anything that might block the identity server (such as Privacy Badger)
- get in touch with the administrators of **identity server X**
- wait and try again later

                                                                               [ Disconnect anyway ] [ Try again later ]

With Disconnect anyway having the green-on-white non-default-option styling, and Try again later styled white-on-green.

The above wording is very long and very boring and probably quite confusing. We don't expect this eventuality to occur often, so it might be fine, but I wonder if @nadonomy can think of anything more succinct that gets across:

  • the situation (that we can't check if your data is on the identity server because it's down)
  • the recommended actions, and
  • the fact that you can still disconnect if you like
@nadonomy

This comment has been minimized.

Copy link
Member

commented Oct 1, 2019

What's the users context (i.e. what copy have they read) to arrive at this point? If it's implicit they're removing data from the IS can we simplify the message to:

We can't reach the identity server your disconnecting from. Try again later, or get in touch with its administrator.

[Cancel] [Disconnect anyway]
@lampholder

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

It's not implicit - you can 'disconnect' your riot instance from an identity server (either by 'connecting' to a different one or choosing not to use an identity server at all). At the point of doing this, you may have threepids still publicly associated with your mxid on the identity server you're leaving behind.

In an ideal world, we'd be able to robustly cause your data to be deleted from the identity server at the point of your saying you want to disconnect. However, this is tricky to do in a robust way - we'd need a whole new layer of infrastructure for the homeserver to accept instructions to delete data from an identity server, then robustly try and get those requests to the identity server (retrying in case of failures), then asynchronously communicating the eventual success/failure state to the user, then giving the user a way to handle this state.

So instead of all that, we just query the IS to see which threepids are publicly bound, and if there are any, tell the user they should use the regular unbinding UX to delete that data before disconnecting.

But, if the IS is not available, we can't make that check.

Sometimes the IS will not be available because of a temporary failure, sometimes because of browser plugin blocking traffic (I'm looking at you, privacy badger), and sometimes because the identity server has been unplugged and thrown into the sea. If it's the first case they should try again later, if it's the second they should tweak privacy badger settings and if it's the third they should brute force disconnect because the server's never coming back to do the check.

When we can't reach the identity server we can't know what is the cause of failure.

@lampholder

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

Thinking again about the UX for this, Ryan pointed out that it will usually take a little while to discover that the IS is not available, so we need both to agree a human-friendly timeout, and to include a representation of this waiting into the UX.

So I reckon it should look something like:


Disconnect identity server

Trying to contact identity server vector.im

(spinner)

[ Go back ] [ Disconnect anyway ] (greyed out, unclickable)


Then either the modal we have today (if the IS is successfully reached):
image

Or if we cannot reach it, then the (slightly) more succinct:

You should remove your personal data from **identity server X** before disconnecting. Unfortunately, **identity server X** is currently offline or cannot be reached.

You should:
- check your browser plugins for anything that might block the identity server (such as Privacy Badger)
- contact the administrators of **identity server X**
- wait and try again later

                                                                            [ Go back ] [ Disconnect anyway ] 
@lampholder

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

And yes that is three different ways of representing UX in a single github comment; you're welcome :P

@jryans jryans self-assigned this Oct 9, 2019
@jryans jryans moved this from Up Next to In Progress in Workflow Oct 9, 2019
jryans added a commit to matrix-org/matrix-react-sdk that referenced this issue Oct 11, 2019
If the IS is unreachable, this handles the error by showing a warning
encouraging the user to check after their personal data and resolve the
situation, but still allows them to continue if they want.

Fixes vector-im/riot-web#10909
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Workflow
In Progress
3 participants
You can’t perform that action at this time.