Security at Obiter.

1. What this page is

A plain description of how we protect your account and your work. It says what we actually do, not what we aspire to. Where a control is not in place, it says so — a security page that only lists strengths is not much use to anyone deciding whether to trust us with their notes.

Obiter is a small team. That shapes the answers below: we lean heavily on well-run infrastructure providers rather than operating our own, and we have not bought certifications we could not honestly maintain.

2. Your data in transit and at rest

• In transit: everything is TLS. HTTP Strict Transport Security is set on our domains with a two-year max-age, including subdomains, and we are on the HSTS preload list, so browsers refuse plaintext to us before they have ever spoken to us.
• At rest: the database and file storage are encrypted at rest by our hosting provider.
• Third-party tokens: where you connect Google Calendar, Outlook, Google Drive, OneDrive or Dropbox, the access tokens we hold are encrypted with AES-256-GCM using a key held outside the database, so a copy of the database alone does not yield access to your connected accounts.
• Passwords: hashed with bcrypt. We cannot read your password, and nobody at Obiter can recover it for you — only reset it.

3. Browser-side protections

Both the app and this site send a Content Security Policy, and:

• X-Frame-Options: DENY and a frame-ancestors policy, so Obiter cannot be embedded in someone else's page to trick you into clicking things.
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin, so the pages you visit inside Obiter are not leaked to third parties in referrer headers.
• A Permissions Policy that switches off camera, microphone and geolocation outright. Obiter does not use them, so nothing embedded in a page can ask for them either.

4. Access to your data

Access to production systems is limited to the people who need it to run the service, and administrative access to the Obiter admin tools requires a passkey — a hardware-backed credential, not a password that can be phished.

We do not read your notes, essays, files or messages. There is no support tool that lets us open your account and look around. If you report a problem with a specific document, we will ask you to describe it or share it rather than reaching in.

5. Abuse and rate limiting

Authentication, AI features and other expensive endpoints are rate limited. Repeated failed logins are throttled. We log security-relevant events — sign-ins, permission changes, administrative actions — and keep them for a limited period to investigate abuse. That logging is done on the basis of legitimate interests and the assessment behind it is written down in our internal records.

6. Backups and availability

The database is backed up by our hosting provider on their standard schedule, with point-in-time recovery. We do not currently run a full documented restore drill on a fixed calendar, and we would rather say that than imply a maturity we have not reached. Keeping your own copy of work you cannot afford to lose remains sensible advice for any online service, including this one.

7. Application errors

We use Sentry to capture application errors. Error reports can include the page you were on and technical details of what failed. We do not send the content of your notes, essays or messages to Sentry.

8. What we do not have

Stated plainly, so nobody has to guess:

• No ISO 27001 certification and no SOC 2 report. We are a small team and neither would presently be honest.
• No third-party penetration test yet. When one is done, this page will say who did it and when.
• No bug bounty programme. Reports are still welcome, and section 9 explains how we handle them.
• No two-factor authentication on ordinary student accounts yet. Admin access uses passkeys; extending that to everyone is on the roadmap and this page will change when it lands.

9. Reporting a vulnerability

Email security@obiter.site. Please include enough detail to reproduce the issue. Our machine-readable contact details are at /.well-known/security.txt.

What you can expect from us:

• An acknowledgement within 3 working days.
• An assessment and our intended fix within 10 working days.
• Credit in our release notes if you would like it, and no credit if you would not.

What we ask of you:

• Give us reasonable time to fix the issue before making it public.
• Do not access, modify or delete data belonging to anyone else. Use your own account to demonstrate the problem.
• Do not run denial-of-service tests, send spam, or use social engineering against our staff or users.

If you follow those, we will not pursue legal action over your research, and we will say so in writing if you ask. We cannot waive anyone else's rights, only our own.

10. If something goes wrong

If a personal data breach occurs and it is likely to risk your rights and freedoms, we will report it to the Information Commissioner's Office within 72 hours of becoming aware of it, and tell affected users without undue delay where the risk is high. We have a written procedure for this and a template for the notice, so the clock is not spent deciding what to say.