Security

1. Where your books live

Your books, receipts and documents are stored in Canada. They sit in Google Cloud's Toronto region, with a disaster-recovery copy in Montréal. Every piece of server code MedBooks runs is pinned to Toronto, with one exception: the nightly cleanup job runs from Montréal because Google does not offer its scheduler in Toronto. That job only starts work — the records it touches never leave Toronto.

We do not say your data never leaves Canada, because that would not be true. Firebase Authentication — the Google service that checks your email and password and issues your sign-in session — runs only in the United States, and that location cannot be changed. What crosses the border is your email address and sign-in metadata: when and from where you signed in, and your multi-factor settings. Your books, receipts and financial records are not part of it. While that sign-in information is in the United States it is subject to US law, including lawful access requests. The Privacy Policy sets this out in full.

Your device keeps a complete copy too. Everything you enter is written to your own device first and works with no connection at all, then copied to your account in the background. MedBooks does not hold your books hostage — and it keeps working on hospital wifi that does not.

When you delete, we chase every copy. Closing your account revokes any bank connection at the source first, then deletes your files from the Toronto bucket and the Montréal backup, your records, the access log that describes you, and finally the login credential itself. The backup copy is deliberately configured never to expire on its own, which is exactly why deletion has to reach it deliberately. What survives is a minimal receipt recording what was purged and when — proof that we deleted, not a record of what you did.

2. What is encrypted, and when

In transit. Everything travels over HTTPS. Both the app and this site send a one-year strict-transport header, so a browser that has visited once will refuse to connect to MedBooks over plain HTTP at all.

At rest, by default. Your records and files are encrypted at rest with keys Google manages. Stated plainly: under the default setting Google could read them, and so could MedBooks with project access. That is the honest cost of the things it buys you — a password you can reset, books we can help you restore, and support that can actually see what went wrong. We restrict that access, and every support access is written to a log you can read.

Advanced Protection, if you turn it on. Your device generates a 256-bit key that never leaves it. Your password and a 28-character Recovery Key each independently unwrap that key, using PBKDF2-HMAC-SHA-256 at 600,000 rounds — the current OWASP figure — and everything is sealed with AES-256-GCM under a fresh nonce for every single write. The key exists only in memory, only while you are unlocked; locking the app or signing out drops it. Nothing writes it to disk, to your browser's storage, or to our database. With Advanced Protection on, we hold ciphertext and cannot read your books.

Emailed receipts are sealed before they are stored. If you forward a receipt to your MedBooks email address, the server encrypts each attachment to your own public key — an ephemeral key exchange on the P-256 curve, then AES-256-GCM — before writing anything down. Once that delivery finishes, the server cannot read the receipt it just delivered to you.

Support access, under Advanced Protection, is one door you open. There is no master key and no standing access, because there is no stored key to give anyone. If you choose to grant support access, the key is wrapped for that one grant, for that one window; you see a banner the whole time; you can revoke it instantly; and it expires by itself. Every access is recorded in a log your account can read and no browser — ours included — can write to.

3. Who can get in

MedBooks is invite-only. Anyone can create a sign-in, and until an administrator approves that account it can read nothing, write nothing and spend nothing. Approval lives in a record only the administrator can write, and the administrator is pinned by account ID rather than by email address — an email can be claimed at sign-up, an account ID cannot. The AI endpoint checks the same approval again in its own code, because the database rules do not govern that kind of endpoint.

The database denies by default. There is no catch-all rule. A signed-in, approved user can read and write exactly one thing: their own records. Settings the server owns are readable by everyone signed in and writable by no one, so nobody can rewrite their own retention window by hand. Several collections — the bank-connection tokens above all — have no browser-facing rule at all, which in this database means no browser can reach them under any circumstances. Only server code can.

File storage is owner-only. You read and write files under your own account and nowhere else; uploads are capped at 25 MB and limited to images, PDFs, CSVs, or opaque ciphertext; everything outside your own area is denied to everybody. Both sets of rules are exercised by an automated test suite against a local copy of the database, and it runs on every change to them — because one bad rule edit is the single most likely way a product like this leaks.

The keys to other services never reach your browser. The AI provider key, the bank tokens and the email-ingest secret are held as server secrets. The AI endpoint additionally pins the models it will call, caps the size of anything you can send it, and enforces a durable per-account hourly limit that survives a restart.

4. How to tell a real email from us

MedBooks will never email you a link to connect or reconnect a bank. Connecting a bank starts inside the app, on the Bank accounts screen, and nowhere else. If a message asks you to follow a link and reconnect, it did not come from us — however convincing it looks, and however much it sounds like something you were expecting. Delete it. If you genuinely do need to reconnect, open the app and start it there.

We will never ask you for your banking password, and we never see it. The connection is made through Plaid; what MedBooks holds afterwards is a token that can read transactions and nothing else. Any message asking you to reply with a password, a card number or a verification code is a fraud attempt, whoever it appears to be from.

