Security

This page describes how Obsydian is actually built and operated today — not what we intend to build. Where a control is missing, it says so, because the useful version of this document is the one you can check.

1. The short version

• All traffic to and from Obsydian is encrypted in transit (TLS).
• Your database records and your stored files are encrypted at rest.
• Image and video metadata scrubbing runs in your browser — those originals never reach our servers at all.
• The vault can be locked behind a passcode, a passkey, or an authenticator code, separately from your account login.
• We never see your card details; Stripe handles them.
• We hold no SOC 2 or ISO 27001 certification and have not commissioned an independent penetration test. See section 7.

2. Accounts & access

Authentication. Sign-in, sessions, passwords and multi-factor enrolment are handled by Clerk, a dedicated identity provider. We never store your password — not hashed, not anywhere. Enabling two-factor authentication on your Obsydian account is done through Clerk and we recommend it.

Authorisation. Every request for content — a vault file, an analytics figure, a draft page — is checked against the signed-in account on the server before anything is returned. For anything behind your login, knowing or guessing an identifier is not enough to read something that is not yours. The images on your public page are the deliberate exception: they are served from a public media URL so that anyone you send your page to can load them, which means anyone holding that URL can load them too, including after you change the photo or take the page offline.

Staff access. Obsydian is operated by a very small team. Access to production systems is limited to those who need it to run the Service, and is used for operating the platform, investigating abuse reports, and complying with the law — not for browsing your content. See the Privacy Policy for the legal framing of that access.

3. How your files are stored

In transit. Everything travels over HTTPS/TLS, including uploads and downloads.

At rest. Vault files are stored in Cloudflare R2. Since 4 September 2026, every file uploaded to the vault is encrypted with its own AES-256 key, derived fresh on each request and never stored by R2 — so an attacker who obtained the storage bucket and nothing else would get ciphertext, not your files. Files uploaded before that date remain encrypted under keys Cloudflare manages. Account and profile records live in a managed Neon PostgreSQL database, also encrypted at rest.

Vault objects are not publicly addressable. Every read goes through an endpoint that checks the file belongs to the signed-in account and that the vault lock is open, and uploads use short-lived signed URLs that expire.

The honest limit. None of this is zero-knowledge encryption. We are not able to offer client-side encryption of vault files while also offering the features people buy Obsydian for: thumbnailing, integrity verification, the watermarker's vault round-trip, and — above all — scheduled leak scanning, which compares your stored files against material found elsewhere on the internet. A scheduled scan cannot borrow your browser to decrypt. That is a genuine trade-off and we have resolved it in favour of the protection features, which means you should treat the vault as encrypted storage operated by us, not as a sealed container we cannot open.

4. The vault lock

The vault can be locked independently of your account login, so that someone with an unlocked phone or a live browser session still cannot open it. Three methods are supported, and you can use more than one:

• A passcode, stored only as a scrypt hash with a per-user random salt — a deliberately slow, memory-hard function — and compared in constant time. We cannot recover or read your passcode.
• A passkey / biometric (WebAuthn — Face ID, Touch ID, Windows Hello, or a hardware key). The private key never leaves your device; we only store the public key.
• An authenticator app (TOTP). The shared secret is encrypted with AES-256-GCM before it is stored.

Failed unlock attempts are rate-limited, and the lock re-arms on a timeout you control.

5. What never reaches us

The strongest privacy guarantee any service can give is that it never receives the data in the first place. Two parts of Obsydian work that way:

• Video metadata scrubbing runs entirely in your browser. The original video file is never uploaded to Obsydian — not to be processed, not temporarily. You can confirm this yourself in your browser's network inspector.
• Image EXIF/GPS stripping happens on your device for vault uploads, before the file is sent anywhere, so the copy that reaches our storage has already had location, timestamp and device fields removed. Photos for your public page — avatar, cover, link images — are stripped on our servers instead, after upload: the original reaches us, the stripped copy is what gets stored and served.

One qualification on that second point, because it is the kind of detail this page exists to state rather than gloss. Stripping metadata would otherwise be a one-way door, so the vault keeps what came off as a small patch stored beside the file — that is what lets Download camera original rebuild the shot exactly as your camera wrote it, down to the same fingerprint. It means the removed fields, location included, do reach our storage: inside that patch, encrypted under its own derived key the same way the file is, never attached to the copy you send anyone. Deleting the item deletes the patch with it.

The patch is skipped where it would cost more than it saves — a large PNG or WebP that stores metadata at both ends of the file, where the span between them is the whole image. Those items say so on their own record in the vault, and cannot be rebuilt. Everything a phone shoots — JPEG, HEIC, MP4, MOV — keeps its metadata at one end and is always restorable.

The same is true of the face-detection and blur tools: the models run locally in your browser, and the frames they analyse are not sent to us or to any third party.

6. Payments

Card details are collected and stored by Stripe, a PCI DSS Level 1 certified provider, and never touch Obsydian's servers. We receive only what we need to run your subscription: the plan, its status, the last four digits and the card brand. Partner commission is paid through Stripe Connect, which collects payout details directly from the partner.

7. What we don't have yet

Obsydian is a young product operated by a small team, and pretending otherwise would defeat the point of this page. As of the date above:

• No SOC 2 or ISO 27001 certification. Both are expensive, multi-month audit programmes, and we have not undertaken either.
• No independent penetration test has been commissioned. When one is, we will publish the fact and the date here.
• No bug-bounty programme — but see section 9; we welcome reports regardless.
• No zero-knowledge storage, for the architectural reason given in section 3.

If any of these are requirements for the material you are considering storing, the right answer is to keep that material out of the vault until we can say otherwise on this page.

8. If something goes wrong

If we become aware of a personal-data breach, we will assess it without undue delay and, where the law requires it, notify the UK Information Commissioner's Office within 72 hours of becoming aware. Where a breach is likely to result in a high risk to your rights and freedoms, we will tell you directly, describing what happened, what data was involved and what you should do.

Deleted content is removed from live systems promptly; limited copies may persist in encrypted backups until they are overwritten on our normal backup cycle. See Privacy, section 10.

9. Reporting a vulnerability

If you believe you have found a security issue, please email support@obsydian.vip with enough detail to reproduce it. We will acknowledge your report, keep you updated while we investigate, and credit you if you would like us to.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly, and that you do not access, modify or delete another user's data while testing — a proof of concept against your own account is always enough. We will not pursue researchers who follow that.