Limitations
What Collogue Cannot Protect Against
The device, recipient, password, and delivery risks outside Collogue’s browser encryption model.
Published: June 3, 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 system can control what it stores. It cannot control every copy another person creates.
This is not a disappointing exception to privacy. It is the boundary between cryptography and reality.
Before encryption, the message is plaintext on the sender’s device.
- keystrokes;
- clipboard contents;
- page text;
- screenshots;
- generated links;
- encryption keys.
Collogue cannot protect information that an attacker observes before the application protects it.
Use trusted, updated devices for sensitive exchanges.
After decryption, the message becomes plaintext in the recipient’s browser.
Malware may read or record it. The operating system may create previews or diagnostics. A browser extension may access the page.
- copy the text;
- take a screenshot;
- photograph the screen;
- paste it into another system;
- forward the link before opening;
- share the credential;
- retain the secret in a password file.
Technical controls can limit service behavior. They cannot guarantee recipient intent.
Choose recipients carefully and use temporary, revocable secrets.
If a sender mistypes an address or chooses the wrong chat account, encryption may deliver the message securely to the wrong person.
The system can verify possession of the link. It may not verify identity.
For high-risk exchanges, confirm the recipient through a trusted process.
If the complete link contains or provides access to the decryption key, anyone who obtains it may be able to open the message.
- forwarded email;
- clipboard history;
- public chat;
- URL shorteners;
- browser synchronization;
- link scanners;
- screenshots;
- exposed notifications.
Treat the full link as sensitive.
Browser-side encryption relies on code delivered to the browser.
A compromised deployment could theoretically alter that code. Controls such as secure deployment, dependency review, CSP, source transparency, independent audits, and reproducible builds can improve confidence.
They do not make a dynamic web application independent of its delivery system.
- low entropy;
- password reuse;
- excessive permissions;
- unlimited lifetime;
- missing MFA;
- absent monitoring;
- shared administrator accounts.
Prefer credentials that are random, scoped, temporary, revocable, and unique.
Collogue does not verify every business context surrounding a request.
Users should verify unusual requests through an established channel.
Encryption may hide content while leaving timing, IP addresses, identifiers, and payload size visible to parts of the infrastructure.
Collogue is not automatically an anonymity service.
See the metadata article for the verified scope.
A web page cannot reliably prevent an external camera.
Attempts to disable copying or screenshots often inconvenience legitimate users while providing weak protection against determined recipients.
- authenticated recipient identity;
- enterprise access control;
- legal hold;
- detailed audit trails;
- data-residency guarantees;
- administrative policy enforcement;
- key custody requirements;
- compliance certification.
Organizations should use approved systems for regulated data and high-impact secrets.
Do not infer compliance from encryption alone.
A precise boundary lets users choose correctly.
A security product earns trust by saying both sentences.
No. Once the recipient can read the message, they can usually record it by software, copy, transcription, or an external camera.
No web application can reliably protect plaintext from malware with sufficient control of the device.
Not for persistent, managed team access. A password manager or secrets manager provides different capabilities such as organization, rotation, sharing policy, and access revocation.
Collogue can reduce persistent exposure in email and chat, but it cannot secure a compromised device or control what a recipient does after reading.