Feature Request: Group Administration

[phime42]

TextSecure groups lack the possibility to remove participants after they were added.

[n00b42]

Agree, would be nice to have this option

[generalmanager]

Well groups aren't controlled by one administrator or the original creator, that's why everybody can invite new users, but you can only remove yourself from the group.
But we can ignore certain users (by not showing their messages) just fine (#222). Or we mute the user/group for however long we like (#801). In any case, this would be a duplicate, we just have to figure out which issue it duplicates.

[phime42]

Well, this makes groups almost useless. If a group is created and everyone can add more members without the possibility for the administrator to remove them, there will just be happy trolling, inviting "friends" for fun, messing around. That makes serious messaging in groups (i.e. for learning groups of about 10 people in university context) impossible.

[generalmanager]

I guess that depends highly on the kind of people you interact with. I read (I think on moxies twitter), that they are about to release a detailed blog post about the group feature - so maybe we should wait until that happens and we know what is supported by the protocol and what isn't.
Then we can talk about further changes, like administrated groups. I personally prefer the current implementation - when the issues I mentioned are integrated, you can always block/mute people you don't want to read from.
Currently you can add new users by clicking the settings icon in the top right from the group chat -> update group -> add member.

[moxie0]

@LOTP : We had to make group administration a distributed function, rather than having a single authority or single source of truth. That's the tradeoff for not having the server administer group membership.

I would imagine that members of a group for a specific serious purpose wouldn't add members who weren't involved in that same project, but maybe you're correct. @Lindworm's suggestion of individual blocking or muting is probably the best we could do.

[phime42]

@moxie0 : Maybe we could add both? The current system based on the sanity and discipline of every group member and the centralized modell? Maybe as "Open Group" and "Administrated Group"?
Because sometimes, if you don't want people to be in a group, you don't just want to mute them. You also want them not to see what's going on in the group, maybe because this person turned out to be not trustworthy (imagine that: in my university many scientific groups are organizing theirselves with WhatsApp Groups. Interns and guests are added for the time of their visits in order to keep them informed about whats going on, what has to be done and where to meet for lunch with the group. Now this intern/guest leaves the scientific group - if he can't removed from the group, he receives information he should never get, and the circle of people that are always well informed about whats going on is going to grow, making this group feature not usable for those applications).

[moxie0]

@LOTP The only thing you can do in that case is create a new group without that person in it (or ask them to leave voluntarily). We might be able to add centralized group management in the future, but at the moment I don't want to put us in a position where we could get subpoenas for this information from law enforcement.

[jocelynthode]

@moxie0 And would it be possible to just give everyone the permission to kick people from the group ? Because for example, today I had a problem with my export/import and I wasn't able to leave the group, so we had to create an other one because I couldn't join the existing one since my phone number was already listed, couldn't leave it as I wasn't in it anymore and they couldn't kick me.

Even stranger, when They sent some messages, I was able to read them but the group was like a ghost one. I could write in the group nor could I see group member or leave the group.

[generalmanager]

@jocelynthode

And would it be possible to just give everyone the permission to kick people from the group ?

Yeah, that doesn't sound like a good idea. Do you think the trolls in @LOTP's scenario would'nt kick you out of your own study group "for fun"?

[jocelynthode]

@Lindworm I don't really. You can hope that people are bit more mature than that. Anyway I'd much prefer being kicked (which everyone can reinvite you) than being forced to recreate a new group when the problem of keys happen.

Though I understand that usually and if the export/import feature was working correctly it shouldn't be an issue.

I still think we should add at least a warning for this export feature.

[johanw666]

@moxie0: it would be possible to store the group settings, including who is admin or not, locally. That would keep you safe from subpoenas because you don't have that information and still alows for group management by admins.

It would not protect against someone who modified the TS source to make himself admin, but that's a lot less likely attack for trolls than simply not unsubscribing.

[msappir]

