You send a colleague a one-time password link in Telegram. Ten seconds later, they open it: “This note has already been read and deleted.” Just two people. Who opened it?
Sometimes, the software building a link preview. That doesn't prove someone stole or decrypted the password. In a poorly designed service, requesting the page is enough to delete its encrypted record. Nobody learns the secret, yet the intended recipient loses access. Similar failures can happen with Slack, Discord or WhatsApp, depending on the service and client involved.
How messenger bots generate link previews
A card with a title and image needs data. When a link enters a message, or sometimes while the message is being composed, the client or messaging service may fetch it automatically. Typically, an HTTP GET retrieves HTML containing og:title, og:description and og:image.
Names such as TelegramBot, Slackbot-LinkExpanding, WhatsApp and Discordbot can appear in access logs. They're examples, not a complete detection rule. Slack documents its metadata-fetching robot; timing, caching and implementation differ across other clients.
The URL fragment is the crucial detail. In https://createsecurelink.com/n/Ab3dE5fG7h#key, everything after # stays out of the HTTP request. An ordinary HTML crawler doesn't obtain the key from that request and cannot thereby decrypt the note.
Now imagine a naive GET /note/id handler: retrieve ciphertext, delete the database record, return the page. A metadata request triggers the same destructive operation as a recipient's visit. The encrypted data is gone before anyone uses the key. Confidentiality may survive; availability doesn't. Those are separate security properties.
Why User-Agent and IP blocklists aren't enough
Blocking TelegramBot is tempting. That won't establish when a view should be consumed.
Not every automatic request comes from a messenger's server. Mobile scenarios involving iMessage, WhatsApp or an in-app WebView don't provide one dependable identification rule across all versions. Previews and speculative navigation may use a browser engine on the device. An ordinary browser User-Agent doesn't mean someone deliberately requested the secret.
Mail security adds another visitor. Microsoft Defender Safe Links checks URLs during mail processing and at click time. Mimecast also describes link scanning; some security products use browser-based or isolated environments. It would be inaccurate to say these products always impersonate Chrome. It would be equally unsafe to treat a Chrome-like header as proof of a human decision.
IP lists don't express intent either. One address may serve many users, and automatic traffic need not originate from a dedicated crawler range. Filtering can reduce abuse; it cannot replace a safe consumption boundary.
Secure Link's architecture: loading a page isn't reading a note
A request to /n/[id] leads to a localized page shell. Its HTML and generic metadata contain no secret, and fetching that shell doesn't consume a Redis view. The separate metadata-preview endpoint doesn't decrement the counter either.
Actual retrieval uses GET /api/notes/[id]. This request obtains ciphertext and consumes a view. For a single-view note, the server deletes the stored record; the browser decrypts the response locally. The API doesn't need the key from the URL fragment.
An important limitation follows. The current version has no mandatory “Show secret” button. With a valid fragment key, the client retrieves data automatically. Password-mode ciphertext is also requested before password entry, so the password protects decryption but doesn't guarantee that an automatic client run preserves the view.
An ordinary HTML preview doesn't run that flow. A JavaScript-capable scanner with the complete URL may. A stricter two-step design would postpone retrieval until a separate recipient action. That reduces accidental opening, though a button alone isn't proof of humanity. Describing mandatory confirmation as an existing Secure Link feature would be misleading.
Who makes the request, and what happens?
“Naive service” means an implementation that consumes a view on the page GET, not every competing product.
| Request source | Naive service | Secure Link today |
|---|---|---|
| Telegram / Slack / Discord preview bot | May burn the note when the message is sent | HTML previews don't consume views |
| Email scanner, such as Safe Links | May remove access before the recipient arrives | HTML checks are safe; JavaScript execution may trigger reading |
| Browser prefetch / prerender | A view may be lost | HTML prefetch doesn't read; JS-enabled prerender remains a risk |
| Intended recipient | Can read if the record still exists | API consumes a view; browser decrypts, deletion follows the view limit |
Prefetch and prerender aren't interchangeable. Downloading HTML differs from running a page, so “preloading is safe” needs a more precise definition.
Practical precautions when sharing secrets
- Choose a service that separates the page shell from content retrieval. If mandatory confirmation is required, check that reading is actually deferred, not merely hidden behind a password form.
- Disable the message preview when appropriate. That can reduce unnecessary fetching, but won't disable corporate link scanning.
- Use Split-link: send the URL in Telegram and the key through a different channel. Two consecutive messages in one chat don't provide that separation.
- Add a strong passphrase. Burn-on-Failure consumes remaining views after failed attempts in the standard client; it isn't a substitute for a good password.
- If the link has already burned, create another one. Don't paste the secret directly into the chat just to get the handoff finished.