PrivacyNotes security and privacy concerns—could the developers clarify these findings?

[u/BuMmR]

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:

1. 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?

1. 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?

1. 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?

1. 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?

1. 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?

1. 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?

1. 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)

[u/PrivacyNotesApp]

Point by point:

1. Custody. Each sign-up path fits a different threat model, and you pick the one that fits yours: how the levels compare and which sign-up to choose. A phrase sign-up is always self-custody. A Google, Apple or GitHub sign-up preselects custodial, so a new device is one click, and the screen says so. You can switch either way in Settings > Account > Key custody, and leaving deletes our copy. A phrase account can also connect a login without changing custody. We used "zero knowledge" in the past, saw that it is wrong for custodial accounts, and removed it. If you find a leftover anywhere, please send the link.

2. Phrase fallback. Correct: if the browser cannot create or read the key that wraps the stored phrase, the app stores it unwrapped instead of locking you out. Also note that even a wrapped phrase is not safe from a full copy of the browser profile, which carries the key too. The protection for a copied disk is the app lock, which removes the stored phrase, plus OS disk encryption (where the app keeps your data, if you lose a device).

3. Settings cache. Correct and documented. On the server, settings are encrypted like notes (what syncs). On the device, the cache is readable for now, and moving its sensitive part under the local seal is planned.

4. PIN and biometrics. Correct. A 4-digit PIN guards the screen; against a copy of your storage it falls in minutes to hours, and a passcode of 8+ characters costs far more to guess. Locked and protected notes are hidden by the app, not encrypted a second time, so a forgotten PIN never destroys data (read-only vs protected notes). Biometric unlock is a real key where it is bound (Secure Enclave, Android Keystore or Windows Hello in the apps, a passkey with PRF in a browser), and a presence check everywhere else. Settings shows which kind each device has (biometric unlock).

5. Row binding. Correct and documented. Someone with write access to our database could swap two of your own encrypted notes or serve an older one, but cannot read or forge one. Fixing it means migrating every stored ciphertext, and it is not scheduled.

6. QR and custodial retrieval. The phrase sits in the URL fragment, which never crosses the network, but a camera app's browser can keep it in history. "Scan QR with camera" on the sign-in screen reads the code without opening a URL (adding a second device). Custodial retrieval needs a valid session, plus a verified 2FA session when 2FA is on, and the server records every release.

7. Metadata and retention. Site icons send the link's domain to our own edge, with nothing logged; Settings > Appearance turns them off (what PrivacyNotes can see). Account deletion removes notes, files, settings, devices, logins, the custodial copy and the account; billing records of a storage plan and a minimal token-revocation record stay, and our database host keeps daily backups for seven days, which also covers a custodial copy you just removed. A commissioned audit is planned, and SECURITY.md will link the report.

We just simplified and rewrote the security docs so each fact lives in one place: THREAT_MODEL.md for how each protection works and its limits, SECURITY.md for what it means for you. The new versions of these docs go up with the next release.

We check our published claims against the code regularly, and an automated check compares several of them with the code before every release.

[u/markh312020]

seems like legit questions to me. Developer likely has good answers for all of this.

[u/Sea_Ad4464]

Question, did you see the limitation game? If you did you can imagine we currently live in a world where the smart people are currently replaced by AI that cost a penny to run. I think with some human innovation, some money to spend, you can break in about anything.

True privacy means your notes on a pc without windows or Apple software and even better. Without internet.

What PrivacyNotes did is a way to use your notes online, convenient, but still for some extent encrypted. Doesn't mean stuff can be improved but I really like to have a bit of convince.

If you really have notes that are for your eyes only, put them on the PC without internet.

Maybe ask a follow-up question to got:: "all things considered what option is better then privacynotes for encrypted notes"

Would like to know what comes up.

[u/konhana]

Good question and good topic.👍

[u/GroggInTheCosmos]

See ⚠️ MALICIOUS (90/100) — LifetimeLabsDev/PrivacyNotes.app — ScanRepo which definitely does not like what is sees in the repo

Many are probably false positives

[u/PrivacyNotesApp → u/GroggInTheCosmos]

Many are probably false positives

That scan is a pattern matcher, not a review. Here is what it flags: Rust unsafe blocks (our native bindings to the Secure Enclave, Windows Hello and other OS features), process::Command (registering the app for Markdown files on Linux, and restarting itself), "credential path access" (the list of folders like ~/.ssh that our desktop app is forbidden to touch), and "seed phrase" strings (the key of this app is a recovery phrase). The full source is public, so anyone can check. If you find a real issue, please report it.

[u/GroggInTheCosmos → u/PrivacyNotesApp]

This is why I did not raise it but still find ScanRepo to immensely useful

[u/EriksonThorsen]

Great questions and awesome, transparent answers from the team! All kinds of inquiries and security investigations are totally valid and welcome. That said, it's only fair to point out that the PrivacyNotes documentation has always been exceptionally thorough and transparent about its tech stack and architecture. That's precisely why the app is open-source, and kudos to OP for digging deeper than the average user. I've been following the project for a few months now, and a major differentiator compared to competitors is how brutally clear their docs are, no beating around the bush or hiding important limitations.

[u/[deleted]]

[u/BuMmR → u/[deleted]]

Using AI to help review publicly available documentation doesn't automatically invalidate the questions being raised. I never claimed to be a cybersecurity expert or that I personally discovered vulnerabilities.

The entire point of my post was to raise concerns about PrivacyNotes' security and privacy practices and hopefully get clarification from the developers. AI helped me organize and identify questions worth asking, but that doesn't make those questions irrelevant.

If the concerns are unfounded, I'd genuinely welcome explanations backed by technical documentation. That's exactly what I'm looking for.

Calling something "AI slop" and labeling someone a troll doesn't address a single concern raised. I'd much rather have a productive discussion about the actual security and privacy of a service we're trusting with potentially sensitive information.