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

Hide room use by verifying #286

Open
Biep opened this issue Oct 27, 2020 · 6 comments
Open

Hide room use by verifying #286

Biep opened this issue Oct 27, 2020 · 6 comments
Labels
A-E2EE-Cross-Signing A-E2EE-SAS-Verification O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Enhancement X-Needs-Product More input needed from the Product team

Comments

@Biep
Copy link

Biep commented Oct 27, 2020

Currently, when verifying someone, one gets an invitation to a room. This is unwanted, for many reasons:

  • Most people will defer the invitation, as they are busy verifying - and then the verification won't proceed.
  • Accepting the invitation leaves one with an unwanted room, that one needs to leave again afterwards. It is messy, both the procedure and the resulting litter.
  • It is quite possible one doesn't want a private channel with the person one is verifying, so it is an invasion of privacy. The verification may be for the sake of a large group, and one might even have told Element to ignore invitations from that particular room member. In some settings (reconciliation, e.g. of a victim with a bully or abuser) it is positively unacceptable; in others (e.g. young girl with older male schoolmate) very unadvisable.
  • In the case of minors or vulnerable people, parents or guardians may not want unsupervised private channels with unvetted people - especially not if their pupil and the stranger both have full power..
  • Verification can even be abused to get a private channel: if the older boy can get the young girl to believe that verification makes things more safe, she'll be an easy victim.
  • Often there is already a private room for the two members, and confusion will result, leading to discussions being arbitrarily distributed over two channels.
  • It scares newcomers off. (Oh, this is some complicated system - first I need to verify, and now I need to accept an invitation while the verification isn't even done yet!)

Using a room under the hood is fine - that comes with the idea that everything is a room. But please don't leak that to the user by default.

@jryans
Copy link

jryans commented Oct 27, 2020

Hmm, interesting feedback... The in-room verification was imagined as a good way to keep a log of your verification activity with someone without needing to invent yet another view of actions and history that is somehow separate from rooms.

In some of these cases, the room itself seems like the least of your worries though: to do verification as intended, you should be comparing things OOB, such as emoji in person (more likely on a video call or similar), so the current system somewhat assumes and expects that you would be verifying people already know personally.

It's not really expected for you to verify random people "just because"... (I do not doubt it happens, I am just trying to add context of what was imagined when designing it.)

This is would be a significant change to the verification system, so I think we'd need to process a lot more feedback before we're ready to change something here. In any case, I'll pass this along to the team.

@philip-rehorst

This comment has been minimized.

@jryans

This comment has been minimized.

@Biep
Copy link
Author

Biep commented Oct 28, 2020

I don't think a significant change is needed - just make the room throw-away, skip the need for explicitly accepting the invitation, and make it all happen behind the scenes.
Instead of making it throw-away it could also be made to show only upon request, and have no write power for the members. That would provide the log function you mention.
(Maybe some of those do require significant changes, but from a user point of view they don't seem particularly invasive.)

And for my personal use case - yes, as a counsellor I do supervise people verifying each other that I would never want to be in a room together without proper supervision. In fact, it is because of the sensitive nature of the discussion in the room I made, and invited them to, that the verification is necessary.
Of course I could tell them to leave the new room immediately after verification, but given the power structures in place (e.g. a daughter with her abusive father) this might not truly happen - either because they decline or because they pretend to but don't (the daughter out of fear for her father, and the father by intent).
So whenever possible, I ask for their 'phones and do the verification plus the subsequent room leaving myself, in their view - but it awkward, given the privacy-sensitivity of modern 'phones.

@Biep
Copy link
Author

Biep commented Oct 28, 2020

Maybe it is good to separate out some issues.

I propose two actions:
A: ensuring the members have no write power in the verification room.
B: Hiding the room, and Element doing auto-accept of the invitation.

  • The privacy issues will be mostly solved by A. B will additionally ensure that no unwanted avatars will show up.
  • The complexity issues will be mostly solved by B.
  • Either A or B will mostly solve the confusion issue (conversations spreading over several rooms).

@mureni
Copy link

mureni commented Jan 16, 2021

I wholeheartedly agree with the others mentioned, and have often grumbled about this UX flow with others for many of the same reasons. Specifically, even in a tech-friendly and privacy-focused group, opening what is to all appearances a new private message window causes massive confusion. The idea that "I don't want to accept this invite" or "I don't want to switch my current view" because you are waiting for the verification to complete is spot on. It is also exacerbated by the fact that if you DO switch windows, often the "awaiting verification" panel will disappear until you actively select the user pending verification again. This can lead to confusion about whether the process failed, or if it worked, and removes the obvious next step interaction ("yes, they match" in the case of emoji verification) from the view.

If opening a new room is necessary, I would strongly suggest some visual indicator to show that this is not a direct/private message, it is a verification process -- and as Biep mentioned above, ensure the members have no write power in the verification room. This would also prevent screencapping the emoji verification within the room itself, which I have seen frequently as a quick and dirty (and insecure) way to get the verification out of the way.

@t3chguy t3chguy transferred this issue from element-hq/element-web May 23, 2022
@kittykat kittykat added O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist labels Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE-Cross-Signing A-E2EE-SAS-Verification O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Enhancement X-Needs-Product More input needed from the Product team
Projects
None yet
Development

No branches or pull requests

5 participants