Signal-ios: Urgent request from Chile: please allow contact removal from groups

[jtatria]

Dear Signal devs,

I'm writing with a humble but rather urgent request that you please incorporate a feature to allow the removal of contacts from signal groups.

I know this point has been raised several times (ie, here and here), and it seems to be the case that the development team has decided not to implement this feature. If this is not correct, and this feature is planned for some future release, then I apologize (but ask you instead to please speed up all eforts to produce such release).

I'm writing from Chile.

The current general uprising has produced an unprecedented intensification of systematic state policies of repression, persecution and human rights violations, mostly from the national police, in the streets, but also through widespread surveilance efforts (as documented, for exampe in the "pacoleaks" data breach a few weeks ago).

This has caused a frenetic and rather improvised activation of whatever social and political organizations are active in the country including, among other things, massive migrations of users from other chat platforms to signal. Most of this users do not have a technical background in security, and assume that the features available in other chat platforms will be present in signal.

The inability to remove contacts from groups, in a rapidly changing political context with clear and immediate threats to the physical integrity of our folks, presents serious operational and security problems that we have had to work around as there is no alternative availabe right now.

Lacking this option, when a contact in a group is compromised, the entire group becomes basically useless, as the operational costs of abandoning a compromised group and recreating it without compromised contacts are simply unafordable. Having to rely on the good faith of compromised users to voluntarily leave groups is patently naive.

I implore you to please reconsider this decision and implement the feature to allow the unilateral removal of contacts from groups.

I know this is a free software project, that is mostly developed by voluntary work and that in the end, the developers have the final say. I'm sure there are reasons for this design choice too (I could not find mention of them in the two issues cited above, but I always assume good faith).

But we have no other secure chat platform (and no real expecttion of adopting a different one), and no human capacity to submit a patch that addresses this feature or fork signalcore (which would require our own servers, that we also have no capacity to implement in a timely manner), so I come here to beg you to please take the operational and security needs of your users in Chile into consideration to provide us with a solution to this problem.

Thank you very much,
Jose Tomas Atria
Santiago, Chile.

PS: I submitted this issue on this platform as I could not find a different one. I saw some reference to a forum somewhere, but I couldn't find it. Also, I submit this issue against signal-ios as this seems to be the most active project and the two other issues in relation with this were submitted here. My apologies if this is not the right channel; in that case, please forward as needed.

[kenthinson]

First let me state I'm sorry for your situation. I see that the other issues were closed without an explanation other then "security" so I will try to elaborate a bit.

Second let me say I'm not a signal developer so I don't have a deep knowledge of this. I was just motivated to research the topic for you after reading your message. However I do write software and I did read some of the api docs before responding. Available here https://signal.org/docs/

As was stated in the other issues you liked. This is for security reasons. Just off the top of my head I can think of a few problems with adding the feature. 1. The server would then have to keep track of Who created the group. 2. who is a member of the group. 3. The server would also have to have the power to remove a user from the group. These are all attack vectors.

Signal is trying to move away from storing data about the users not to holding more of it:
https://signal.org/blog/sealed-sender/

So removal of a person from a group is probably not in the interest of the users of signal.

What I would purpose as a "meet half way solution". Perhaps there can be a button added that will create a new group and automatically select all contacts from a old group. A sort of "copy" a group function. Just copying over the contacts that were selected before. At this point a screen would ask the user who should be added or deleted before this new group is created. Reducing the workload of creating a new group.

Be safe Jose.

[NiklasBr]

That is a plausible explanation @kenthinson, but many things in life should be taken with moderation.

Security in short has always been about:

• Confidentiality – nobody other than the intended recipients should be able to read the content
• Integrity – the data should be complete and not change
• Availability – the data/service should be available and possible to use

By concentrating too much on the Confidentiality & Integrity part of the equation Signal is sacrificing:

1. The Availability part by making users not being able to kick away compromised contacts. Causing them to possibly abandon Signal altogether.
2. The Confidentiality part, ironically, because Signal is making it harder to avoid compromised contacts.

For example, to prevent car theft I could fill my trunk with cement and push it off a cliff into the cold ocean. Nobody will be able to steal it, it will be perfectly safe from thieves! Also, nobody will be able to light it on fire while on the ocean floor. Double win! ;)

However, this theft prevention is a significant hindrance for my actual usage of my car. I did put too much emphasis on the Confidentiality & Integrity of my car, but now I have very little Availability. Moderation is not always a bad concept with regards to security.

[kenthinson]

@NiklasBr I understand your argument. Everything is a tradeoff between convenience and security. My post is not intended to argue one way or the other. Simply to make it easier for people who don't code to understand the situation as the other linked issues did not elaborate beyond "security" before closing.

[NiklasBr]

I understood that your neutral position. I was primarily addressing the Signal devs, but can see that it was not entirely clear.

That said, this bug must be fixed.

I really don't understand the design decisions Signal have implemented with regards to data Confidentiality and data Availability (example), it ends hurting users in tangible ways. For me this has meant messages from dear ones lost forever (due to lack of backup), for Chilean protesters it can be much much worse than that…

[jtatria]

Thank you both for your comment. As @NiklasBr has argued clearly, this _is_ an accesibility problem, but this is not merely a "trade-off" as @kenthinson implied in his second comment: Accesibilty barriers imply operational costs, as I tried to explain in my post. Folks here _are_ using signal, with little awareness of the design decisions and without being security experts. What then happens is that a contact gets compromised, but the operational costs of recreating the group is such, that the contact is left in the group and the group becomes less useful, as either information that could be critical for the protection of others doesn't get sent, or it does get sent and compromised.

This is a given situation, it is what is going on right now, not an hypothetical use case, and it indicates how accesibility barriers erode security, because they lead to user carelessness.

Now: From @kenthinson's first comment, I understand this could be sorted out with some syntax sugar, yes? I.e. taking his suggestion of a "copy group" feature, but implementing it explicitly as a "remove user" feature: instead of presenting the user with "copy" function and then a picker to check which users to remove, why not just add a big red button on a contact's entry in a group that says "Remove User", that when pressed just recreates the group with the same name, and adds all members but that one transparently?

That sounds possible, secure, and easy to implement as it is merely a client change to add a UI feature.

[Mihahn]

This can be close with the introduction of groups v2 I guess.