Practical guide
How to Share Sensitive Text Without Creating an Account
When an account-free encrypted link is useful and where it is not enough.
Published: July 16, 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: An account-free private-message link can be useful for a one-off exchange when neither party needs a permanent shared workspace. It reduces setup and account data, but it does not prove anonymity, authenticate the recipient, or replace managed access for recurring secrets.
Suppose two people need to exchange one short secret exactly once.
Should they first create two accounts, verify two email addresses, accept a privacy policy, configure a workspace, invite one another, and learn a collaboration model?
Sometimes yes.
Sometimes the machinery becomes larger than the task.
Account-free sharing is valuable when the exchange is temporary and the identity relationship already exists elsewhere.
- profile names;
- account passwords;
- persistent workspaces;
- contact lists;
- billing identity;
- long-term message history.
This can reduce friction and retained identity data.
No account is a product property. Anonymity is a much stronger network and operational property.
- a one-off support credential;
- a short recovery code;
- a temporary Wi-Fi password;
- a client’s hosting login;
- a short-lived API token;
- a private configuration value;
- a sensitive personal note;
- a bootstrap password.
The common pattern is that the parties already know why they are communicating and do not need Collogue to become their identity provider.
If possession of the complete link enables access, the link functions as a bearer capability.
The service may know that a valid capability arrived. It may not know who held it.
Account-free access exchanges identity enforcement for lower friction. Whether that trade-off is appropriate depends on the secret.
- sending to the wrong recipient;
- reusing a permanent password;
- including unnecessary context;
- sharing a root token;
- opening the final link;
- ignoring an unavailable state;
- using a compromised device.
Removing signup screens does not remove the need for judgment.
- a team needs ongoing shared access;
- access should be revoked per person;
- credentials must be organized;
- users need updates after rotation;
- auditing matters;
- the secret is used repeatedly.
Do not build an operational secrets platform out of private-message links.
- regulated health or financial records;
- large confidential documents;
- legal workflows requiring evidence;
- highly classified material;
- identity-bound delivery;
- retention and legal-hold requirements;
- contractual data-residency commitments.
Use the system approved for the data category.
Persistent accounts create persistent relationships.
- identity;
- login history;
- recovery information;
- user preferences;
- message ownership;
- billing records.
Avoiding accounts can reduce this data surface when the product genuinely does not need it.
That is a modest, defensible privacy advantage.
It should not be inflated into “nothing is known about the user.”
The process is deliberately small because the task is small.
No-account access does not automatically provide anonymity. Network and infrastructure metadata may still exist.
The intended account-free flow should not require one. Confirm the actual product behavior before publishing this statement.
Prefer a managed password or secrets system for recurring access.
Create a temporary Collogue link for a one-off password, token, recovery code, or private note.