Incident response
What If Someone Opens the Link First?
What to do when a sensitive link or password may have reached the wrong person.
Published: April 15, 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
Direct answer: Collogue cannot show who opened a link. If both the link and separately shared password may have reached the wrong person, treat the credential as potentially exposed: revoke or rotate it, verify the recipient through another channel, and create a new message rather than resending the same value.
Collogue has no server-side read event, so it cannot prove that a person opened a message or identify a viewer. A broken link or failed decryption may instead be caused by an incomplete URL, an altered URL, or the wrong password.
If the message contained a password, API key, session token, recovery code, or access link, treat the value as exposed.
- Revoke or rotate it.
- Do not send the same value again.
- Confirm the intended recipient.
- Create a new temporary value where possible.
- Send a new Collogue link.
- Investigate the delivery path if the problem repeats.
A permanent credential creates a larger incident than a temporary one. This is why delivery and credential design belong together.
Not every private message is an access credential.
If the content was a non-critical note, the sender may choose to create a new message after confirming the recipient. The risk depends on the sensitivity of the text and the consequences of disclosure.
The service cannot make this decision for the user. It can explain the state clearly.
Only if the service intentionally collects and can reliably interpret relevant evidence—and even then, attribution may remain uncertain.
- the intended recipient;
- a corporate proxy;
- a mobile carrier;
- a VPN;
- a mail scanner;
- a shared network;
- an attacker.
A user agent may describe software, not a person.
Do not imply that an audit trail identifies a human unless the system includes authenticated recipient identity and the claim is supported.
For recurring delivery failures inside one organization, test non-sensitive links through the same mail path and review security-gateway policy with the administrator. Do not use a real credential as a test message.
- assess the consequence of disclosure;
- confirm whether the recipient opened it;
- avoid repeating more context than necessary;
- use an approved incident process for regulated information.
No. The current client does not collect read events, and a URL request does not identify a person.
If a password link does not decrypt, confirm the URL and password. Replace the credential whenever both pieces may have been exposed.
Collogue cannot reliably distinguish a scanner from a person. Publish only the diagnostic capabilities that the code actually provides.