search

element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
75 stars 12 forks source link

Don't allow multiple people in DMs #320

Open opusforlife2 opened 3 years ago

opusforlife2 commented 3 years ago

Description

I just discovered the horrifying fact that you can invite people to a 1:1 chat. I tested this just now and the 3rd user was indeed able to join after an invite. Why the hell is this allowed by the client/server/spec?

I have never seen this behaviour in any messaging service. This completely ruins the sanctity of personal chats between people, because a 1:1 chat can be converted to a group chat at any point, exposing the chat history.

This means that one can have no expectation of privacy on Matrix, and will always have to be guarded in conversations, because there is the (major or minor, depending on the persons involved) chance that the other user can invite a 3rd party to the chat and let them see the entire chat history between the first 2 users.

There is also the chance that a non-tech-savvy user mistakenly invites a 3rd user to the chat, resulting in the same problem.

Steps to reproduce

Describe how what happens differs from what you expected.

Neither user in a 1:1 chat should be able to invite another user. This functionality should be disabled for all 1:1 chats.

If a user creates a group chat by inviting at least 2 people, then the invite function could stay enabled.

Version information

For the web app:

opusforlife2 commented 3 years ago

This is allowed on Element Android as well.

t3chguy commented 3 years ago

This is intentional, for bots, personal assistants, etc. It is a social issue, not a technical one. You are both admins of the 1:1 room, you can do whatever you please.

Element uses the trusted_private_chat preset from the spec https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-createroom

Neither user in a 1:1 chat should be able to invite another user. This functionality should be disabled for all 1:1 chats.

This can be done if both peers agree to it, by setting the invite permission to Admin and then the peers changing their power level to below Admin.

t3chguy commented 3 years ago

This is allowed on Element Android as well.

Yup, an individual client forbidding it would be brittle given that a user could use a malicious client/API call to do it anyway.

opusforlife2 commented 3 years ago

This can be done if both peers agree to it, by setting the invite permission to Admin and then the peers changing their power level to below Admin.

Imagine me trying to get everyone in my social circle (consisting of mostly non-tech-savvy Whatsapp users) to follow these instructions, and them having to do this for their social circles as well. đŸ˜“

The point is, Matrix aspires to be the default messaging solution for everyone, doesn't it? This is a glaring UX issue for most people. I have to admit it is so for me as well.

Possible solution: A user should be able to create a "non-inviteable" room with another user (and it should be the default option, too) where such functionality is disabled.

If a couple of tech-savvy users want to add bots to their chat, then there should be an advanced chat creation option just for them.

t3chguy commented 3 years ago

Possible solution: A user should be able to create a "non-inviteable" room with another user (and it should be the default option, too) where such functionality is disabled.

This is already possible.

  1. Create a room
  2. Change permission to invite to Admin
  3. Invite your friend
  4. Drop yourself from Admin
t3chguy commented 3 years ago

If a couple of tech-savvy users want to add bots to their chat, then there should be an advanced chat creation option just for them.

What if you realise you want to have a bot after a few months of a DM existing? then you're stuck and have to throw your history away?

opusforlife2 commented 3 years ago

This is already possible.

I see. I think the opposite of the steps you've listed (where you promote yourself to admin, invite your friend and then make them an admin) could be the workflow for a tech-savvy user to create a bot-friendly room. But the default should still be that both users aren't admins and hence cannot invite anyone.

What if you realise you want to have a bot after a few months of a DM existing? then you're stuck and have to throw your history away?

This bot functionality seems to be a sticking point. Does the Matrix protocol differentiate between users and bots?

If so, one solution is that only bots could be invite-able.

If not, another idea is that it should take the consent of both users in a 1:1 chat before an invite is sent to a 3rd user/bot/whatever. So even if one participant does this out of ignorance or malice, the other user has the power to prevent it. How's that?

t3chguy commented 3 years ago

where you promote yourself to admin

You can't promote yourself to admin, only an admin can do that, if there are no admins in the room then it is simply not possible.

