Collegamenti segreti una tantum: come condividere informazioni sensibili senza lasciare una traccia permanente

The Problem with "Secure Enough" Channels

Email can be encrypted in transit. Slack can be locked down with single sign-on (SSO). Signal can offer disappearing messages. All of that helps—but it solves a completely different problem.

The issue isn't always interception. It's retention.

When you send a secret through a normal channel, you're betting on a massive chain of assumptions:

• The message will never be forwarded, screenshotted, or copied.
• Nobody will accidentally search the shared chat history six months later.
• Backups, server exports, and data discovery workflows won't turn a quick handoff into a long-term liability.
• Link preview bots in Slack, Teams, or iMessage won't fetch the URL automatically and burn it before your recipient opens it.
• The secret will be immediately rotated after use, even though the old value still sits in a server log somewhere.

The Separation of Powers: Encryption protects content in motion. Ephemerality reduces what exists afterward. Both matter—but most mainstream communication tools optimize heavily for the first and entirely ignore the second.

What a One-Time Secret Link Actually Is

A one-time secret link (sometimes called a "burn after reading" link or self-destructing note) is a URL meant to deliver sensitive text to one reader, once. After that read, the content should be gone—not archived, not searchable, not lingering in a mailbox or chat history.

A true one-time secret design is stricter than an expiry timer. Critically, the encryption key is generated in your browser—never on the server—and the plaintext is encrypted there before anything is uploaded.

In practice, the full flow looks like this:

1. 1

   Browser-Generated Key & Encryption

   Step 1: Your Browser

   You write the secret in your web browser. The browser generates a fresh encryption key locally and uses it to encrypt the text—before any network request leaves your device.

2. 2

   Ciphertext Upload

   Step 2: The Server

   Only the encrypted blob is uploaded. The server stores ciphertext it cannot read because it never received the key or the plaintext.

3. 3

   Key Stays in the Link

   Step 3: The URL

   The browser-generated key is appended to the link in the URL fragment—the part after #—which is never sent to the server.

4. 4

   One Read, Then Gone

   Step 4: The Recipient

   The recipient opens the full link. Their browser reads the key from the fragment, decrypts locally, and the server deletes the ciphertext after that first successful read.

Not every product sold as a one-time secret link follows this pattern. Some tools encrypt on the server after receiving your text—or generate the key there, meaning the service could read your secret. Others rely on a shared password the service can validate. Still others delete on a schedule but keep metadata, logs, or recoverable copies. When you evaluate a tool, ask whether it implements the full design—not only whether the link expires.

Why the URL Fragment Matters

This architectural detail is incredibly easy to miss, yet it is the foundation of modern web cryptography.

In a standard HTTPS request, everything before the # symbol is sent directly to the server. Everything after the # stays inside the browser sandbox. That means a well-designed one-time link system can store your encrypted content securely at /note/abc123 while keeping the decryption key at #xK9m2p... entirely invisible to the server logs, CDN access paths, or external database tables.

When to Use a One-Time Link (And When Not To)

Not every channel is wrong for every kind of secret—but most everyday tools were built for persistence, not one-time delivery.

The Link Preview Trap

Here's a failure mode most tech teams discover the hard way. Many enterprise chat apps automatically crawl incoming URLs to generate rich previews (titles, descriptions, thumbnails).

That automatic crawl can consume a one-time link before your recipient even has a chance to click it. The automated preview bot becomes the first reader, the note burns, and your colleague opens a dead link.

Serious ephemerality tools actively mitigate this by blocking known crawler user-agents, forcing explicit user click-throughs before local decryption happens, and keeping token expiries incredibly tight.