Invite failed to warn me that the invited user might not exist

[DMRobertson]

Moved from matrix-org/synapse#12735. The original reporter was @felixx9.

Steps to reproduce

• User A wants to invite User B, but accidentially invites User C (which does not have an account / does not exist yet)
• User A does write a lot of confidential stuff into the newly created room
• User C (which might be a completely different person than User B) creates his account
• he sees the invitation & accepts it

Outcome

What did you expect?

• I would expect, that
  • I see this warning (but I didn't): Invites should check more thoroughly if a user exists #7137 within Client (e.g. Element)._
  • 
  • the room is encrypted
  • if not possible due to missing public key (?) of User C: Do not create the room
  • if created an encrypted: User C is not allowed to join, (unless invited again after account creation.)

What happened instead?

• User C can read the whole history, which was meant for User B
• the room is not encrpyted (even though the servers default setting says: encrypt all rooms)

Operating system

No response

Application version

Element Desktop 1.10.8

How did you install the app?

No response

Homeserver

matrix.yatrix.org, Synapse > 1.58.1

Will you send logs?

No

[DMRobertson]

In matrix-org/synapse#12735 (comment) I responded with:

• User A wants to invite User B, but accidentally invites User C (which does not have an account / does not exist yet)

This isn't a mistake that Matrix-the-protocol can prevent. Imagine user A had emailed a bunch of secret documents to user C --- there's no way to take those emails back once they've been sent.

However: the fact that you didn't see the warning sounds like a problem in Element Desktop.

the room is not encrpyted (even though the servers default setting says: encrypt all rooms)

Again, this sounds like it might be a bug in the client. Clients are responsible for sending an m.room.encrypted state event, which marks the room as encrypted (telling other clients which encryption algorithm to use).

I'm going to move this issue to the Element-web repo for them to investigate more.

[t3chguy]

Again, this sounds like it might be a bug in the client. Clients are responsible for sending an m.room.encrypted state event, which marks the room as encrypted (telling other clients which encryption algorithm to use).

@DMRobertson not if the Synapse config option encryption_enabled_by_default_for_room_type is in play

(even though the servers default setting says: encrypt all rooms)

[DMRobertson]

@DMRobertson not if the Synapse config option encryption_enabled_by_default_for_room_type is in play

That's fair. Shall we repurpose this issue for the report of the missing warning? I'll reopen the synapse one for the report of that config option not applying.

[robintown]

The lack of encryption is expected behavior whenever we encounter a user without encryption keys. There is currently a large red warning at the top of the timeline when the room is unexpectedly unencrypted:

However, the rest of the report still holds. I'm going to repurpose this issue (again, sorry 🙂) to track the lack of warning that the user might not exist, which looks like a possible regression.