How OCADE protects your work

HTTPS is enforced by the browser, not just offered. Every public response carries HSTS with a one-year max-age, so after a first visit the browser refuses plain HTTP to this host without asking anyone. It is deliberately scoped to this host and is not submitted to the browser preload list, because both of those are close to irreversible commitments about hosts this code cannot see.

A content policy limits what the page may load and where it may send. Scripts come from this origin only — a third-party player script was found being blocked on every public page and removed rather than allowed. Framing is denied, MIME sniffing is off, the referrer is trimmed cross-origin, and the permissions policy withholds geolocation and USB outright while keeping camera, microphone and payment to this origin.

Browser-only records are encrypted at rest with AES-GCM. Each record's value is encrypted under a data-encryption key that exists only in memory, derived from your passphrase with PBKDF2-SHA256 or wrapped by a hardware authenticator through the WebAuthn PRF extension. The key is never written to disk and never leaves the device.

Record metadata is NOT encrypted, and that is a deliberate trade. Identifiers, data classes and timestamps stay in the clear so the product can list and search without asking you to unlock first. Someone with access to the browser profile could therefore see how many records of each kind exist and when they changed — but not what any of them says.

Offline Intelligence lives apart from your account data. The model is stored in the browser's private origin filesystem, not in the account database and not in the record store. Deleting account data, deleting private data and signing out all leave it in place; only the model vault's own uninstall removes it, and only when you ask for that specifically.

Limitation. Anything held on your device is protected by your device. OCADE cannot defend a browser profile that somebody else can already read while it is unlocked.

On-device answers do not leave the machine. When OCADE answers with Offline Intelligence, the prompt and the answer are produced in the browser. Nothing about that exchange is sent anywhere, which is also why it keeps working with the network off.

Every answer says which engine produced it. The answer receipt records the engine and the exact sampling settings used, so 'this was answered on my machine' is something you can check rather than something you are told.

A second factor is real TOTP, verified by the auth provider. Enrolment is only protection once a code has been verified, and an unverified enrolment is swept away rather than counted. High-risk actions require both the second factor and a recent proof of it, so a session that authenticated hours ago cannot quietly perform one.

Recovery codes reset your factors; they are not a way to sign in. They are stored as HMACs under a server-side pepper, bound to the account, usable once, and rate-limited by a lockout that lives in the database rather than in a server process — so restarting the server does not restart the attempts.

You can see every signed-in session and end any of them. The list is of real authenticated sessions, not of devices you once approved — a device record outlives a sign-out and answers a different question. Ending a session kills its refresh token immediately; an access token already issued stays valid until it expires, and the page says so rather than implying an instant cut-off.

Server functions take your identity from the verified token, never from the request. There is no parameter anywhere in the session or entitlement paths that names a user, which is what makes 'do this to somebody else's account' impossible to ask for rather than merely refused.

Limitation. Revoking a session ends its ability to renew. An access token issued moments earlier remains valid until it expires, which is a bounded window rather than an instant kill.

Consent is recorded with the version that was accepted. Which legal document version an account accepted, and when, is written append-only under row-level security once an account exists, and kept locally before there is one. Nothing about the record blocks the product if it cannot be written.

Credentials are recognised as credentials and kept out of audit trails. One rule decides what counts as protected text — keys, tokens, recovery codes — and every subsystem that writes an audit line redacts through it, rather than each keeping its own idea of what is sensitive.

OCADE's servers can never answer as your computer. The paired-computer bridge only exists where a machine has been explicitly enabled, and OCADE's hosted deployment never sets that flag — so the endpoint is absent in the cloud rather than merely refusing. That is the whole point of a paired device.

A paired browser must be approved at the computer itself. Requests are signature-checked, origin-checked, expiry-checked and replay-checked, and the only cross-origin allowance is an echo of an origin a person already approved on that machine. The local engine port is never reachable from the browser and is never returned to it.

Row-level security is on, and privileged functions are closed to browsers. Account data is constrained per account in the database itself. The functions that read or revoke sessions bypass row-level security by design and are therefore granted to the service role alone — no browser key can execute them, and a permanent test refuses any new one that is granted more widely.

Data at rest on the server is protected by the hosting provider. Account data lives in managed Postgres at Supabase, and disk encryption there is the provider's, not something OCADE implements. It is named that way rather than presented as OCADE's own control.

Limitation. OCADE does not operate the machines its account data sits on and does not hold their disk-encryption keys. Where the data is stored is set by the Supabase project the deployment is bound to.

An administrator role exists and is checked on the server. Administrative screens verify the role against the database before they load, and being sent to an access-denied page is the expected outcome for an account without it.

Limitation. Organization-wide security policy — enforced second factors, session lifetime rules, single sign-on and directory provisioning — is not offered yet. It is absent rather than present and unenforced.

Report a suspected vulnerability by opening a Security ticket from a signed-in account. It arrives in the administrative support queue attached to your account, which is how it can be followed up.

Please include what you did, what happened, and what you expected. Do not include passwords, one-time codes, recovery codes, private keys or full card numbers — a report never needs them, and a ticket is not the place for them. Please do not run tests that degrade the service for other people or that reach into another person's account.

OCADE does not publish a dedicated security email address, because no such mailbox has been activated and verified on the domain. One will be published here once it exists and delivery to it has been confirmed.

OCADE does not publish an incident history. That is a statement about what is published, not a claim that there have been no incidents — an empty page must never be read as a clean record.

Current component checks are on the status page, which runs from OCADE's own origin and is not an independent status service.

Depending on the features you use, OCADE relies on Supabase for accounts and account data, Cloudflare for delivery, a payment provider for purchases, and — only if you sign in that way — Google for authentication. The privacy notice is the authoritative list and states what each one receives.