An honest account of what Palarid's architecture protects against — and what it does not.
Last reviewed: July 2026
The strongest security property
There is no server holding your data. Palarid has no user database, no account system and
no stored personal records. A breach of our hosting would expose no user information, because
none is there. This is the single most meaningful security property of the product, and it comes
from the architecture rather than from a policy promise.
What browser storage does not protect against
Local storage is not encrypted storage, and we will not call it that. Anyone with access to
your unlocked device and browser profile can read what Palarid has saved. Browser extensions with
broad permissions can read it too. If you share a computer, use a separate browser profile, or do
not store sensitive material in Palarid.
Your device's own protections — screen lock, disk encryption, account separation — are what
actually guard this data. Palarid sits inside them; it does not replace them.
What we have hardened
No secrets in the codebase. Palarid ships no private API keys. The only keys involved are ones you choose to add.
Keys are never placed in URLs, never logged, and never sent anywhere except the provider you selected.
Key fields are masked, autocomplete is disabled, and the storage limitation is stated at the point of entry rather than buried in a policy.
Destructive actions are protected — irreversible deletions require explicit confirmation, take a snapshot first, and offer a short undo window.
Corrupt-storage recovery — malformed local data is handled without breaking the app, and quota exhaustion is caught rather than silently losing writes.
Non-destructive migrations — an upgrade backs up existing data before converting it, and is safe to re-run.
Third-party surface is small — a map library, a QR decoder, and whichever AI provider you opt into. No advertising or tracking networks.
The code playground is sandboxed. The Live Coder tool runs your HTML, CSS and JavaScript in an isolated frame with its own opaque origin. Code executed there cannot read your stored data, your API keys, or anything else on the page.
Injected markup cannot phone home. The Content-Security-Policy blocks any form from submitting to another domain, blocks <base> injection (which would silently repoint every script on the page at an attacker's server), and blocks plugin content entirely.
Powerful browser features are denied by default. Camera, microphone, location and screen capture are permitted only for Palarid itself and only because named tools use them. Bluetooth, USB, serial, MIDI, payment and device sensors are switched off at the HTTP layer, so a bug could not reach them.
No referrer is sent on outbound links. Palarid links to debt charities, NHS pages and crisis resources. Those sites are told nothing about where you came from.
Fixed in July 2026
Recording these rather than quietly patching them, because a security page that only lists
strengths is not a security page.
The code playground was not sandboxed. The Live Coder tool rendered your code in a frame that shared Palarid's origin, which meant script running there could read everything in local storage — journal entries, financial figures, health logs, saved API keys, and the password vault while it was unlocked. It now runs with an opaque origin and no access to the parent page. Fixed 27 July 2026. We have no evidence it was exploited; the tool requires a person to type or paste code themselves.
Two third-party scripts loaded without integrity checking. The map and QR libraries are loaded from public CDNs. They are version-pinned, but a compromise of either CDN would have executed attacker code with full access to your data. The prerequisite attribute is now in place; the integrity hashes themselves are the next step (see below).
Known gaps
Still open, stated plainly.
Subresource Integrity hashes are not yet applied to the two CDN libraries. Until they are, a compromise of jsDelivr or unpkg would be a compromise of Palarid. This is the highest-priority open item.
The password vault uses 100,000 PBKDF2 iterations. That met OWASP guidance when written; current guidance for PBKDF2-HMAC-SHA256 is 600,000. Raising it requires a migration that re-derives every existing vault on next unlock — worth doing carefully rather than quickly, because a mistake would make vaults permanently unopenable.
Content-Security-Policy is partial. The directives that could be verified safe are enforced. A full policy including script-src is deployed in report-only mode while the real allowlist is measured. The app contains a large amount of inline JavaScript, so a script policy strict enough to actually stop cross-site scripting requires restructuring first.
No end-to-end encrypted sync yet. Until it exists and has been reviewed, we will not use the word "encrypted" to describe stored data.
No formal third-party penetration test has been carried out.
Palarid is maintained by a very small team. Response times to reports will reflect that.
Reporting a vulnerability
If you find a security issue, please report it before disclosing it publicly. We will confirm
receipt, investigate, and credit you if you would like to be credited.
Use the report form and mark it as a Safety concern.
Please include steps to reproduce. Do not include other people's personal data.
Please do not test against other users, degrade the service, or access data that is not yours.
If you are worried about your own data
Export a backup now — Settings → Data → Export. It is a plain JSON file you control.
Remove any provider key you no longer use.
Clear a category rather than everything, if you only want to remove one kind of record.