Experiencing a difficult scenario right now which apparently hasn't been taken into account, where this design decision is a real problem.
Basically, there's a group where a few people discussed some sensitive stuff. One member, it turns out, did not protect their data with any password, and then their phone got stolen. The group's entire contents and membership are now possibly out there and accessible to potential attackers.
Granted, everyone should have had a password before using the app for sensitive communications, but passwords are currently optional, some people are not security-conscious, and here we are. Being able to remove our friend's account from the group would save all of the participants a lot of worry and possibly real trouble.

[smichel17]

edit: I've since changed my mind about this solution. Updates further down the thread.

It's a bit awkward technically, but here's one possible solution. It's essentially a UI for people to re-create a group without a person, preserving history.

Scenario: There's a group with 4 people, p1-p4. p1 wants to kick p4.

UX:

• p1 goes to administer the group and chooses 'kick p4'.
• p2 and p3 receive prompts saying p1 started a vote to kick p4. A kick vote must be unanimous. This vote is not visible to p4. [KICK / CANCEL]
• if either p2 or p3 decline, the conversation continues as normal, with no record of the kick vote. If it succeeds
  • p1, p2, and p3's screens show a line about p4 being kicked (same style as when a person is added)
  • p4 sees p1, p2, and p3 leave the group.

Technical:

• When p1 sends the request, a new group is created containing p1, p2, and p3. Like the original messages used to sync android and desktop, it's not visible, only used by the client to trigger the kick confirmation message.
• If someone declines the vote, everyone leaves the new group. The person who declined does not leave until every other client has either left or voted not to kick (since that might happen async).
• If the vote succeeds, p1, p2, and p3 leave the old group, and their clients import the old group's history and metadata into the new group.
• p1, p2, and p3 are able to start a new vote to kick (even another vote to kick p4) while the previous vote is active. No way to stop that.
  • If they do so, their client will first send a decline vote to the existing group, and will not initiate the new vote until the previous one is dissolved (this is why the client that declines must be the last to leave)
    • Optional UX: display a message that the previous kick vote is in the process of being canceled, please wait.
  • If p4 initiates a kick vote (say, to kick p2) while the previous kick vote is active...
    • If p1 or p3 vote no, the vote is canceled like normal
    • If p1 or p3 vote yes to kick p2, their client will first vote no to kick p4, then vote yes to kick p2 after the kick-p4 vote is complete.

---

I will note, this does not solve the case of "friend X added people to the group and now we can't get rid of them", since friend X would need to vote to kick the new person as well. It does allow the removal of inactive users.

[gith-account]

Ignoring a user instead of removing him from a group does not keep that user from reading messages (and responses to messages) in said group. Muting a user or a group does not really solve the problem, either. Wanting a certain user removed from a group does not usually mean that group members no longer want to hear from the group in general, nor does it necessarily mean that group members want the user muted in private conversations or other groups.

Example given: a group of colleagues to discuss job related tasks. If one of the group members leaves the team or company, that person should no longer have access to the group, but people may still be friends with that person and keep communicating in private and in other, non work-related groups.

Rebuildung large groups whenever a member is supposed to leave, is not a viable option.

Why can the creator of a group not hold some key locally that identifies him as administrator of that group? Whoever has the key can alter the group. If someone without admin status wants to add a member, an amdin has to approve it. If the key is lost, the group can no longer be altered. However, if all users leave a group, it will be closed. So you could give up a group, if that happens.

[TimesEnemy]

Greetings.

Really not sure about the logic in posting to a closed thread...

This is a complicated concept. I originally was going to just say, "me too," but that obviously went out of control.

I agree with gith-account that a central admin should be the sole person responsible for the thread/group. The current solution of requiring members to unsubscribe or leave the group is not that great, but I understand the simplicity of it.

