Threat models
Why Collogue Links Are Not One-Time Links
Why a password-protected encrypted link is different from a read-once or expiring secret.
Published: May 5, 2026
Current implementation boundary
Current Collogue links carry the encrypted payload in the URL. The browser uses Web Crypto API: PBKDF2-SHA-256 with 310,000 iterations derives a 256-bit AES-GCM key from the separately entered password, with a random 16-byte salt and a 12-byte IV. The current client has no application API request for creating, retrieving, or storing messages.
The password is not encoded in the link. The implementation does not provide one-time viewing, server-side deletion, or an expiry timer. Treat the full link as sensitive and share the password through a separate channel.
Further context
A link that works once can reduce exposure, but the person who opens it first still wins.
That sentence captures both the benefit and the limitation.
Imagine sending a temporary password in email.
Most of these copies will never cause an incident. The problem is that they exist long after their purpose ended.
That is a real reduction in persistent exposure.
- how likely access is;
- how long access remains possible.
A secret available for ten minutes is not automatically safe. It is usually exposed for less time than the same secret sitting in an inbox for three years.
This is risk reduction, not invulnerability.
Still, the failure is useful. Bob and Alice now know not to trust the credential blindly.
For an access token or password, the safe response is usually to revoke or rotate it and create a new one.
Ordinary plaintext email rarely provides this warning. It continues displaying the secret no matter how many people have read it.
If the link acts as a bearer capability, Collogue may know that the correct URL was presented. It may not know that the human is Bob.
- verify the destination address;
- confirm the recipient through an established channel;
- avoid including unnecessary context with the link;
- use a temporary, scoped credential;
- require a password change or token rotation;
- enable MFA on the target account.
Do not turn the private link itself into the only identity proof for a highly privileged action.
People sometimes send half a password by email and half by text.
This can force an attacker to compromise two channels, but it also creates complexity, transcription errors, and two persistent fragments. Its value depends on whether the channels are genuinely independent and how the halves are generated.
Another approach is to send the Collogue link through one channel and confirm the recipient or provide non-secret context through another.
Neither method automatically creates multi-factor authentication. They are delivery choices, not universal proofs.
- a temporary password;
- a short-lived API token;
- a recovery code;
- a Wi-Fi credential;
- a one-off client login;
- a private configuration value;
- a short sensitive note.
- long-term team credential sharing;
- recurring access;
- highly regulated records requiring audit workflows;
- large files;
- secrets that cannot be rotated;
- cases requiring strong recipient identity verification.
A password manager, secrets manager, privileged-access system, or approved enterprise transfer tool may be better for those cases.
It can reduce persistent readable copies and active lifetime. Safety still depends on link delivery, encryption, recipient verification, endpoint security, and the secret’s own lifecycle.
No. It proves only the application state it records. The first viewer may have copied the content, and the service may not know who that viewer was.
Prefer temporary, scoped, revocable credentials. A safer delivery channel does not repair an overprivileged or permanent secret.
Collogue can reduce persistent exposure in email and chat, but it cannot secure a compromised device or control what a recipient does after reading.