Security & trust
What protects your reading, and what doesn’t yet
Every page like this one lists strengths. The part worth reading is the second half.
How your data is protected
| Control | What it means for you |
|---|---|
| Per-account isolation in the database | Every table carrying your data is protected by PostgreSQL row-level security, forced on, so a query can only ever see rows belonging to the account it is running for. It is not a filter the application remembers to apply — it is a rule the database enforces underneath the application. |
| Private content stays private | Documents you import are stored per-account. They are never pooled with other readers’ content, never shared, and never used to train anything. |
| Your card never reaches us | Payment details are entered on Stripe’s own hosted checkout. Card numbers do not pass through, and are not stored on, our servers. |
| An append-only payment record | The payment audit trail cannot be edited or deleted through the application at all — enforced three ways, including a database trigger that survives a misconfigured permission grant. |
| Secrets are never in plain text | Credentials live in a secrets manager and are delivered to running services at start-up. They are not in the source code, not in the container images, and not in configuration files. |
| Passwords, and getting locked out | Passwords are hashed, never stored or logged. A reset link is single-use, lasts one hour, and signs out every other device when used — so a reset actually evicts someone who should not be there. The reset form answers identically whether or not an address has an account, so it cannot be used to find out who is a customer. |
| Your own hardware, not a rented one | The database, object storage and application all run on machines we own. That is a cost decision first — it is why the subscription can be priced the way it is — but it also means your reading is not sitting in a third party’s multi-tenant system. |
| No trackers, anywhere | There is no advertising technology, no third-party analytics and no cross-site tracking in this product. The only third-party script is Stripe’s, on the checkout page alone. Usage analytics are first-party, stay in our own database, and are described on the privacy page. |
What we have not done yet
This section exists because a security page without one is marketing. Everything here is true as of the last review of this page, and each item is work we intend to complete — listing it is not an excuse for it.
No independent assurance
- We hold no third-party audit or accreditation of any kind. No SOC 2, no ISO 27001, no equivalent. If a supplier questionnaire asks, the honest answer is none.
- No external penetration test has been carried out. The security work here is our own review of our own system, which is exactly the arrangement independent testing exists to correct.
- There is no bug bounty. There is no budget for one yet. Reports are answered by a person, and researchers are credited by name with their permission.
Isolation between services is weaker than we want
- Our application runs on a cluster shared with other projects. A cluster-wide network rule predating this product currently grants every workload on it broad network reach, which means the network isolation we have written for Readeroom specifically does not take effect the way it should. We have narrowed what we can from our own side; fully correcting it is a change to shared infrastructure and is scheduled.
- Traffic between our own services is not yet encrypted in transit inside the cluster. The service mesh that was intended to provide it is not active on these workloads. Traffic between you and us is encrypted normally; this is about the hop between our own components on our own machines.
Availability
- We run a single site, and there is no off-site copy of it yet. The database is backed up nightly and kept for 30 days, which is what protects you against the failures that actually destroy data — a bad migration, a mistaken deletion, a defect in our own code. Those replicate to a live replica in milliseconds, so a replica has never been a backup, and until 2026-07-20 a replica was all we had. What the nightly backup does not cover is loss of the building: it is written to storage in the same facility as the database. That is a genuinely different failure domain from the database machine, and it is not geographic redundancy, and we would rather name the gap than let the word “backup” imply it is closed. The off-site copy is the next item, and it will be encrypted before it leaves. We do not claim an uptime figure we cannot hold — see the availability clause.
- The backup is verified by restoring it, not by trusting it. Worth stating because it is the part most often skipped: every backup is rebuilt into an empty database and compared against the original object by object — tables, columns, indexes, triggers and, above all, the row-level rules that keep one account’s data unreadable to another. The first time we ran that comparison it caught a restore that looked perfectly healthy and had silently lost five of those rules. An unrestored backup is a hope.
- Each service currently runs as a single instance, so a routine node maintenance can cause a brief interruption. Reading a document you already have open is unaffected.
Measurement, not security, but stated here anyway
- Our reading measurements have not been through formal reliability testing yet — no test–retest or alternate-form study. We therefore describe results as measurements rather than as scores with a known margin, and the method page says what the evidence does and does not support.
Reporting a vulnerability
Please tell us. Send it to security@readeroom.com — the address is also published at /.well-known/security.txt.
- We aim to acknowledge within two working days and to respond substantively within five.
- Please give us a reasonable window to fix an issue before publishing it, and please do not access, modify or retain another reader’s data while demonstrating one — a proof-of-concept against your own account is always enough.
- We will not pursue or threaten legal action over good-faith research that follows the two points above.
- Researchers are credited by name here, with their permission.
If something goes wrong
During an incident this page does not change — it is served from the same system that may be having the problem. That is why our current status is kept separately, off our own infrastructure, where a problem here cannot take it down too. If you cannot reach us at all, the security address above is the one to try.
If an incident affects personal data, we will say so directly rather than waiting to be asked, and we will say what was affected, what was not, and what changed as a result.
Changes to this page
This page is reviewed whenever the underlying system changes materially. It describes the product’s security posture; it is not a contract. The commitments that are contractual are in the terms, and what we do with your data is on the privacy page.