Bitburner One-Time Links: What “Works Only Once” Really Means 🔥

A practical, honest explanation of what “works only once” really means in one-time secret links, how Bitburner handles it, and the real-world edge cases.

If you ever used a one-time secret link, you probably saw the promise: “works only once”. It sounds simple, but in real world it is more subtle. I built Bitburner to be a clean and safe way to share secrets, and in this post I explain what “only once” actually means, how it works under the hood, and what can still go wrong if you are not careful.

This is a 101-style post, but with real details. If you want to try the app while reading, open Bitburner here: bitburner.vberkoz.com.

The short meaning of “works only once” 🚀

One-time link means the secret should be revealed a single time and then removed. So if you open it and see the message, the next person opening the same URL should get “already consumed” or “expired”.

But “only once” is not the full story. The full story is:

the secret is stored for short time,
the secret is deleted after first successful reveal,
if someone opens it earlier, you lose the chance,
and you still must protect the link itself.

So it is not a magical safety guarantee. It is a time-limited sharing pattern.

Why one-time links are useful at all ✅

People share passwords in chat all the time. That means the secret lives in chat logs, backups, exports, search, and screenshots. It can stay there for years.

One-time links move the secret out of the chat. The chat stores only a random URL. The actual message sits in a separate storage with short TTL and is deleted after reveal.

This is the main value: less permanent traces, less long-term exposure.

How Bitburner “only once” is implemented 🔒

In Bitburner the message is encrypted in your browser, then stored on the server in encrypted form. The decryption key is never sent to the server; it lives in the URL fragment.

Typical flow looks like this:

You type a message in the web app.
Your browser encrypts it with AES-GCM.
The encrypted blob is stored in DynamoDB.
The link you get contains an ID and the key in fragment:
https://bitburner.vberkoz.com/#<id>:<key>
When someone opens the link, Bitburner fetches the encrypted blob using the ID, then decrypts in browser using the key in fragment.
After successful fetch, the backend deletes the stored ciphertext so it can’t be read again.

This is what “only once” means here: the storage is consumed and deleted after first valid retrieval.

What “only once” does NOT mean ⚠️

I want to be very clear: “only once” does not mean “only one person can ever see it”.

If someone else gets the link before your recipient, they can open it first. Then your recipient gets the “already consumed” message. The system does not know who is “the right person”. It only knows “first successful fetch wins”.

Also, if the recipient copies or screenshots the secret, that is outside the system. One-time links cannot stop human behavior.

So think of it like a seat in a cinema: only one person can sit there, but anyone who comes first can take it.

The race condition problem (and how to avoid it) 🧠

A naive implementation can accidentally reveal a secret twice. This happens when you do “read then delete” in two separate operations. If two requests hit the server at same time, both might read before deletion.

To make “only once” real, you need atomic behavior: “give me the secret and remove it in one step”.

In Bitburner, this is handled by the backend so the secret is removed immediately on retrieval. The point is: no window where two readers can race.

Expiration is not optional ✨

One-time is about usage, but expiration is about time. Both are needed.

Bitburner lets you choose expiration like 1 hour, 6 hours, or 24 hours. This does a few important things:

reduces the time the secret exists,
limits the damage window if link leaks,
clears old data automatically (TTL).

Even if nobody opens the link, it will die on its own. That is a core part of the safety story.

Client-side encryption is the real protection 🛡️

A common question: “If the server stores my message, can the server read it?”

In Bitburner, the answer is no. The server only stores encrypted data. The key lives in the URL fragment (the part after #) which is never sent to the server in normal HTTP requests.

So even if the database leaks, an attacker sees ciphertext without keys. That is a very strong security property.

But it still depends on one thing: if your full link is leaked, the key is leaked too. So protect the URL itself as you would protect a password.

The “link preview bot” issue 🕵️

This is the most common real-world failure. Many apps (Slack, Teams, Telegram, some email clients) open links automatically to generate previews. Security scanners in corporate email also “click” links in background.

If the one-time secret reveals on first GET, the bot can consume it. Then the real recipient gets nothing.

Bitburner is designed to avoid this by not revealing the secret on initial page load. The reveal happens with a clear user action, so bots don’t consume the secret just by previewing. It is still not perfect (bots can emulate a click), but it reduces accidental burns a lot.

“Only once” vs “only once per device” 👀

Sometimes people imagine a one-time link is tied to a user. That is not the case.

One-time links do not have identity. They are anonymous by design. That is part of why they are simple and fast. It also means you should not send the same link to multiple people, because any of them can be the “first”.

If you need identity, you need a different system: authentication, access control, and audit logs. One-time links are for quick, frictionless sharing.

Why Bitburner uses the URL fragment 🔗

The URL fragment is special: browsers do not send it to the server. It stays in the client.

That is why the link format is #id:key in Bitburner. The server sees only the ID and returns ciphertext. The browser uses the key from fragment to decrypt.

It also means: if you paste the link in a place that strips fragments, you will lose the key and the link will not work. So always copy the full link, not a “shortened” version.

Typical “only once” failure modes 💥

Let’s list them clearly so expectations are right:

The link is opened by someone else first.
The link is opened by a preview bot.
The link expires before recipient checks it.
The recipient copies the secret elsewhere.
The URL fragment is stripped (no key).

None of these are “bugs”. They are just reality of how the web works. A good one-time link system reduces risks, not removes them.

Good habits for using Bitburner 🧩

Here is how I personally use it:

Set the shortest expiration that is practical.
Send the link in a channel that is reasonably private.
Tell the recipient to open soon.
Rotate the secret after it is used (for passwords, API keys).

These habits turn “one-time” into real safety, not just a shiny feature.

What you gain compared to plain chat 💬

If you paste a password in chat, it can live forever. If you use Bitburner, the secret is stored encrypted and deleted after one read or after expiration.

So you gain:

less persistence,
less exposure in logs,
less risk from old backups,
less accidental sharing over time.

This is why even a simple one-time link can be a big upgrade over “just send it in Slack”.

Final thoughts ✅

“Works only once” is not a magical promise. It is a contract: the secret should be available for a single successful retrieval, then it should disappear.

Bitburner follows this model with client-side encryption, short TTL, and delete-on-read behavior. It still depends on the link being kept private and opened by the right person first.

If you need a fast and practical way to share a secret without leaving it in chat history, Bitburner is built for that. Try it here: bitburner.vberkoz.com.