Security overview

Last updated 1 September 2026.

This page describes what is actually deployed, not what we intend to build. Where a control is missing, it is listed as missing — an institution's security review will find out either way, and finding out from us is better.

Access and authentication

  • Passwords hashed with bcrypt and a per-password salt; login timing is equalised so a wrong email and a wrong password are indistinguishable
  • Sessions held in httpOnly, Secure, SameSite=Lax cookies — never in local storage, so a script cannot read them
  • Server-side session revocation, so signing out everywhere takes effect immediately
  • Role-based access: platform roles plus per-study roles (viewer, data viewer, editor, admin). Raw participant data needs data-viewer or above
  • Optional Google sign-in

Protecting data

  • TLS 1.2/1.3 only, HTTP Strict Transport Security for one year including subdomains, and all plain HTTP redirected
  • Encryption at rest for the database and object storage, provided by AWS and MongoDB Atlas
  • Object storage is private with public access blocked; files are reached through short-lived signed URLs
  • IP addresses are never written to the database — they exist only in memory for rate limiting

Isolating untrusted code

  • Experiments run inside a sandboxed iframe on a separate origin, with no access to the parent page or its cookies
  • The analysis engine runs the researcher's Python in the browser under a script-only sandbox with a restrictive content security policy, so generated code cannot call our API or reach the network
  • Uploaded JavaScript and CSS libraries are scanned for known malicious patterns
  • Exported CSV values and headers are neutralised against spreadsheet formula injection

Abuse and integrity

  • Redis-backed rate limiting on every endpoint, which fails closed rather than open
  • Cross-site request forgery protection by SameSite cookies plus an explicit origin allowlist on every state-changing request
  • Append-only audit log covering roughly 60 action types, including every data export, deletion, publish and code change. Admin impersonation is attributed to the admin, never the person impersonated
  • Production refuses to start with default or weak secrets, or with insecure cookie settings

Research-specific safeguards

  • Version pinning: a participant's session captures the exact published code, so mid-study edits never change what a running participant sees
  • Per-participant consent records store the exact wording agreed to, so later edits to a consent form cannot rewrite history
  • Per-study retention windows that automatically delete finished runs, their responses and recordings
  • Generated exports are deleted after 7 days

Where your data can be hosted

Institutions differ on what their policy allows, so there are three options. The second and third are set up per agreement rather than running by default — ask us and we will scope it.

Standard hosting

Our managed service. Application servers, file storage and email are hosted in India. Transfers from the EEA or UK are covered by Standard Contractual Clauses and a transfer impact assessment.

Hosting in the EEA or the United States

We are open to running a dedicated instance in either region for institutions whose policy requires participant data to stay there. Storage, database, email and AI inference would all be pinned to that region. Set up as part of an institutional agreement — tell us what your policy requires and we will scope the timeline with you.

Self-hosted

For institutions that need the platform to run entirely on their own infrastructure, using their own object storage, mail relay and AI provider credentials, so that no participant data reaches us at all. Offered under an institutional licence.

Not yet in place

  • Multi-factor authentication for researcher accounts
  • Independent penetration test, with a summary report available to institutions
  • SOC 2 Type II and ISO 27001 — not currently held

Reporting a vulnerability

Email [email protected] with enough detail to reproduce the issue. We will acknowledge within three working days. Please give us a reasonable window to fix it before publishing, and do not access, modify or delete data belonging to anyone else while investigating — testing against your own account is always fine.

If something goes wrong

If a breach affects personal data we hold for a researcher, we will notify them without undue delay so they can meet their own 72-hour notification duty as controller, and we will give them the detail their regulator expects. Where we are the controller — account, wallet and billing data — we notify affected people and the relevant authority ourselves.

For institutional reviews

We complete HECVATs and institutional security questionnaires on request, and our data processing agreement with Standard Contractual Clauses is ready to countersign. A transfer impact assessment is available on request. An accessibility conformance report and a penetration test summary are arranged per institution, so tell us early if your review needs them. Email [email protected].