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

Messages bluntly refuse to send in a room with an unverified device present. #3287

Open
ara4n opened this issue Sep 16, 2024 · 11 comments
Open
Labels
A-E2EE Encryption O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Maybe-Release-Blocker

Comments

@ara4n
Copy link
Member

ara4n commented Sep 16, 2024

Steps to reproduce

  1. Upgrade to build 706
  2. Try to speak in a room where a verified user has an unverified device present (i.e. red shield on EW)
  3. Message fails to send outright, without any retry button
  4. "Sending failed [OK]" is the dialog if you tap the (!) icon.
  5. On removing the errant devices, messages then send okay.

Outcome

What did you expect?

An error message which actually explains what the problem is and how to fix it. From memory, the intended behaviour is to warn the sender loudly about the unverified device, but not block sending outright?

Also, if a message send does fail like this, i'd expect to be able to resend it - rather than have to copy the body and paste into the composer and hit send again, which just ends up with stacks of unsendable msgs.

What happened instead?

Cryptic failure with super-frustrating lack of retry button.

Your phone model

No response

Operating system version

No response

Application version

706

Homeserver

No response

Will you send logs?

Yes

@ara4n ara4n added T-Defect A-E2EE Encryption S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience X-Maybe-Release-Blocker labels Sep 16, 2024
@mxandreas
Copy link

Overall, this is by design. It is a stop-gap solution in a sense that eventually users won't see it because all of their devices are verified or if they are not, then those devices are excluded. Also, it was meant to apply only when you have explicitly verified the user with such devices - meaning it concerns a small percentage of current users who are very "strict".

Now, what is new and was realized yesterday, is that each person counts as a verified used to themselves. From a security perspective that makes sense - as otherwise a malicious homeserver could add a device on behalf of you and you would not notice. However, it was not considered when thinking about the overall current UX.

@BillCarsonFr
Copy link
Member

Maybe instance of matrix-org/matrix-rust-sdk#3973

@mxandreas
Copy link

Also, if a message send does fail like this, i'd expect to be able to resend it - rather than have to copy the body and paste into the composer and hit send again, which just ends up with stacks of unsendable msgs.

You can click on "Send anyway" for that.

@pmaier1

This comment was marked as off-topic.

@pmaier1
Copy link

pmaier1 commented Sep 17, 2024

Message fails to send outright, without any retry button

Did you see a red indicator on the message? Tapping it should give you the ability to resend. Or did you not see that at all?

Screenshot from 2024-09-17 10-23-49

@mxandreas
Copy link

For reference / visibility - here is the ticket to adjust the copy, in case this was your own device: element-hq/element-meta#2534

@ara4n
Copy link
Member Author

ara4n commented Sep 17, 2024

Did you see a red indicator on the message?

Yes

Tapping it should give you the ability to resend.

No. It popped up a "Send failed [OK]" alert, and nothing else.

@ara4n
Copy link
Member Author

ara4n commented Sep 17, 2024

it looked like this:

@ara4n
Copy link
Member Author

ara4n commented Sep 17, 2024

For reference / visibility - here is the ticket to adjust the copy, in case this was your own device: element-hq/element-meta#2534

It wasn't my own device. The repro steps were:

  • Be logged in as yourself (@matthew:matrix.org in this instance)
  • Verify a user (@matthewtest:matrix.org in this instance)
  • Log into that account on an unverified device (iamb or something, in my instance)
  • Discover you can no longer send msgs in any room where @matthewtest:matrix.org is present, with the "Sending failed" failure mode.

@mxandreas
Copy link

It wasn't my own device.

Got it, was just putting it here for visibility when it comes up with your own device.

The repro steps were.

FWIW - tried this morning myself and it worked as expected, if it helps with anything.

@pmaier1
Copy link

pmaier1 commented Sep 17, 2024

FWIW, ignore #3287 (comment). This was in the context of https://github.com/element-hq/crypto-internal/issues/370.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE Encryption O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Maybe-Release-Blocker
Projects
None yet
Development

No branches or pull requests

4 participants