Do Link Previews Burn One-Time Secret Links?
In poorly engineered services, automated link preview bots from messaging apps can visit the URL and destroy a one-time secret before the human recipient opens it. Secret Note (saklama.com) prevents premature burning through a two-step confirmation interface where the ciphertext is fetched and deleted only when the user explicitly clicks 'View note'. Furthermore, the decryption key resides entirely in the URL hash fragment, which RFC 3986 guarantees is never transmitted in HTTP requests to preview crawlers or host servers.
- Messaging platforms (Slack, WhatsApp, iMessage, Teams) dispatch background crawlers to unfurl link previews.
- Rudimentary secret services that destroy notes on the initial HTTP GET request suffer premature burning by bots.
- Under RFC 3986 section 3.5, browsers and web crawlers never transmit the URL hash fragment (#) in HTTP requests.
- Secret Note retrieves and deletes the secret only after a human user clicks the 'View note' button.
- An optional extra passphrase (PBKDF2-SHA256, 200,000 iterations) prevents consumption on incorrect entries.
How Link Preview and Unfurling Crawlers Operate
When you paste a web URL into a modern messaging platform such as Slack, WhatsApp, Microsoft Teams, Apple iMessage, or Skype, the application attempts to enhance the chat experience by generating a rich snippet. In web development terminology, this background process is known as link unfurling. The messaging client or its backing cloud infrastructure automatically dispatches an automated HTTP GET request to the target URL.
The crawler's sole objective (operating under user-agent strings such as WhatsApp/2.x, Slackbot-LinkExpanding, or Applebot) is to parse the initial HTML document for metadata tags. It searches for standard Open Graph elements such as og:title, og:description, og:image, and site favicons. This metadata is parsed rapidly to render an informative preview card beneath your chat bubble. While convenient for general web links, this automated behavior introduces severe challenges for self-destructing secret links.
The Premature Burn Vulnerability in Naive Secret Tools
Certain open-source scripts and simplistic one-time secret services operate on a flawed assumption: they treat the very first HTTP GET request to a secret's URL as confirmation that the intended recipient has read the message. In such an architecture, pasting your secret link into a chat immediately triggers the platform's preview crawler. The hosting server dutifully serves the secret payload to the crawler and permanently purges the record from its database.
When the human recipient eventually opens the chat and clicks the link minutes later, they are greeted by an error message stating that the note has already been destroyed. This causes significant operational friction, but more dangerously, it triggers severe security panic. Both the sender and recipient assume that an unauthorized third party or network adversary intercepted the communication. In reality, the credential was inadvertently consumed by a benign chat crawler.
Two-Step Retrieval: How Secret Note Shields Against Crawlers
Secret Note eliminates the premature burn vulnerability through a deliberate, two-stage interaction flow. When an incoming HTTP GET request reaches not.saklama.com, the server does not release the ciphertext payload. Instead, it returns a static, lightweight HTML container containing standard metadata and a confirmation interface.
The recipient is presented with a clear advisory screen explaining that the link contains a single-use secret that will be permanently destroyed upon retrieval. The actual encrypted ciphertext is requested from the server only when a human user deliberately clicks the View note button.
Because automated unfurling crawlers only read static HTML responses and do not execute interactive JavaScript button events, they cannot trigger the retrieval API endpoint. You can freely paste a Secret Note link into Slack, WhatsApp, or Microsoft Teams: the crawler unfurls the generic preview card, while your confidential ciphertext remains untouched and waiting on the server until the human recipient chooses to open it.
Why Decryption Keys Never Leak to Crawlers (RFC 3986)
A related concern frequently raised by security-conscious users is whether link preview crawlers can read or store the decryption key itself. The protection against key leakage is rooted in the fundamental architecture of the World Wide Web. When you create a note on not.saklama.com, your browser generates a random 256-bit symmetric key, encrypts the payload locally with AES-GCM-256, and appends the key to the URL following the hash mark (#)—the fragment identifier.
According to RFC 3986 section 3.5, the URI fragment is strictly a client-side component. Conforming web browsers, HTTP client libraries, and crawler bots strip everything from the hash sign onwards before composing the HTTP request sent over the network wire. For example, if you share https://not.saklama.com/n/abc#xyz123, the request sent to the server is strictly GET /n/abc.
Because the fragment never crosses the network in the HTTP request line or headers, neither the preview crawler's servers (Meta, Microsoft, Apple, or Slack) nor saklama.com's own infrastructure ever receive the decryption key. The cryptographic key stays exclusively on the local devices of the sender and recipient.
Edge Cases, Extra Passwords, and Endpoint Limits
While the two-step architecture robustly prevents crawler burns, users should remain aware of operational boundaries. First, if a sender accidentally truncates the link when copying and omits the hash fragment (#), the recipient will receive the ciphertext container but will lack the mathematical key required to decrypt it.
Second, if a link is accidentally posted to a public channel or intercepted, whichever entity clicks View note first will consume and read the secret. To provide defense-in-depth against misrouted links, Secret Note allows configuring an optional Extra password derived with PBKDF2-SHA256 (200,000 iterations).
The critical benefit of the extra password is that verification occurs entirely inside the client browser. If an unauthorized party attempts to open the note and guesses the wrong password, the decryption fails locally without burning or modifying the server-side record. The note remains intact and accessible when the legitimate recipient inputs the correct passphrase.
| Architectural Metric | Naive Burn-on-GET Services | Secret Note (saklama.com) |
|---|---|---|
| Preview Bot Crawl Result | Note is prematurely burned and lost | Note is preserved safely on server |
| Destruction Trigger | Initial automated HTTP GET request | Explicit click on 'View note' button |
| Key Transmission to Server | Depends on implementation | Kept in URL fragment, never sent (RFC 3986) |
| Crawler Server Key Visibility | Hidden if fragment used | Completely stripped by crawler clients |
| Behavior on Incorrect Passphrase | Often burns the note immediately | Rejected locally; secret is not consumed |
Frequently Asked Questions
Will pasting my Secret Note link into Slack or WhatsApp destroy it?
No. When opened, Secret Note displays an initial confirmation interface. Preview crawlers do not execute interactive button clicks, so the secret remains safely stored on the server.
Can link preview crawlers capture the decryption key?
No. Under RFC 3986 section 3.5, web clients and crawlers strip the URL fragment (#) before making HTTP requests. The decryption key never reaches the crawler's servers or saklama.com.
What does a recipient see before clicking 'View note'?
The recipient sees an introductory advisory screen informing them that the link contains a single-use secret that will be permanently destroyed once viewed.
What happens if someone types the wrong extra password?
The extra password is checked locally in the browser using PBKDF2-SHA256. If incorrect, decryption fails without sending a consumption request to the server, preserving the note.
Can enterprise email security crawlers burn the note?
Automated security scanners make standard GET requests and cannot burn the note. For aggressive sandboxes that automate user clicks, configuring an extra password guarantees complete protection.