Safe sharing
How to Share a Private Link Safely
Practical steps for sharing a Collogue link and its password with less persistent exposure.
Published: March 4, 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
Encryption protects content under technical assumptions. Delivery decides who gets the opportunity to use it.
A beautifully encrypted message sent to the wrong address is still sent to the wrong address.
- check the complete email address or account name;
- be careful with autocomplete;
- confirm unusual requests through an established channel;
- avoid sending to broad groups;
- do not post the link in a public ticket or repository.
For high-impact credentials, contact the recipient through a known channel rather than replying blindly to an unexpected request.
Suppose you are sending access to an administrative panel.
- the company name;
- the login URL;
- the username;
- the password;
- the purpose of the account.
An intercepted message provides a complete instruction manual.
A narrower Collogue message might contain only the temporary password. The ordinary channel can provide non-sensitive context, or context can be split when the risk justifies it.
Do not turn this into ritual. Separating harmless details has little value if every channel is controlled by the same compromised account. Use judgment.
The best password to deliver is often temporary and easy to replace.
- the link and password must be kept private;
- they should open it only on a trusted device;
- they should not send it to an online link checker;
- they should report a link or password that does not work;
- a password should be changed after use.
Avoid technical jargon in user-facing messages. Explain that the password is shared separately and that both pieces should stay private.
Use the product’s confirmation state, automated tests, or a separate sample message.
The interface should make this warning visible before the sender leaves the result screen.
Email, SMS, team chat, and phone calls have different risks.
- account compromise;
- device sharing;
- message retention;
- corporate archiving;
- link scanning;
- notification previews;
- recipient convenience;
- ability to verify identity.
There is no universally safest channel independent of the people and systems involved.
For ordinary business use, an established channel to a verified recipient plus a temporary credential is often more valuable than an elaborate process nobody follows correctly.
- public URL scanners;
- generic shortening services;
- public documents;
- analytics redirectors;
- QR-code generators you do not trust.
Such services may receive or request the complete URL. If the key is inside the link, they may receive the capability to open the message.
A sender may deliver the link by email and confirm the recipient by phone. Another workflow may send non-secret context through a ticket and the private link through an approved messenger.
This can make a single-channel compromise less sufficient.
It does not automatically create strong authentication. If the same person controls both channels, if both channels are synced to one device, or if the sender verifies an attacker, the separation offers less.
Use separate channels as one control among several.
- replace credentials;
- do not resend the same secret;
- confirm the destination;
- review recent account activity;
- create a new link.
I sent the temporary password through a private Collogue link. Use the password I shared separately, and change the temporary password after your first login. If either part may have reached someone else, tell me so I can replace the credential.
This copy is short, specific, and does not promise impossible security.
It can be appropriate when the recipient and email account are trusted, the secret is temporary, and the organization understands link-scanner behavior. Email delivery does not authenticate the viewer by itself.
For higher-risk access, separating context may reduce the value of a single intercepted message. It is not necessary in every case and does not replace temporary credentials or MFA.
You can, but consider channel membership, retention, enterprise archives, notification previews, link scanning, and account compromise. Use the narrowest appropriate destination.
An additional passphrase may help only if it is strong, handled separately, and implemented correctly. If you can securely deliver the passphrase, consider the total workflow rather than assuming another password always improves it.
Create a private Collogue link when you need to send a password, token, recovery code, or another short piece of sensitive text.