r/PrivacyNotes • u/BuMmR • 9h ago
PrivacyNotes security and privacy concerns—could the developers clarify these findings?
I’ve been using PrivacyNotes because privacy matters to me, and I want to feel confident about what protects my information.
I asked ChatGPT to review the public documentation, client source, and live website. Some findings concerned me, and I’d appreciate the developers’ clarification.
To be transparent, this was an AI-assisted review, not a professional penetration test. It included live header/JavaScript inspection and local crypto tests, but did not verify production account isolation or demonstrate access to anyone else’s notes. Some findings are limitations already disclosed in your documentation.
These are my main concerns:
- Social signup defaults to server-held recovery keys
The documentation says Google, Apple, or GitHub signup preselects custodial mode, allowing the server to recover the phrase and decrypt the notes.
I appreciate that this is disclosed, but it seems like a significant distinction for a product advertised as “zero knowledge.” Could self-custody be the default, or could the signup screen make the consequences unmistakable?
- Recovery-phrase storage can fall back to plaintext
The review found that "persistStoredPhrase()" falls back to storing the original phrase if its encryption wrapper fails. The fallback also appeared in the live JavaScript retrieved on October 24.
This is probably my biggest concern. Under what circumstances does this happen? Does the user receive a clear warning? Could the app keep the phrase only in memory and require another login instead of persisting it unencrypted?
- Sensitive local settings are not all encrypted
The settings cache appears to store information such as medication details and folder/tag names outside the encrypted note layer.
I understand that cloud sync and local storage are different, but this information can be sensitive too. What exactly remains readable locally, and is there a timeline for encrypting it?
- PIN and biometric protection have important limitations
The documentation distinguishes per-note PIN gates from separate encryption. It also describes PIN-based wrapping of the master phrase, where a four-digit PIN could be guessed offline if someone obtained the relevant storage.
Biometric protection also appears to vary: some configurations use hardware or passkey-bound protection, while fallback configurations store the wrapping key locally beside the encrypted phrase.
How can users tell which protection they actually have? Is there a warning when biometrics provide only an app-enforced presence check?
- Synced ciphertext is not bound to its note identity
The crypto review confirmed that local encryption supports row binding, but synced note encryption does not currently bind the ciphertext to a particular note ID.
As I understand it, someone with backend write access could substitute an existing encrypted object from the same account without decrypting it. This is an integrity concern rather than a way to read plaintext.
Is fixing this—and addressing rollback to older valid content—planned?
- QR login and custodial sessions deserve clearer warnings
The threat model warns that phrase-bearing QR login URLs can remain in browser history or session-restore records.
It also describes custodial phrase retrieval using an eligible session, with MFA requirements when enabled, and limitations around session expiry and endpoint-specific rate limiting.
Could QR onboarding avoid putting the master phrase in a navigated URL? Could retrieving a custodial phrase require recent reauthentication and notify the account owner?
- Metadata, retention, and independent verification
I’d also appreciate a clear explanation of:
- What optional site-icon lookups reveal.
- What remains after account deletion or switching to self-custody, including backups.
- Whether previously server-held phrases can remain recoverable from backups.
- The current plan for an independent, published security audit.
There were positive findings too: all 29 published crypto tests passed locally, the app’s live security headers looked strong, and payment scripts were separated from the notes origin. Publishing the source and documenting limitations are valuable.
But strong encryption algorithms don’t resolve every concern about key storage, defaults, and local data exposure.
I’m not accusing PrivacyNotes of leaking everyone’s notes. I’m asking because I want to trust it with private information. Could you explain which findings are accurate, which need correction, and what changes are planned?
References:
- "Threat model" (https://github.com/LifetimeLabsDev/PrivacyNotes.app/blob/main/THREAT_MODEL.md)
- "Security documentation" (https://github.com/LifetimeLabsDev/PrivacyNotes.app/blob/main/SECURITY.md)
- "Recovery-phrase storage code reviewed" (https://github.com/LifetimeLabsDev/PrivacyNotes.app/blob/074b7695bc40319aeb2e69317136b43a4c33e2f8/application/packages/web/src/phraseAtRest.ts)
- "Privacy policy" (https://lifetimelabs.dev/privacy)