Skip to content
StudyBrave

Security

What can be seen, and by whom

This page exists because the material these protocols handle is unusually personal, and because an anonymous project asking for that material owes a plain accounting rather than a policy.

It is written to be checkable. Where a claim can be verified from your own browser, it says how.

Data
Held
Your email address, if you subscribedStored here, and passed to the sending provider with each issue. Nothing is stored beside it.
yes
What you write in a contributionStored, because it was sent to be read and — for proposals and corrections — published.
yes
Your nameNever asked for. Not stored.
no
Your API keyNever sent to this server. It stays in your browser.
no
Your Self Map, records, and calibration historyStored in your browser, not here.
no
Which protocols you readNot linked to you. No cookies, no visitor profiling.
no
Your IP addressSeen by the web server while a page loads. No access log is kept. The error log is the one exception — see below.
transit
What you type into an agentNever reaches this server. It goes to the model provider you chose.
no

The part most projects leave out

Encryption protects storage. It does not protect inference.

When you run a protocol, the text you have written has to reach a language model in readable form, because that is what the model needs in order to respond. Encrypting it at rest changes nothing about that moment. Any product that runs an agent over your data and also claims your data is unreadable is describing two things that cannot both be true.

What StudyBrave does instead is remove itself from that path. You bring your own API key. Your browser talks to the model provider directly. The conversation is between you and them, under their terms and their retention policy, and this server is not a party to it.

This does not mean nobody sees it. Your model provider does. Read their retention policy, because it is the one that governs your material — not this page.

The Studio

The in-browser runner is live. It is the part of this project where the architecture has to carry the claim, so here is exactly what it does.

  • Your API key stays in your browser. You paste it once; it is encrypted with a key derived from your passphrase and written to your browser's own storage. It is sent to Anthropic, by your browser, and to nowhere else.
  • Your conversation never reaches this server. The request goes from your machine directly to the model provider. There is no endpoint here that proxies it, because building one would have meant seeing it.
  • Your records are encrypted before they are stored. A random data key encrypts every artifact and transcript; your passphrase only wraps that key. Neither ever leaves the browser, so a forgotten passphrase cannot be reset — you are given a recovery key instead, once.
  • Deleting means deleting. “Delete the vault” drops the entire database. There is no copy on any server to also delete.

The agent definitions the Studio runs are the same files published on each protocol page and offered for download. There is no hidden system prompt.

What this server stores

Two things, both of which require you to type into a form: subscriber email addresses, and contributions people chose to send. Nothing is collected by watching you read, and nothing from the Studio is collected at all.

How to check

  • Open your browser's network inspector and use the site. You will see requests for pages and fonts, and — only if you subscribe — one request to /api/subscribe carrying your address and nothing else.
  • Run a protocol with the inspector open. This is the check that matters. Every request carrying your key or your answers goes to api.anthropic.com. Filter by studybrave.com and you will find nothing but the page itself. If you ever see otherwise, the claim on this page is false and we want to know.
  • Open the Application panel, find IndexedDB → studybrave, and look at a record. You will see a nonce and a block of ciphertext. The readable fields are the date and the protocol code; everything you wrote is inside the encrypted part.
  • Look for analytics. There are none. No Google Analytics, no tag manager, no pixel, no session recorder, no third-party script of any kind.
  • Look for cookies. As a reader you are never given one. The single exception is the sign-in session for the moderation panel at /panel, which only whoever runs the project can obtain and which is scoped to that path alone.
  • Fonts are served from this domain, not from Google. No request leaves for a third party while you read.

Contributions

The contribution form is the one place where the server stores something you wrote. That is a real change from “there is no database of you”, and it is stated here rather than glossed over.

  • Stored: what you typed, when, its status, and a random key returned to you. For an offer of work, also whatever contact string you chose to include.
  • Not stored: your name, your email, your IP, your browser, where you came from. The form asks for none of it and the table has no column for any of it.
  • The key is the whole account. There is no password and no recovery, because there is nothing to recover it against. Lose it and the submission continues without you.
  • Proposals and corrections become public once they clear triage — that is the point of an open queue. Offers of work never do, because they often carry contact details.
  • Withdrawing deletes the row. The exception is a submission already accepted into the library: by then its content is published under CC BY-SA 4.0, and claiming it could be recalled would be a lie.

Subscribing

  • Stored: your email address and the date you submitted it. Nothing else.
  • Not stored: your name, your IP, where you came from, what you clicked.
  • Not done: selling, sharing, or handing the list to an advertiser or data broker.
  • Unsubscribing deletes the row. It is not a flag on a record we keep; the record goes.
  • The issues are sent through Resend. Your address and the contents of each issue pass through them, and they keep delivery records — whether a message was accepted, bounced, or complained about. Your address is not uploaded to them as a stored list; it is sent with each issue and the list itself stays here. Their privacy terms govern what they retain, and they are worth reading if this matters to you.
  • Every issue carries a one-click unsubscribe your mail app can act on directly, plus a link. Both delete the row.
  • Rate limiting is the one place your address is touched. A salted hash of your IP is held in memory for ten minutes and never written to disk. The salt is random and regenerated whenever the server restarts, which makes the hashes useless for correlating anything across restarts — including by us.

What is not promised

Being honest about the good parts requires being honest about the rest.

  • No independent audit has been done. Everything above is a claim by the project about itself. It is structured so that most of it is checkable from your own browser, which is the best available substitute, and not the same thing.
  • The server is not exclusively ours. This site runs on shared infrastructure alongside unrelated services. It is isolated at the container level and reachable only through a reverse proxy, and that is a weaker guarantee than dedicated hardware.
  • Browser storage is not a vault. When the runner ships, your data will live on your machine. Anyone with access to your unlocked machine has access to it. Clearing your browser data destroys it, with no copy held anywhere else.
  • The error log is a real exception. The web server writes no access log for this site — the usual line-per-request file with your address in it does not exist here. It does keep an error log, and when a request fails at the server level that entry can contain the address that made it. This is kept because a site with no error log cannot be repaired. It records faults only, it is rotated, and it is never joined to anything else.
  • Requests pass through a network provider. Traffic to this domain is proxied, which means a third party terminates TLS in front of the origin. This is standard practice and it is still a party in the path, so it is named here rather than omitted.

Reporting a problem

If you find something on this page that is not true, that is the most valuable report you can make. Corrections are published rather than quietly fixed.