saklama.com · guide
How does Secret Note work?
Your note is encrypted before it ever leaves your browser; the key never reaches us. First, watch the journey of a note — then see the technology behind it, step by step.
the journey of a note
The story of a note that becomes unrecognizable — and then itself again.
01 · On your device
Your note lives here — whole and readable, on your device.
02 · The grinder
The moment you hit send, it is encrypted — ground into unrecognizable pieces.
03 · The long journey
Whether it travels for a second or five years — it is meaningless data all the way.
03 · The long journey
Servers, cables, hands change. None of them can read it. Neither can we.
04 · Reassembly
Only in the right hands, with the right key, does it become itself again.
05 · One chance
You get one chance to read it. Look closely.
06 · Ash
The moment it is read, it is gone forever. Even the sender can't bring it back — we never saw it at all.
What happens, technically?
Every scene in the story above corresponds to a real technical step. Here it is, without the poetry:
-
01
Encryption happens in your browser
The moment you click "Create Encrypted Link", your note is encrypted with the AES-GCM 256-bit algorithm using your browser's built-in WebCrypto API. Only the ciphertext — a meaningless string of characters — is sent to the server.
-
02
The key travels in the # part of the link
The decryption key is written into the
#(fragment) part of the link. Browsers never send this part to the server — that is not our choice, it is a web standard. Since the key never reaches us, decrypting your content is technically impossible for us. -
03
One-time notes are deleted atomically
When a one-time note is read for the first time, it is consumed through an atomic operation at the file-system level and permanently deleted. Even if two people try to open it at the same instant, only one sees the content; there is no copy, no backup, no recovery.
-
04
The time lock is a server policy
For time-capsule notes, the server refuses to hand out the encrypted text before the unlock date arrives. Let's be honest: this lock is not cryptographic; it is a rule enforced on the server side. We still cannot see the content — the server only decides when it is delivered, never learns what it is.
Verify it yourself
You don't have to take our word for it; your browser shows the proof:
- Open the Secret Note page and press F12 to launch Developer Tools.
- Switch to the Network tab.
- Write a test note, send it, then click the
/api/noterequest that appears in the list. - In the outgoing data you will see only the ciphertext in the
cfield. Your note itself — and the key after the#sign — appear in no request at all.
Technical FAQ
Where is the decryption key stored?
Nowhere. The key exists only in the # part of the link, and browsers never send that part to the server. That is also why a lost link means the content can never be decrypted — we hold no copy that could be opened.
What do you (your servers) see?
Only the encrypted text and technical metadata such as creation and expiry times. Short-lived, IP-based rate limiting is applied to prevent abuse; the note's content, its title, and the key never reach us.
Is the time-capsule lock cryptographic?
No — and we prefer to say so plainly. The unlock date is a policy enforced on the server side: the server refuses to deliver the encrypted text before the date arrives. The content remains end-to-end encrypted either way; the lock only controls delivery time and teaches the server nothing about the content.
Is the code open to inspection?
The encryption runs entirely in your browser, so hiding it is simply not possible: anyone can open /js/crypto.js and read the WebCrypto calls line by line. You can also confirm the network traffic with the "Verify it yourself" steps above.
How does password protection work?
When you add a password, the content key is wrapped in your browser with a second key derived from the password using PBKDF2-SHA256 (200,000 iterations). The password is never sent to the server either; even someone who intercepts the link cannot unwrap the key — and therefore cannot decrypt the content — without the password.