Why pasting a burn-after-reading link into a chat that generates a preview does not always use up the read

Paste a URL that looks like https://…/s.html?id=…#… into Slack, Discord, or Microsoft Teams and a small card often appears under the composer or the message: a title, a one-line description, sometimes an icon. Many people read that card as “the link has already been opened.” The order is the other way around. The chat product first sends an HTTP GET to that address, pulls og:title, og:description, or a plain <title> from the HTML, then draws the card. The recipient may not have clicked anything yet.

Slack wrote this down. By default, messages that contain a fully qualified URL expand into a preview. The robot that does the expansion identifies itself as Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots). Slack’s Unfurling links in messages page calls that default treatment “classic link unfurling”: Slack crawls the URL and attaches a preview. The same company’s Slack Robots page says the expander fetches as little of the page as it can (using HTTP Range headers) and looks for oEmbed, Twitter Card, and Open Graph tags. It fetches an image, video, or audio file only when a tag points at one, so it can check that file. Responses are cached globally for around 30 minutes. The page does not say “run the page’s JavaScript” or “click a button for the user.”

When a browser — or a preview robot that behaves like one — issues that GET, text after # is not part of the request line. IETF RFC 3986 §3.5 defines the fragment as client-side identification. It is not used by the server when processing the URI. So even if the robot copies the whole string you see in the composer, the request that hits UsePwd usually stops at s.html?id={id}. Why the key never appears in access logs is the older article Why URL hash fragments never reach the server. This piece covers the next layer: does a GET that never carried the key count as “one read.”

Plenty of one-time links hang the secret on the same URL the preview bot GETs. The robot fetches once; the server returns the body and deletes the record. The recipient then opens “already read” or a 404. That failure is common. It is not Slack “maliciously burning the secret.” It is an implementation that treats a cacheable GET — the method RFC 9110 still describes as safe — as the action that destroys ciphertext.

UsePwd Burn-Link splits the job into three steps. On create, the current tab encrypts with Web Crypto and AES-256-GCM. Plaintext is at most 32 KB. The only fields uploaded are ciphertext, a TTL, and a read count. Expiry can be 1 hour, 24 hours, 7 days, or “burn after read only” with no clock TTL. Reads are 1–10, default 1. The share URL looks like s.html?id={id}#{key}. Create and read both open immediately — neither side registers. The server only stores ciphertext. It cannot see plaintext, and there is no account that could recover the secret by user.

When the recipient opens the read page, the tab first asks /api/secrets/{id}/status whether ciphertext is still there. That call returns active, burned, or expired. It does not increment the read count and it does not delete the record. Only after Open and view does the browser request /api/secrets/{id}, fetch ciphertext, and decrypt locally with the key after #. After the create-time count, the server deletes the ciphertext; a later fetch returns 410. A preview bot that stops at the landing HTML usually has no key and does not click that button.

Slack’s link-expanding robot, Discord’s embed crawler, and the server-side request Microsoft Teams uses to build a card are the same class of fetch: GET the page, then look for a title and a description in the HTML. Discord identifies that crawler as Mozilla/5.0 (compatible; Discordbot/2.0; +https://discordapp.com). Public write-ups of Discordbot agree on one limit you can treat as a working assumption: it parses the HTML the server returned and does not execute JavaScript. Slack is explicit about another limit. After trying robots.txt, Slack stopped honoring it as if it were a search crawler, because unfurling is “acting on behalf of a human,” not walking the site. Putting noindex on the read page can keep search engines from indexing it. It will not stop the card in a channel.

UsePwd’s read page is a temporary ciphertext view. It ships noindex, nofollow and is not in the sitemap. The document title is fixed as “Open a One-Time Secret Link.” The description only says decryption finishes in this tab and the key sits after #. If a preview card appears, the channel sees that generic line — not the password, token, or ticket text you typed. That can be true at the same time as “the access log has no fragment.” The card proves someone GET the landing page. The log still has no key after #.

Slack says unfurl results for the same URL are cached for around 30 minutes. Pasting the same test link into a channel twice in a short window may not produce a second fetch. To check “did a bot visit,” look for a User-Agent such as Slackbot-LinkExpanding or Discordbot in your own access log. Do not stare at the card refreshing. A GET to s.html still does not mean /api/secrets/{id} was called.

The usual consumer is the recipient: they open the full link, see “Ciphertext is still here,” then click Open and view. The default count is 1. After that successful fetch, the server deletes the ciphertext. Opening the same link again shows “Already burned.” If you set reads to 2 or higher at create time, earlier fetches leave ciphertext in place until the counter hits the cap. Expiry also deletes: 24 hours by default, or 1 hour or 7 days. “Burn after read only” deletes on count, not on the clock.

The second class is an environment that runs scripts and simulates a click. Some mail security gateways and link sandboxes open the URL in an isolated browser. Some of them also click the primary button. That is no longer “draw a card.” It is a second, human-shaped visit. If the sandbox clicks Open and view, the read is used and the recipient later sees the burned state. Check that against the gateway’s own report. You cannot infer it from the chat card.

The third class is posting the ciphertext API URL itself. The read-page address is s.html?id=. The call that consumes a read is /api/secrets/{id}. Ordinary users do not copy the second one. If someone pastes that API URL into a channel that previews links, and the product treats the first GET as the fetch, the read can be spent at preview time. UsePwd’s share shape is not that address. The create page copies the read-page link with #.

The chat product stores the whole address you pasted. Anyone who can search history, export a workspace, or open a backup can open the read page again. While reads remain, a later opener can still click Open and view and see plaintext. After the count is spent, history keeps a burned link plus whatever title the card showed. An admin export cannot restore ciphertext the server already deleted. It also cannot undo “this channel once held the full URL.”

Screenshots and forwards are another copy. If someone captures plaintext after a successful read, or forwards the link into another preview-generating room, the boundary moves from “this GET” to “who is on the next hop.” Burn-Link limits how long ciphertext lives on the server and how many times it can be fetched. It does not stop the recipient from taking a screenshot. UsePwd has no accounts and no vault, and it cannot recover a lost link by user. Long-term storage or multi-device sync belongs in a dedicated password manager. Identity is on About.

Files are a third path. A local backup of a single file up to 5 GB goes through File Encryption Box, which writes .lock / .enc. The file is not uploaded by default. Generate the passphrase itself in the 6–128 range on the password generator, then check strength on Password Audit. Those pages, like this article, open immediately. Do not read “the preview did not spend a read” as “paste this into any channel and it is safe.” Channel history and the preview fetch are not the same layer.