Draft, pending legal review. This page has not yet been reviewed by a lawyer. It describes how epnote works today and will be updated once it has been checked.
Security
Last updated 20 October 2026. epnote is operated by PASTE_YOUR_FULL_LEGAL_NAME, 57299672066.
On your device
Your documents are stored in your browser's own database (IndexedDB), encrypted with AES-256-GCM using a key generated on your device. Your letterhead, signature and saved tests are stored on the device too. A backup you export is encrypted with a passphrase only you know, and cannot be opened without it. We cannot read any of this, and nothing in the app sends it anywhere.
Two honest limits: the device key is stored beside the data, so this protects against casual reading of the browser's files, not against someone who has your whole device or a malicious extension running while you are signed in. Your device's own disk encryption (FileVault, BitLocker) and screen lock are the real protection at rest, and the app's data should be cleared from any device you stop using.
Nothing about patients on our servers
An export asks our server for permission with the type of document and a random identifier, never the content. An account holds your email, your name if you gave one, your plan, export count and practice settings, and the server refuses any other field. Feedback is free text you type and we ask you not to put patient details in it. Our logs record the method, path, status and duration of each request and never what was sent.
epnote is hosted by Vercel and its server functions run in Vercel's Sydney region, pinned in the project's configuration. Vercel is a US company, so its own request logs, which record the method, path, status and duration of a request and never what was sent, may be processed outside Australia. The account database is Supabase in Sydney.
In transit
Every connection to epnote, to Supabase and to Resend uses HTTPS (TLS). Our responses carry a content security policy that lets the page load code only from its own origin, forbids framing by other sites and never allows eval in production, along with the usual browser protections (no sniffing of content types, a strict referrer policy, HSTS).
Accounts
You can sign in by Google, by email and password, or by a one-time link sent to your email. A sign-in link works once and expires. With Sign in with Google, Google checks who you are and epnote never sees a Google password. If you set a password, Supabase stores it hashed and epnote never sees it either; a reset is a one-time link to your email address. In the account database, row level security means a signed-in user can read only their own row and change only their own settings; plan and counts change only through the server.
If something goes wrong
If we become aware of a security incident that may involve personal information we hold, we will contain it, assess it quickly and work out who is affected. Where the Notifiable Data Breaches scheme in the Privacy Act 1988 (Cth) applies and the breach is likely to result in serious harm, we will notify the affected people and the Office of the Australian Information Commissioner as the scheme requires, and we will say plainly what happened and what we have done. Because patient and report data never reaches our servers, an incident on our side cannot expose it.
If you find a security problem in epnote, please tell us at epnote.app@outlook.com. We read every report and will reply.
What this page is not
This page describes how epnote is built and run today. It is not a certification, an audit result or a legal opinion, and epnote does not claim one.
Contact
PASTE_YOUR_FULL_LEGAL_NAME, 57299672066. Email epnote.app@outlook.com.