As a safety, and to complicate things, there could be a mutiny feature, which would allow either a majority or a complete vote to "kick" the admin and assign a new admin. The admin would not be allowed to vote. This would also provide a backup if the admin loses their device, or just goes silent for an extended amount of time. In situations where there is an even amount of recipients or voters and a tie occurs, an automatic re-vote would take place with a notification that there was a tie, then if the tie remains, no change would take place regarding the admin. Any user, including the admin, could initiate a mutiny vote. (Would be good if there was also the ability for the admin to voluntarily step down and assign a successor.) All mutiny votes would require a single non-admin recipient be listed as the pending new admin. The admin would not be kicked from the group following a successful mutiny, they would simply be demoted. If the new admin decides to kick them, so be it.

Something that would push into another feature request would be the ability to remotely destroy threads. If a device is lost or stolen, then the authentication to remotely kill the old instance would be the private key (from a backup). No backup, no remote kill. Related threads: #1764, #5713, #643

Group conversations would have to provide some type of secondary/tertiary key, unique to that thread. The necessary portion of the key to authenticate would need to be sent to the admin of the group. In a case of a mutiny, the keys would need to be regenerated by all members and passed to the new admin (the old admin would have bad keys and could be purged by the old admin when they next do a backup). This key would obviously also have to be included in any backup done by the active admin. (I am not sure how groups are currently encrypted ... using each recipients individual keys or by creating a new key ... if via a new key then a third key would be required for this feature.)

I mention this remote kill feature because it is applicable to a group discussion in which sensitive information is shared, but a user is removed from the group, or a user loses their device. This is also applicable for all recipients of a group that are kicked from the group. The admin could then initiate a member validation check in which selected members optionally have their conversation history wiped, then are kicked from the group. I say, "optionally," to allow the admin the option to wipe their conversation or not, as sometimes it may be acceptable for the kicked recipient to retain the conversation history to that point. If it is not acceptable for them to retain it, then the admin would make that decision when kicking them. This could not be changed once the kick is completed. Related threads: #5455, #5594

Oh yeah, the other aspect of group administration which is a wee bit frustrating is that anyone can force anyone into a group. I would like for membership to be voluntary rather than mandatory. Well, as I am typing this I just realized I have only added people to a group and have never been added to a group ... so it may be voluntary currently. If not, see first two sentences of this paragraph. :)

With regard to non-admin's making kick requests, these can realistically just be done directly, outside of the group thread. For instance, if USER1 wants to kick USER6, rather than create a new capability within the group administration for this type of request, USER1 could just directly communicate, outside of the group, with the ADMIN and say something like, "Yo, USER6 is a lame anchor, I recommend you kick them."

FWIW, i may be open to publishing this post in hardback for an early release next summer ....

[smichel17]

@TimesEnemy That seems way too complex, not only to develop but also as a Signal user. Reading over my previous post, I think that's also waaaayy too complicated for Signal. Here's something simpler: Give each user the option to "fork" a group.

@moxie0 @liliakai Would you consider this as an alternative to centralized group administration?

UX:

1. Enter group
2. Choose "fork"
3. Select a subset of participants from the group, optionally change the group name or picture
   • Almost the same UX as current "update group" screen.
4. Choose "continue"
5. Group shows that you forked it (same style as when you add someone)
6. A new group is created with participants you selected in step 3
7. Each person's devices locally import saved history from the original group (which is not changed in any way)

Backend:

It's exactly like creating a brand new group, with one twist: The "Group was forked" alert contains an ID number (presumably something like a signed hash of the group's current metadata). When you create the new group, your message includes the same ID number. That's how devices know how to import history.

I'm not sure if we have a guarantee which message will arrive first. If there's no guarantee, it's easy enough to check for a matching ID upon receipt of either message and populate the history retroactively if necessary.

---

Use cases:

• Someone uninstalls signal and the group is getting error messages
• A device is compromised
• Someone is spamming the group
• A subset of people in the group want to start a discussion less generally relevant
  • Eg, my friends have a group chat; I fork the group to plan an event.

Other pro: Doesn't add any new abuse cases, since it's really just a shortcut for existing functionality.

[haffenloher]

@smichel17 interesting idea, could be a pragmatic solution to many problems. I wonder whether the github-y "fork" terminology would be understood by the user, though