Does the Matrix protocol differentiate between users and bots?

Nope, and it doesn't have to be just bots, personal assistants are also a like usecase.

If so, one solution is that only bots could be invite-able.

Bots would still be exploitable to destroy your idea of privacy though

If not, another idea is that it should take the consent of both users in a 1:1 chat before an invite is sent to a 3rd user/bot/whatever. So even if one participant does this out of ignorance or malice, the other user has the power to prevent it. How's that?

That would be a suggestion for https://github.com/matrix-org/matrix-doc/ - not an individual Matrix client implementation

opusforlife2 commented 3 years ago

You can't promote yourself to admin, only an admin can do that, if there are no admins in the room then it is simply not possible.

The direct chat creation UI could show you an option to choose between staying an Admin (advanced option) and becoming a whatever-is-below-Admin (default selected option), with the consequences that entails.

Nope, and it doesn't have to be just bots, personal assistants are also a like usecase.

Okay, that's a dead end, then. Thanks for clarifying.

Bots would still be exploitable to destroy your idea of privacy though

Yeah, now that I think about it, not every user will make themselves completely aware of the consequences of every bot they invite.

That would be a suggestion for https://github.com/matrix-org/matrix-doc/ - not an individual Matrix client implementation

Sure, I'll open an issue there. But I hope you'll consider changing this at the app level as well, because MSCs seem to take ages to be merged, and it's not like Element has always been strict about including only spec-included functionality...

t3chguy commented 3 years ago

Changing it app-level would be exploitable, it'd prevent people being invited from Element but other clients/older versions would still be able to invite, which would give a false sense of security, also its basically unchangeable for existing 1:1s given that both Admins would have to perform actions.

Have left it in X-Needs-Product for the product team to review it

opusforlife2 commented 3 years ago

Oh. Okay. What about server-level?

t3chguy commented 3 years ago

Sure, but that'd be a discussion for the various server implementations

opusforlife2 commented 3 years ago

Alright. I'll open an issue there as well. Thanks!

ShadowJonathan commented 3 years ago

Can you please not title this "MAJOR BUG"?

opusforlife2 commented 3 years ago

So do you want to keep this open or close it until further developments in https://github.com/matrix-org/matrix-doc/issues/3197?

ShadowJonathan commented 3 years ago

Personally, i'd say to let this one open, it is a UX problem first and foremost, and an MSC (coupled with a few others) can solve it. If anything, this issue can be a marker that the problem exists.

opusforlife2 commented 3 years ago

Thanks for clarifying your thought process. It helps me gain an understanding of the project structure and processes and which level of the org I need to initiate or participate in discussions at.

You have to admit, having a spec, and a reference homeserver, and a reference client, all with different (but with some overlap) teams working on them makes for a pretty confused user trying to find an entry point into the discussions.

kate-shine commented 3 years ago

One possible option to solve one of issues with this feature would be to create the DM room with "history_visibility": "joined" by default (for newly joined users, the history is readable only since the point of when they joined)

Ultimately though, if you join a 1:1 chat with someone, you have to trust them to not disclose the chat content anyway. Inviting someone isn't the only way they can show the content to the third party.

opusforlife2 commented 3 years ago

Ultimately though, if you join a 1:1 chat with someone, you have to trust them to not disclose the chat content anyway. Inviting someone isn't the only way they can show the content to the third party.

Sure. But the most they can do on other apps is to physically show the chats to someone or share screenshots, which by their nature are very limiting in function. They can't actually fundamentally change the very identity of the 1:1 chat by making it a group chat, polluting its history and forcing the user to either abandon the chat history and open a new 1:1 room, or persuade or coerce the 3rd user into leaving.

Don't forget non-tech-savvy users doing this by accident. That is also a significant worry in my case. I suppose the rule of thumb is "If it's advanced functionality, don't just prevent them from pressing the button, don't even let them see that the button exists."

kate-shine commented 3 years ago

@opusforlife2 That's why I suggested disabling a history for newcomers as a quite effective fix to a part of this issue. It effectively fixes the problem of doing this by accident. Tech savvy people can change that default.

