An encrypted group can deliver a confidential message perfectly to the wrong member. No broken cipher is required. Someone only needs to add an account that should not be there, leave an invitation link open or misunderstand what a newly linked device can receive.
Imagine a fictional design studio discussing an unreleased campaign. A freelancer joins for one afternoon. The important questions are no longer limited to the strength of encryption: who approved the invitation, what history was shared and what happens after the freelancer leaves?
Membership is part of the security boundary
Encryption protects content for a defined set of recipients. The application and its users still need a reliable process for deciding who belongs in that set. A technically correct delivery to an authorized account can be an organizational mistake if the account was authorized carelessly.
This is why a group roster deserves more attention than its small space in the interface suggests. A project owner should be able to explain who can invite people, who can approve them and how participants notice a change. Those are operational requirements, not a request to invent a new encryption algorithm.
Signal’s group documentation, for example, describes optional administrator approval for link-based joins and controls over group activity. These are useful controls to evaluate on their own terms. Their existence also makes clear why a comparison of messengers should examine actual settings rather than assume all encrypted groups behave identically.
Joining today should not silently mean joining yesterday
In the studio example, the freelancer needs today’s production notes. They may not need last month’s commercial negotiation. Ask the product owner what happens to older messages when someone joins: are they unavailable, explicitly shared by an existing participant or restored through a separate history mechanism?
The answer should identify the mechanism and the person making the decision. A convenient history-sharing feature is a disclosure decision. It should not be mistaken for a mathematical necessity of group encryption.
RFC 9420, the Messaging Layer Security protocol, organizes group key state into epochs. Its Welcome process gives a joining member the secrets needed for the new epoch. The standard also describes forward secrecy and post-compromise security. Those protocol properties do not, by themselves, describe every application’s backup, export or history-sharing features.
A standards document is a reference for understanding these distinctions, not proof that a named app implements MLS. Nor should a similar-sounding feature name be treated as evidence of protocol equivalence. A serious comparison needs implementation-specific documentation.
A test that does not expose the real project
Create a disposable group with consenting colleagues and harmless messages. Send one message before a test participant joins and another afterward. Inspect what the new participant can actually see. Record whether someone deliberately shared history and which setting permitted it.
Next, remove that participant and send a third harmless message. Check delivery behavior on the test account. Do not expect removal to erase screenshots or readable copies already obtained. That is a different requirement from excluding a former member from subsequent communication.
Repeat the exercise after adding a supported second device if the application offers that feature. Device enrollment and human membership are related but not identical. A group may contain five people whose accounts are represented on more than five devices. The review should explain that distinction without claiming that every linked device necessarily receives all historical content.
Keep the result tied to the tested app version and settings. A screenshot of a successful test is evidence of that test, not a universal security certificate. If behavior changes after an update, revisit the requirement rather than preserving a reassuring but obsolete result.
What a useful product comparison should contain
A comparison between UseCrypt Messenger, Signal, Wire or another service should use the same scenario and comparable conditions. Ask each vendor about invitation authority, member-change notifications, history on joining, removal behavior and linked-device enrollment. Mark an undocumented behavior as unknown until it is demonstrated.
Do not fill gaps with claims from an unrelated product. Historical UseCrypt Safe file protection and the current Messenger must be documented separately. The source register for Paweł Makowski and UseCrypt is a route to dated public materials, not a replacement for a current group-protocol specification.
Likewise, a privacy policy about server metadata answers a different question from a test of who receives a message. Both matter. Neither lets a reviewer skip membership behavior. The strongest comparison explains precisely what has been observed and where the evidence ends.
Give the group an owner, not an illusion
For a short collaboration, decide who can approve a new participant and when access should end. Review the roster at the moment a confidential phase begins. If history must be shared, choose the relevant material deliberately instead of assuming the entire archive belongs to everyone joining later.
This does not require a cumbersome ceremony for every casual conversation. It requires matching the process to the stakes. A public community group and a confidential negotiation should not inherit the same invitation policy merely because they use the same application.
Before sending the next unreleased design or business proposal, open the member list. Confirm the recipients, then confirm the history policy. Encryption can protect the delivery. It cannot decide which people your project should trust.
Bringing Privacy Back is an owned editorial publication associated with UseCrypt. Product references here are not an independent comparative audit or a claim that UseCrypt Messenger implements MLS.