Mail forged from our domain is rejected before it reaches you. medbooks.ca publishes a DMARC policy of p=reject, which instructs every mail provider to refuse messages that claim to come from us but are not signed by us. You can check that in a few seconds: dig +short TXT _dmarc.medbooks.ca.

What that does not stop — and what to look at instead. No mail policy can stop someone registering a domain that merely looks like ours (medbooks-ca.com, or rnedbooks.ca, where “rn” reads as “m” in most screen fonts), or simply setting their display name to “MedBooks Support” on an ordinary address. Mail like that passes every technical check, because it is honestly sent by whoever registered it. So read the actual address rather than the name your mail app shows you, and treat any link asking for bank access as false until you have checked.

If something arrives claiming to be from MedBooks and you are not sure, do not follow it — send it to us instead, the same way you would report a security problem.

5. What we do not do with your data

• We do not sell your personal information — not to data brokers, not to lenders, not to anyone.
• We do not use your books to train AI models. Documents you ask MedBooks to read are read and returned; they are not kept to improve a model.
• We run no advertising or analytics trackers. No pixels, no session replay, no third-party scripts at all. This page loads nothing from anywhere else, and the content-security-policy header it is served with sets script-src 'none' — a browser would refuse to run a tracker here even if one appeared. You can check that yourself in about ten seconds: view the source of this page, or read the response headers.
• We do not want patient information, and MedBooks is not built for it. The app reads the aggregate amounts that arrive in your bank account. It does not parse OHIP remittance advice and has no access to health numbers, fee codes or diagnostic codes. Please do not put patient information into MedBooks — it is not designed or permitted for it.

6. Everyone who touches your data

The complete list. If a company is not on it, your data does not reach them.

There is no payment processor today. MedBooks is free during the invite-only beta and holds no card details, because it has no way to take them. When billing starts, the processor will be named on this page and in the Privacy Policy before the first charge, not after it.

7. What MedBooks cannot do, and does not promise

A security page that only lists strengths is marketing. These are the limits, and they are the part worth reading twice.

MedBooks holds no security certification, and this page does not imply one. There is no SOC 2 report, no ISO 27001, and no independent penetration test. The software has been reviewed by the person who wrote it and by automated tests, and by nobody else. An audit costs real money and MedBooks is a free beta; when that changes we will say so here with a date, not a badge.

Whoever can publish the code is the real trust anchor. MedBooks is a web app — your browser downloads fresh code from our servers every time you open it. Anyone able to publish that code could publish a version that behaves differently, one that quietly sends a key somewhere before encrypting. No database rule, no key design and no header prevents that. It is true of every web application that encrypts inside a browser, including ones that market themselves otherwise, and it is precisely why this page explains the limit instead of reaching for the marketing phrases that imply a vendor is locked out of your data by mathematics alone. With Advanced Protection on we hold ciphertext and cannot read your books — that claim is true, and it is the strongest one we are willing to make. The stronger-sounding phrases you will see elsewhere quietly rest on the same assumption this paragraph has just made explicit: that the code you were served is the code that was described to you. What we can tell you is how that publishing power is held today: one owner and no other accounts on the project; no downloadable service keys and no automated deploy token, the kind of credential that works forever and ignores two-factor; and passkey sign-in on the account that can deploy. If you are evaluating any web-based product that stores something this sensitive, this is the question to ask its vendor.

Under the default setting, we can read your books. Said once more because it is easy to skim past in §2. Advanced Protection is how you take that ability away from us, and it costs you the ability to be rescued.

Your own device is outside all of this. Someone with your unlocked laptop or phone can read your books, with or without Advanced Protection. Device encryption, a screen lock and a passcode are the controls that matter there, and they are yours to set.

We do not run a bug bounty. There is no money for one yet, and promising a reward we cannot pay would be worse than saying this. Reports are still very welcome — see below.

If something goes wrong, you will hear it from us. Canadian law requires that a breach creating a real risk of significant harm be reported to you and to the Office of the Privacy Commissioner as soon as feasible, and that every breach of safeguards — including the harmless ones and the near-misses — be recorded for two years. We keep that register, and it was created before the first incident rather than after it.

8. Reporting a security problem

If you have found something, please tell us at admin@medbooks.ca. Put “security” in the subject line so it does not sit in a queue. What helps most: what you did, what you saw, and roughly when.

We will not pursue legal action against anyone who reports a problem in good faith, works only against their own account, does not access or alter anyone else's data, and gives us a reasonable chance to fix the issue before publishing it. If you tell us about something real, we will tell you what we did about it.

Machine-readable contact details are at /.well-known/security.txt.

9. How to check this page

Claims are cheap. Several of the ones above can be verified from outside MedBooks, without taking our word for anything:

• The absence of trackers on this site: view source, or read the content-security-policy response header.
• Transport security on both the site and the app: read the strict-transport-security header.
• Where the app's server functions run: their addresses carry the region in them, visible in your browser's network inspector while the app is open.
• What the app tells its own users about Advanced Protection: the wording in §2 above is the wording inside the product, deliberately.

If any of this stops being accurate, that is a defect — report it the same way you would report a bug. This page carries a version and a review date at the top for exactly that reason.