Someone uninstalls signal and the group is getting error messages

should no longer happen due to #5318

[smichel17]

@haffenloher

I wonder whether the github-y "fork" terminology would be understood by the user, though

Definitely not the best terminology; In addition to what you mentioned, it's not even really consistent with what it means to fork something here -- when you first fork something, it's identical to upstream, then diverges as you develop; with this feature, the new group gets changed right away.

I used it because I knew it would be immediately understood by this crowd. If OWS is interested in iterating on this direction, we can do a brainstorm for better words.

should no longer happen due to #5318

There are still prominent error messages on desktop. That said, it's a good point that this is better addressed by improving how clients handle unregistration than introducing this as a workaround. I think the other use cases still stand.

[smichel17]

@moxie0 @liliakai @michaelkirk A version that adds even less complexity/change:

• From the current "Update group" screen, allow users to remove others from the group
• If the user chooses to do this, show a message on-screen that this won't kick anybody out; it'll start a new "fork" of the conversation without those people.
• Create the fork in two steps. Step 1 uses the process above; step 2 adds any participants (a normal group modification)

[Trolldemorted]

@smichel17 I fear with the signal server dropping messages when a device's queue is full, forking groups will lead to chaos and unknown groups on devices that are not always online.

Do we have any information how WhatsApp handles it?

[smichel17]

@Trolldemorted I didn't consider that before. However, I don't think it will be a problem. Take the use cases I listed above, where N is the number of people in the original conversation and M is the number in the fork:

A device is compromised

Group is forked (M+N), then everyone continues using the new group uninterrupted and with no behavior change.

Someone is spamming the group

