"Key in the URL": Why Bitburner Can't Read Your Message 🔐

A clear explanation of why Bitburner cannot read your message: client-side encryption, URL fragments, what servers receive, and the real limits of this model.

People ask me a lot: if Bitburner stores my message, can Bitburner read it? The short answer is no. The long answer is: the key never goes to the server, and your browser does the decryption locally. If you want to try it in practice, use the app here: bitburner.vberkoz.com.

This post explains what “key in the URL” really means, why it matters, and what it does not protect you from. I will keep it human and practical, without heavy math.

The big idea: the server never gets the key 🧩

Bitburner uses client-side encryption. This means your browser encrypts the message before it is sent anywhere. The server only stores encrypted data (ciphertext). Without the key, ciphertext is just random noise.

Where is the key? It is stored in the URL fragment, the part after #.

Example:

https://bitburner.vberkoz.com/#<id>:<key>

The key lives after the #. The important part: browsers do not send the fragment to the server in HTTP requests. The server sees only the ID, and it never sees the key.

So even if Bitburner wanted to read your message, it cannot. It does not have the decryption key.

What the server actually sees 📦

When the browser requests the secret, it sends a normal HTTPS request. The server receives:

the request path and query (no fragment),
headers (user agent, etc),
the ID for the encrypted blob.

The server does NOT receive:

the fragment,
the key,
your decrypted message.

This is a browser rule, not a Bitburner trick. The fragment is a client-side feature, and it never leaves your device unless you copy the full URL and send it somewhere.

Why this is called end-to-end encryption 🔒

End-to-end means only the sender and receiver can decrypt. The server is not part of the trust chain.

Bitburner uses this pattern:

Sender encrypts in browser.
Server stores encrypted blob.
Receiver decrypts in browser using fragment key.

The server is just a mailbox for encrypted data. It cannot open the mail.

This is different from “encryption at rest”, where the server encrypts data with its own key. In that model, the server can still decrypt when it wants. In Bitburner, it cannot.

Why the key is in the URL, not in the database 🔗

If the server stores both ciphertext and key, the server can decrypt. That defeats the whole point.

Keeping the key in the URL fragment means the key exists only on the client side. It also makes sharing easy: you just send one link, and the receiver has everything needed to decrypt.

It is simple, but powerful.

The tradeoff is also clear: anyone who gets the full URL can decrypt. So the URL is the secret.

How encryption happens in the browser 🧠

Bitburner uses the Web Crypto API. The browser generates a random key, then encrypts your message with AES-GCM. AES-GCM gives both confidentiality and integrity, so if ciphertext is changed, decryption will fail.

This process happens in your device memory. The plaintext is never sent to the server. Only the encrypted bytes go out.

This is why Bitburner can say it cannot read your message, and it is actually true.

What happens when you open the link 🚪

When you open a Bitburner link, the app does this:

Reads the fragment from the URL.
Splits it into ID and key.
Fetches encrypted blob from the server using the ID.
Decrypts the blob in your browser using the key.
Shows the message.

The server only sees a request for an encrypted blob. It never sees the key or the decrypted content.

What this protects you from (and what it doesn’t) ⚠️

This model protects you from:

server-side data leaks (database dump is just ciphertext),
employees reading your secrets,
backups containing readable messages.

It does NOT protect you from:

someone who gets your full link,
malware on the sender or receiver device,
someone screen-recording the message after it decrypts.

So it is strong for server trust, but not magic for endpoint security. This is the correct and honest tradeoff.

The fragment can be lost if you are not careful ✂️

Some apps or services strip URL fragments when they auto-link or shorten URLs. If the fragment is missing, the link is useless because the key is gone.

This is why you should:

send the full link as plain text,
avoid URL shorteners,
verify the recipient sees the full #... part.

If the fragment is lost, no one can decrypt. Even you.

Why HTTPS still matters 🛡️

Even with client-side encryption, you still need HTTPS.

HTTPS protects:

the encrypted blob in transit (prevents tampering),
the frontend app code (prevents injection of malicious JS),
the ID from being intercepted or modified.

If someone can modify the frontend JavaScript during delivery, they can steal the key or plaintext. So HTTPS is not optional. It is part of the security model.

”Can the server log the key anyway?” 🤔

The key is in the fragment, which is not sent in HTTP requests. So server logs cannot capture it by default.

But you should still be careful:

if you paste the link into analytics or support tools, the full URL might be stored,
if you use a browser extension that logs URLs, it might capture fragments,
if you copy the link into a place that previews or stores URLs, it may record it.

So again: treat the full link like a password.

Why Bitburner does not need accounts ✅

Because the key is in the URL, there is no need for user accounts or login. The link itself is the access token.

This keeps the tool fast and simple. You can use it without friction. This is why one-time secret tools feel so lightweight compared to full secure messaging apps.

But it also means there is no recovery. If you lose the link, the message is gone. This is a tradeoff for simplicity.

SEO-friendly summary for readers in a hurry 📌

If you are searching for “Bitburner key in URL” or “why server cannot read message”, here is the short answer:

Bitburner uses client-side encryption. The message is encrypted in your browser with a random key. The encrypted message is stored on the server, but the decryption key is kept in the URL fragment after #. Browsers never send fragments to servers, so the server never receives the key and cannot decrypt your message. The link itself is the secret, so keep it private.

Final thoughts ✅

“Key in the URL” is not a marketing line. It is a concrete security design that reduces trust in the server. Bitburner cannot read your message because it never receives the key.

If you want a lightweight way to share a secret without storing it in chat history, this model is a good fit. Just remember: protect the link, use HTTPS, and open the link on a safe device.