Prevent adding additional users to personal messages?

Hi there. I’m seeing concerns from users about the ability to add additional users to a personal message topic who can then see the entire message thread, resulting in a possible intentional or unintentional doxing if somebody posted private information earlier in the thread.

The expected behavior for these users is that added users would only be able to view the personal message topic from the point where they were added. This sounds ideal to me too, but hard to implement from the Discourse point of view.

I wonder if it would be feasible in the short term to disallow adding users after a personal message topic is started, possibly only allowing removals?

4 Likes

Hi,

General question about the messaging feature, noticed that it seems any members of a private message thread can add new members, is there a setting to change that?

I heard this may be intentional for the sake of anyone being able to add a moderator to these if that is necessary, because if they are encrypted moderators won’t be able to access the messages even if they are flagged.

However it can be problematic if someone ads non-moderator users to a thread without asking about if the rest of the members of a talk are ok with that first.

Main question is if there are already settings that can be adjusted for permissions on this or if it could be developed as a new feature that default is only the person who initiates a private message can add new members to that, or alternatively even they can’t do that, with one exception being for requesting moderation for flagged posts.

1 Like

ah yes, this has come up before including a topic you created. I don’t believe there are currently settings or a mechanism for controlling the addition of PM recipients, other than the max_allowed_message_recipients and the min_trust_level_to_allow_invite settings.

2 Likes

Thanks for your reply, forgot I had asked this before but there were no answers.

The other day someone was (it seemed to me) arguing in a PM with a moderator on here. The PM had been initiated by the moderator. The non-moderator user invited me to the message. It felt odd that they were able to do that. I’m also aware of cases where it’s convenient to allow users who didn’t initiate a PM to be able to invite other users to a PM. Instead of a site setting that prevented PM participants from adding other participants to a PM, it might be good to have a default value that could be overridden on a per PM basis.

4 Likes

This is one of those things I like to think falls under forum etiquette (as opposed to explicit rules, which one could very well make a rule specific to adding recipients if they felt it was needed) - I think it’s good etiquette to ask the current group message participants if it is in fact ok to invite others.

I like this idea. Not sure how it would be implemented, like maybe a checkbox like the official warning checkbox staff have? (an allow group pm setting I suppose :thinking: )

hah, Yea I can think of some awkward situations where I was invited into conversations where I felt like perhaps it wasn’t appropriate for me to be there.

3 Likes

It can be an etiquette thing, depending on the talk however it may go beyond that.

Anyone can leave a message thread and some people can boot others out also.

This same thing happened to me. I wasn’t sure about mentioning that out here on the forum maybe moderators will comment or moderate this.

After this I did mention to the moderator that I had advised the user ask permission first before doing this, but they felt that wasn’t necessary because the topic was originally a thread they started that was taken down to be a message instead.

I do think it’s important to note that they aren’t actually private messages. They are called Personal Messages and are not necessarily “private” in the way that some people believe. They work great for group discussions and my forum staff uses this feature often. I know many of our forum users do too because it’s very cliquey LOL.

2 Likes

It seems like a good illustration of the problem. Essentially, I was given access to something that wasn’t my business.

I’m not sure either. Especially if the aim is to not introduce too much complexity into the UI. For the cases I’m thinking of, it could be controlled as a group setting, but I don’t think that would resolve the issue that’s mentioned in the OP.

2 Likes

Right, sort of like an unlisted thread don’t show up on home page or search but still not secure.

I think if you can limit the examples to strictly general terms then it would be relevant to the discussion. However, discussing specific details of the user and/or situation would likely be inappropriate. Please be mindful of this. :pray:

I agree. I think in those cases it can put the person invited into the moderation discussion in a really awkward position, and I would not recommend it as an example of good forum etiquette. If there was a toggle I could switch to disallow it I think I would use it when I created those kinds of PMs.

There seem to be a few topics where this has been brought up so I’m going to see if I can tidy them up so we can focus the discussion in one place. :+1:

4 Likes

Alright thanks, I agree toggle switch sounds like a good idea.

There is also the personal chat feature which is a little different, I haven’t used that much don’t know how that works.

Interesting idea. So any one of the participants could hit the “No additional participants” button and only the person that activated it could deactivate it?

That’s where it gets tricky. It would probably make sense to just give the ability to the person who started the message or staff members. I think that would take care of all the scenarios that are listed in this post: Prevent adding additional users to personal messages? - #3 by Lilly.

The case that seems straightforward to me is for Official Warning PMs. For that case, I’m not sure a toggle is even needed.

It’s worth noting that the ability for any user to add users to a PM is very useful when Discourse is used as a support platform. It allows the person who’s requesting support to add members of their team to the PM. This makes life somewhat easier for the support team, because it puts the onus on the people they’re supporting to make sure that the wrong person doesn’t get invited to the PM.

I wouldn’t recommend that, no.

For someone creating a new message thread, it could be an option then, but may be best for that option be restricted to only trust tier #4 staff members/volunteer moderators.

One last technical question; don’t know if anyone may know what happens to messages when there are no longer any members of a conversation? Are these automatically deleted or archived somehow?

When all members are removed from a PM it ends up in kind of a weird state. It’s not archived or deleted, but it’s not displayed anywhere in the UI that I’m aware of. Admins can still access the message if they know the message’s ID. Here’s an example:

An admin could add users back to the message if they wished.

2 Likes

Interesting, just tested this and the message thread was still there with the same url after everyone had been removed from the message. There are restrictions on who can remove others from a message, that seems to be only who started the message or an administrator/moderator.

This seems like something that may be more developed in the years ahead. If this happens without the url being recorded first than there would be no way to access/delete the message thread, except maybe there is some other way.

With the feature to invite new members to a talk, there is no formal invitation given with oppourtunity for someone to choose to either accept or decline an invitation.

If that could be further developed to do that, maybe there would be a way to incorporate system so that say: random user 478 wants to invite someone to a talk: this will notify other members that they have requested that invitation be sent out, but that might take a couple days for the mail service to deliver.

Discourse seems to go really fast but sometimes slowness is superior.