ShadowJonathan commented 3 years ago

@opusforlife2 That's why I suggested disabling a history for newcomers as a quite effective fix to a part of this issue. It effectively fixes the problem of doing this by accident. Tech savvy people can change that default.

It basically breaks the "promise" of DMs given by other platforms though, in the sense that I can start a DM with anyone and send messages to them immediately, if it's set to "joined", the other can only see messages for as long as they have joined, obscuring any message I'd have sent to them while they still had to be invited.

(Though now that I think about it, wasn't there an "invited" history visibility state? That someone could read up until the point they were invited, I might be wrong)

opusforlife2 commented 3 years ago

(Though now that I think about it, wasn't there an "invited" history visibility state? That someone could read up until the point they were invited, I might be wrong)

There is indeed such a state: "Members only (since they were invited)"

I think (though I'm not fully certain) that Whatsapp works this way as well. You see all messages from the point you're invited.

reivilibre commented 3 years ago

Yes, a potential solution to this would be to use the invited history_visibility state.

It's a matter of opinion whether that should be the default, but you of course still have the choice of setting that manually when you create a new room.

I think I'd be in favour of making that default, but it's a matter of taste, fundamentally.

There is also the chance that a non-tech-savvy user mistakenly invites a 3rd user to the chat, resulting in the same problem.

This is the fundamental problem. If you don't trust the other user in the first place, they could easily just give screenshots/logs of what's been said, so not sure that changing this would be effective against hostile people.

opusforlife2 commented 3 years ago

but it's a matter of taste, fundamentally

I don't think it's a matter of taste. It would be great if every social group had an IT expert guiding it, which could neatly bypass this problem. But Matrix will be used by entire groups of novice users who never stray from the defaults, and for them this is more like a security loophole.

You can even craft a headline out of this: "Glitch in the Matrix: Users discover app's default settings can potentially reveal your entire 1:1 chat history to a 3rd party".

reivilibre commented 3 years ago

but it's a matter of taste, fundamentally

I don't think it's a matter of taste. It would be great if every social group had an IT expert guiding it, which could neatly bypass this problem. But Matrix will be used by entire groups of novice users who never stray from the defaults, and for them this is more like a security loophole.

You can even craft a headline out of this: "Glitch in the Matrix: Users discover app's default settings can potentially reveal your entire 1:1 chat history to a 3rd party".

For someone who doesn't stray from the defaults, though, there are two exceptions to that:

Now, as a point of preference, I probably would still prefer invited to be the default, but it's not quite as shocking as you make it out

opusforlife2 commented 3 years ago

xD Naturally, I was sensationalising the headline. That's the norm these days.

The risk is limited to a 3rd user whom you've added, of course. Thank the lord Arceus that E2EE prevents any random passerby from reading your messages, at least.

they wouldn't invite someone else in the first place

Considering some of the non-tech-savvy people I know, they would get spooked by the fact that the possibility exists at all, and some may even ditch the platform for poorer alternatives.

ShadowJonathan commented 3 years ago

Note: Setting it to "invite" would be a compromise, because it still leaves the migration to only show you "new" messages.

opusforlife2 commented 3 years ago

In the 2nd-user-consent scenario, the migration process could include an automatic step where an alert or notification is sent out to every user in the "migratee's" contact list, something like "X has migrated to Element Home. For security reasons, you need to provide your consent before X is allowed to view your past messages from their new Home."

karlabbott commented 2 years ago

So we've had a discussion about this in product and we are in favor of making the default status for dms to be "Members Only (since they were invited)" which is what @reivilibre pointed out not far above.

Our internal teams are looking into what needs to be done to better shore up the definitions of dm versus room and handle this better overall. That said, that work is still a few months away and will then take some time for implementation once we start going down that road.

So as a good compromise here, setting the history_visibility state to invitied seems like the best way forward for now and in a few months, we'll address this more fully.

Approving the history_visibility default of rooms to be invited with this comment.