What Does the Secret Note Security Model Protect and What Not?
The Secret Note security model protects confidential messages by encrypting them locally in the browser with AES-GCM-256 before transmission. Decryption keys are stored solely in the URL fragment (#), which browsers never transmit to the server, ensuring zero-knowledge storage; one-time notes are deleted immediately upon the first read, whereas expiring notes remain available until their configured duration elapses. However, the model cannot defend against compromised endpoints, physical screen captures by recipients, or malicious code delivery by the server.
- Encryption runs locally in the browser using AES-GCM-256 via the native Web Crypto API.
- Decryption keys remain inside the URL fragment (#) and are never transmitted to the host server.
- Even during a total database breach, an attacker obtains only indecipherable ciphertext.
- A two-step viewing flow prevents automated link-preview crawlers from consuming one-time notes prematurely.
- Clear boundaries: Recipient screenshots, operating system malware, and server code distribution remain trusted boundaries.
Core Architectural Principle: Zero-Knowledge by Design
Secret Note is designed to secure confidential data through cryptographic constraints rather than contractual privacy pledges. At the heart of this architecture lies the zero-knowledge principle: the hosting infrastructure never possesses the plaintext message or the secret key required to decrypt it.
When a sender composes a note, all cryptographic routines execute locally within the browser using the Web Crypto API (SubtleCrypto). A cryptographically strong 256-bit symmetric key is generated on the device, and the text is encrypted via AES-GCM-256. The resulting ciphertext is saved to the server, while the decryption key is attached after the hash symbol (#) of the generated link. Under RFC 3986 Section 3.5, browsers never send the URL fragment across the network. The server stores only opaque ciphertext.
Threats Fully Mitigated: Server Breaches and Network Observers
This architecture provides robust, mathematical protection against two predominant vectors of digital compromise:
- Server-side data breaches: If the hosting server is compromised, seized, or backed up by an adversary, the captured database contains only indecipherable ciphertext. Because the decryption keys were never uploaded, decrypted recovery is mathematically infeasible.
- Network observers and intermediate proxies: While standard HTTPS secures data in transit, the URL fragment architecture provides an essential second line of defense. Because fragments are stripped locally before HTTP transmission, network sniffers, corporate firewalls, and proxy server access logs record only the base URL, leaving the decryption key untouched.
Link-Preview Bots and Premature Consumption
When sharing links across modern chat environments like Slack, WhatsApp, Microsoft Teams, or Discord, automated crawlers fetch the URL to render link unfurlings. In simple burn-after-reading implementations where any HTTP GET request burns the note, these background crawlers inadvertently destroy the message before the intended recipient ever opens it.
Secret Note resolves this issue by isolating page rendering from payload destruction. Opening the URL loads an unencrypted shell showing a confirmation prompt. The ciphertext is retrieved only when the user actively clicks the View note button (at which point one-time notes are permanently deleted from the server, while expiring notes remain until their expiry). This ensures that automated bots cannot trigger accidental deletion. For more background, see our guide on what is a self-destructing note.
Out-of-Band Hardening: PBKDF2 Passwords
A standard one-time link carries an operational risk: if the communication channel is monitored, whoever clicks the link first obtains the message. To defend against compromised transmission channels, Secret Note provides an optional Extra password layer.
This extra passphrase is never sent across the wire. Instead, it is evaluated locally using PBKDF2-SHA256 with 200,000 iterations in compliance with OWASP guidelines. If you transmit the link over email and the password via an encrypted messaging app like Signal, an adversary intercepting only one channel cannot decrypt the note. Furthermore, incorrect password submissions are rejected in the browser without consuming the one-time note on the server.
Honest Threat Boundaries: What Web Encryption Cannot Stop
Sound security practices require recognizing the fundamental limits of web-based confidentiality:
- Recipient behavior: Once decrypted text renders on screen, the recipient can copy it, capture screenshots, or take photographs with an external phone. No software can physically restrict a recipient's local display hardware.
- Endpoint compromise: If either device suffers from active spyware, keyloggers, or malicious browser extensions, secrets can be recorded before client encryption or after client decryption.
- First-to-click exposure: Without an extra password, whoever navigates to the complete URL first will read the message.
The Web Cryptography Dilemma and Server Code Delivery
Every browser-based cryptography tool operates under a core trust dependency: each time a user loads the page, their browser downloads and executes JavaScript served by the remote server. A compromised or coerced hosting provider could theoretically alter the served JavaScript to leak keys.
To make this trust relationship as transparent and verifiable as possible, not.saklama.com strictly avoids all third-party tracking scripts, ads, and external dependencies. All client-side JavaScript is served unminified and cleanly formatted, allowing security professionals and curious users to inspect the live cryptographic code directly in their browser developer tools. For a broader comparison of credential transmission tools, see our analysis of one-time links versus one-time passwords.
| Threat / Attack Scenario | Protection Status | Defense Mechanism & Technical Boundaries |
|---|---|---|
| Server Database Compromise | Full Protection | The server holds only AES-GCM-256 ciphertext; decryption keys never touch the host database or filesystem. |
| Network Eavesdropper (ISP / Wi-Fi) | Full Protection | Protected by TLS encryption; additionally, RFC 3986 prevents URL fragments (#) from entering HTTP requests. |
| Link-Preview Crawlers | Full Protection | Crawlers only receive metadata; the payload is fetched only when a user clicks 'View note' (and deleted at that point for one-time notes, while expiring notes persist until their expiry). |
| Communication Channel Interception | Partial Protection | An optional password sent out-of-band via a separate channel prevents attackers from decrypting intercepted links. |
| Recipient Screen Capture | Unprotected | No browser technology can prevent a recipient from copying text, capturing screenshots, or taking photos. |
| Endpoint Malware (Keylogger) | Unprotected | Malware on the sender or recipient operating system can intercept text before encryption or after decryption. |
| Malicious Server Code Delivery | Trust Assumption | Users trust the JavaScript served on each visit. Unminified source code and zero trackers enable direct audits. |
Frequently Asked Questions
Will my note leak if the saklama.com database is breached?
No. The server stores only AES-GCM-256 ciphertext. The decryption key exists solely in the URL fragment (#) on the sender and recipient devices, meaning attackers cannot decrypt the database contents.
Can my network administrator or ISP inspect my secret?
No. All connections are secured via HTTPS, and browsers strip the URL fragment (#) before dispatching network requests per RFC 3986. Network observers can only verify that you accessed not.saklama.com.
Can Slack or WhatsApp preview crawlers burn my note?
No. Secret Note employs a two-step viewing flow. Visiting the link displays an informational prompt; one-time notes are fetched and burned only when a human user clicks the 'View note' button (while expiring notes remain accessible until their expiration time).
Can you prevent a recipient from taking a screenshot?
No. Web applications cannot control the recipient's operating system, screen recording tools, or physical cameras. Once decrypted, client-side data capture cannot be technically prevented.
Why is the optional extra password beneficial?
It establishes two-channel security. Senders can deliver the link via one medium (like email) and the password via another (like SMS or Signal), preventing eavesdroppers from accessing the payload with the link alone.