Encryption basics
HTTPS and Message Encryption Are Not the Same Thing
The difference between protecting a connection and encrypting a message before it leaves the browser.
Published: March 29, 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
Imagine two envelopes.
The first is carried through a guarded tunnel, opened at the destination, and handed to the office staff. That resembles HTTPS.
The analogy is imperfect. Web servers are not offices, TLS is not a tunnel, and JavaScript has a habit of turning simple analogies into architecture diagrams. Still, the distinction is useful.
Without HTTPS, someone on the network path may be able to observe or alter traffic.
Collogue must use HTTPS regardless of any additional message encryption. Browser cryptography delivered over an untrusted connection could be replaced before it runs.
HTTPS protects the trip. The destination application can still process the content.
Whether it does so is an application decision.
With browser-side message encryption, the page transforms plaintext into ciphertext before the create request is sent.
It does not make TLS optional. The connection still carries identifiers, ciphertext, application code, and operational metadata. An attacker who can modify the page could alter the encryption process.
A useful security review considers at least four states.
Plaintext exists in the sender’s browser.
Threats include malicious extensions, scripts, malware, shoulder surfing, and accidental copy-and-paste.
The request may contain plaintext or ciphertext depending on the application.
Plaintext exists in the recipient’s browser.
The recipient can read it—and so can sufficiently privileged software on that device.
A security claim that discusses only one state is incomplete.
- copy plaintext before encryption;
- send the key to another endpoint;
- weaken random generation;
- replace an algorithm;
- alter the destination link.
This is not an argument against browser cryptography. It is an argument for accurate threat models, secure deployment, content security controls, source transparency, reproducible builds where practical, and independent review.
Client-side encryption can create a different boundary when the application never receives the message key.
Again, verify Collogue rather than generalizing.
Can someone on the network casually read or modify this connection?
What form does the message have when it reaches the application?
Who has what is needed to decrypt it?
How long and how often will the service return it?
These controls complement one another. None should borrow credit from the others.
No. HTTPS protects the delivered application, requests, identifiers, and ciphertext from network tampering and observation.
Yes. TLS is normally terminated at the service, after which the application processes the submitted values.
Create a private Collogue link when you need to send a password, token, recovery code, or another short piece of sensitive text.