What Metadata Can Still Exist Around an Encrypted Message?

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: Encryption can protect message content without hiding every surrounding event. In the current client-only implementation, the app does not create message IDs, expiry settings, or access events. Network infrastructure outside this code may still process ordinary connection metadata. Content confidentiality and anonymity are different properties.

An encrypted message can be unreadable and still be visible in silhouette.

An observer may not know what Alice sent Bob. The observer may still know that a message was created at 14:03, that its encrypted payload was 840 bytes, that a request arrived from a particular network, and that the link was accessed ten minutes later.

Whether these facts matter depends on the threat model.

Content is the message itself.

Not every system collects every item.

Proper encryption should make the ciphertext computationally unhelpful for learning the plaintext without the key.

• exact words;
• passwords;
• token values;
• personal notes;
• structured content.

• the existence of ciphertext;
• its approximate size;
• when it was uploaded;
• when it was requested;
• the network endpoints making requests.

Cryptographic systems often protect meaning more readily than circumstance.

• the user’s connection;
• a VPN;
• a corporate gateway;
• a mobile carrier;
• a reverse proxy;
• a security scanner;
• a shared network.

It is not a perfect identity. It is still potentially sensitive metadata.

Determine whether Collogue or its infrastructure retains it, for how long, and for what purpose.

Do not call Collogue anonymous merely because no account is required.

An opaque identifier is preferable to one containing user or content information. It remains a linkable event marker if it appears across logs.

Encryption usually does not hide the approximate length of the plaintext unless padding is added.

For most short secrets, this is not the main risk. In some contexts, size patterns can reveal message type or activity.

Do not claim that Collogue hides size unless padding has been verified.

Creation and expiration timestamps may be necessary for lifecycle enforcement.

They can also reveal a pattern of activity.

Analytics, error reporting, CDNs, fonts, embeds, and support widgets may receive request metadata.

• the create page;
• the result page;
• the reveal page;
• the decrypted-message state;
• the How privacy works pages.

Privacy-sensitive routes should avoid unnecessary external requests.

If sensitive identifiers or keys appear in URLs, navigation and resource loading require careful referrer policy.

• whether the key is in a fragment, query, or path;
• whether third-party resources load on message pages;
• the Referrer-Policy header;
• external-link attributes;
• analytics URL capture.

Fragments are not normally sent in HTTP requests, but page scripts and user actions can still expose them.

No single word such as “private” answers all of these concerns.

A transparent service states which layer it protects.

• Use a trusted device.
• Avoid public or monitored environments for highly sensitive exchanges.
• Use temporary credentials.
• Do not include unnecessary context.
• Consider whether the existence and timing of the exchange are themselves sensitive.
• Use an approved anonymity system when anonymity—not merely content confidentiality—is required.
• Follow organizational policy for regulated data.

Collogue should not present itself as an anonymity network unless it actually provides those properties.

It should not reveal the exact plaintext under sound encryption, but it may reveal an approximate length or message pattern.

Collogue can protect message content under its verified model, but it should not be confused with an anonymity network.

Related reading

• Can Collogue Read My Private Messages?
• Can Email Scanners Open a Collogue Link?
• How Collogue Encrypts a Private Message