This was already a problem, but it's still only M+N for the fork and then (N^2)/2 as each person leaves the original group -- that's much less than a spammer could flood the group with, and only N different from manually recreating the group from scratch (or maybe better, if there's no one person who can add everyone to the group, requiring it to created and then modified several times). So it's bad, but overall better than the alternative.

A subset of people in the group want to start a discussion less generally relevant

This one seems like it would be problematic (after all, you could get many groups popping up all over the place!), but actually is a net decrease in the size of someone's queue. Each fork is M+N, but after that, you save N-M on each message you send in the new group that you would have sent to the main group. It is possible that having more groups would cause the behavior change of chatting more, since you're not worried about flooding the main conversation.

[smichel17]

@\all Do you think this idea is good enough for me to open a new issue about it rather than continuing discussion in this closed issue? Any other concerns we should flesh out before doing so?

[Trolldemorted]

@smichel17 You missunderstood, the queue won't be full due to the messages of the actual fork, but due to normal messages being sent.

My Signal-Desktop's queue is full every weekend, so both messages and group updates are dropped. If the fork messages get dropped, my device will have received no group update from the new group, consider the old group valid, and receive messages from an unknown group (since the other members consider myself a valid member).

Having a single or a set of administrators is the only way to go, i think.

[smichel17]

@Trolldemorted isn't that already a problem if you get added to a new group over the weekend?

[Trolldemorted]

@smichel17 of course it is, that is why i would like it to not get worse.

[smichel17]

"I have a leaky faucet, so I'm going to use hand sanitizer instead of washing my hands." -> This is a decent stop-gap measure, but really, we should just fix the faucet so you can wash your hands again.

"There's a serious drought, so I'm going to use hand sanitizer instead of washing my hands." -> This makes more sense as a long-term solution. Not necessarily one we're happy with, but it might be the best option available.

@Trolldemorted That is to say, I think we should prefer a centralized solution if and only if your problem is unfixable. Otherwise, we should prefer this solution, but wait to implement until your issue is resolved.

[Trolldemorted]

Well, i do not even know if it is considered a problem or as "working as intended", and i do not think there is an easy way to fix it either.

But with potentially dropped messages, out-of-order delivery, and unstable clients the centralized way is the only one to go imho. Signal's groups are async or otherwise damaged every few weeks for me, adding more complexity that relies on stability is no way to go.

[smichel17]

Otherwise, we should prefer this solution, but wait to implement until your issue is resolved

edit: sorry, that was cheeky. What I'm saying is -- Imagine your issue didn't exist. Which solution do you prefer, the centralized or decentralized one?

Now jump back to reality. If your previous answer was "decentralized", then our goal should be to first resolve your issue, then implement the decentralized solution.

Just because groups are unstable right now doesn't mean centralized is the only way to go, period.

[johanw666]

On 05-10-2016 22:24, Trolldemorted wrote:

But with potentially dropped messages, out-of-order delivery, and
unstable clients the centralized way is the only one to go imho.

It does have serious privacy issues: we just learned yesterday that Open
Whispersystems was subphoenaed with a gag order about some account. In
the current system, they fortunately could not deliver any usefull
information about users.

Met vriendelijke groet,

Johan Wevers

[2011]

Going to ask this here just because I can (without opening a new bug).

Is there any merit to automatically removing users from groups when they unregister (of course, they should leave any groups they belong to on their own, but people often forget)?

[Trolldemorted]

@johanw666 with centralized i did not mean centralized on the OWS servers, but rather "one device is the admin device which is the single source of truth distributing snapshots/states with a logical clock"-centralized.

[sebastianst]

Maybe you could implement some kind of threshold administration: When creating a group, you can set a threshold parameter n. Any member can commit an administrative action to the group, like deleting or adding a user. All other users are presented with the to be committed action and can either accept or decline it. If any user declines (or m users decline, a second parameter), the action is cancelled. Or if n users accept, the action is executed.
You wouldn't have a single authority and no single users could mess around.
In case of the remove user action, the user should only be presented with the accept, but not the decline option, so that trolls can be removed. (If he accepts, of course, remove him immediately.)
As typical parameter choices I imaginen=3 (and maybe m=2).

[mrdomino]

FWIW this seriously limits the use of Signal for organizations -- it exacerbates things if there's ever a departure on bad terms.

Any of the above solutions would work for this. Proposed solutions are obviously of limited value compared with code, but yet another possibility would be to implement the centralized group management and make it possible to create both kinds of groups: self-managed / un-subpoeana-able, and centrally-managed / subpoeana-able.

The trade-offs make sense on an individual level -- if you want a centrally-managed group, it's probably easy to discover through other channels who's at your organization. I don't know if they make sense overall -- how easy is it to observe the existence of self-managed groups, and do they all become more endangered if less people are using them?

[johanw666]

@mrdomino : "centralized" does not have to be "registered at a server". It can also mean that one device is acknowledges as the "master" device in a group, and this function is preferably transferable. I know that defence against maliciously adapted clients would be hard, but if you are willing to take some risks there that point it would function just like WhatsApp groups but without the privacy issues of administration at the server.

I do admit this would require much carefull design and discussion to prevent unmaintanable code crawling with ad-hoc patches ruining the design.

[dirmeier]

[trmendes]

Got a friend in a group who had her phone stolen in Colombia and the person who still the phone is now reading all the messages. It would be nice to have a way to remove that number from the group chat.

[freekvh]

Why not allow anyone to remove anyone in groups? Most groups are with friends, it's not like I can't throw a friend out of a place in real life. I'd just be anti-social, but allowing for it may sometimes be handy.

[FelixHen]

just allow removing. No need for admins. everyone is admin.

[sebastianst]

@FelixHen agree. If someone misbehaves and kicks out randomly, they'll be kicked out themself. People who have been kicked out accidentally can also easily be added back, so there's no danger to give everyone the power to remove others.

[freekvh]

The way it is now makes (somewhat) sense for a channel, not for a group of a couple of people all knowing each other. Just name what we have now a "channel" and introduce an "everybody is admin" group-form for smaller groups.

[2-4601]

As explained in the clean up issue (#7598) discussion about feature requests should take place in the forums. You can use the forum with your GitHub account. There's an existing thread there about improving Signal groups https://community.signalusers.org/t/improving-signal-group-chats/979