Technical assessment of Privnote's security model and posture
Privnote implements client-side encryption using AES-256. The encryption process occurs entirely in the user's browser before any data is transmitted to Privnote's servers. The decryption key is embedded in the URL fragment (the # portion), which is not transmitted to servers in standard HTTP requests. This means Privnote's servers store only encrypted ciphertext and never have access to plaintext note content.
This is a meaningful security property. Even a complete compromise of Privnote's server infrastructure would not expose note content, because the servers do not hold decryption keys. The security of the system depends on the integrity of the JavaScript code served by Privnote's website.
Users must trust that Privnote's JavaScript code correctly implements the described encryption and has not been tampered with. Since Privnote is not open-source, this cannot be independently verified. Users are also trusting that Privnote actually deletes notes after reading rather than retaining copies.
For most everyday use cases, this is an acceptable trust model. For highly sensitive data requiring verifiable security guarantees, open-source alternatives with audited code should be considered.
When a note is accessed, Privnote's server marks it as read and deletes the stored ciphertext. Subsequent attempts to access the same URL return a "note not found" response. The deletion is permanent — there is no recovery mechanism, no backup, and no way to restore a destroyed note.
The self-destruction mechanism only prevents re-access via the URL. It does not prevent the recipient from copying the text, taking a screenshot, or recording their screen. The system also cannot prevent an attacker who intercepts the URL from reading the note before the intended recipient. Password protection significantly mitigates the link interception risk.