Message privacy
Can Collogue Read My Private Messages?
What the current browser code can and cannot access when it encrypts a Collogue message.
Published: January 14, 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
“Can the service read my message?” sounds like a yes-or-no question. Technically, it is several questions wearing one coat.
A useful answer separates these questions instead of hiding them behind a single adjective.
The readable message is called plaintext. The encrypted result is ciphertext. Good encryption should make ciphertext useless without the required key.
The next question is where the key comes from and who can obtain it.
If Collogue uses a different mechanism, the public explanation must describe that mechanism rather than borrowing the URL-fragment story from another product.
Suppose a website encrypts messages in the browser. Today, you inspect the network request and confirm that no plaintext is sent. Good.
That does not make browser encryption pointless. It tells us what the protection means.
A publicly inspectable repository can improve transparency. It does not prove that the deployed build exactly matches the repository unless there is a verifiable release process. An independent audit can improve confidence. It does not convert a changing web application into a mathematical theorem.
Security remains an engineering claim supported by evidence.
These protections are meaningful precisely because they are narrow.
- the sender’s device is compromised;
- the recipient’s device is compromised;
- a malicious browser extension reads the page;
- the sender gives the link to the wrong person;
- someone forwards the full link before it is opened;
- the recipient copies or records the message;
- the web application delivered to the browser is malicious;
- the secret itself is weak, reused, or excessively privileged.
Encryption controls access to information under stated assumptions. It does not repeal human behavior.
Use that term only if the architecture, key handling, deployed code, and operational model justify it. A browser-encrypted payload alone is not enough to settle every interpretation of “zero knowledge.”
The answer depends on whether records contain plaintext, ciphertext, keys, or enough data to derive keys. Publish the verified schema and key path rather than a slogan.
Yes. A recipient must eventually reconstruct plaintext to see it. At that moment, the browser environment and device become part of the trust model.
Create a private Collogue link when you need to send a password, token, recovery code, or another short piece of sensitive text.