I was worried about sharing broadly and leaking info from 1 contact to another, but it seems like the Signal team did all the right things here. When you create a story you can make it a group story or not. If you do not make it a group story, reactions and replies to stories get sent to you over your 1:1 chats and not shared across other recipients of the story. If you make it a group story, and share it with multip…
I'm still of the opinion that encrypted private group chats are an impossible UX problem (1:1 chat is fine). But if I were to trust anyone to find a way to do it properly, it would be Signal.
System level some use additional connections/recipients for spam/moderation and the moment you allow any invisible/visible group users in, there is a massive potential for an exploit.
Additionally you have the potential for forking off messaging to other users at the system level for either oversight or spam/moderation/other. Some of the compromised systems out there use this very well.
A sneaky way some of these "secure" messaging apps are also doing this is ghost participants in the chat that can essentially syphon off the messages even without a compromised client. The ghost participant is always under the guise of moderation or anti-spam or telemetry or some other proprietary shim.
> The code shows that the messages were secretly duplicated and sent to a “ghost” contact that was hidden from the users’ contact lists. [1]
Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats.
Other areas that "secure" messaging apps have holes in is the anti-spam/moderation systems that need to view messages and in the clients themselves who have access to the unencrypted content. This is also taking place in other client apps as well: VPN, password managers, extensions, wallets, even build systems and more. Many like VPNs have logs sent elsewhere but deleted locally -- access to entire machine and all network access. People are way too trusting of "secure" systems/apps that are very common today based on trust.
All of these apps/systems would pass code checks, reviews, security inspections and essentially be encrypted/"secure" though a copy is sent off to another area for review. At runtime the leak is in the direction of the data.
Then you also have governmental oversight that opens up holes that can be exploited.
On Ghost Users and Messaging Backdoors [2]
> to add a “ghost user” (or in some cases, a “ghost device”) to an existing group chat or calling session. In systems where group membership can be modified by the provider infrastructure, this could mostly be done via changes to the server-side components of the provider’s system.
> I say that it could mostly be done server-side, because there’s a wrinkle. Even if you modify the provider infrastructure to add unauthorized users to a conversation, most existing E2E systems do notify users when a new participant (or device) joins a conversation. Generally speaking, having a stranger wander into your conversation is a great way to notify criminals that the game’s afoot or what have you, so you’ll absolutely want to block this warning.
> While the GCHQ proposal doesn’t go into great detail, it seems to follow that any workable proposal will require providers to suppress those warning messages at the target’s device. This means the proposal will also require changes to the client application as well as the server-side infrastructure.
> (Certain apps like Signal are already somewhat hardened against these changes, because group chat setup is handled in an end-to-end encrypted/authenticated fashion by clients. This prevents the server from inserting new users without the collaboration of at least one group participant. At the moment, however, both WhatsApp and iMessage seem vulnerable to GCHQ’s proposed approach.)
[1] https://www.vice.com/en/article/v7veg8/anom-app-source-code-...
[2] https://blog.cryptographyengineering.com/2018/12/17/on-ghost...