Security and privacy

Where what you send goes

Your request reaches the Babel Mesh gateway, which picks a node according to the request's data class and forwards the request to it. The node computes the result with its model and returns it through the gateway.

The node that serves a request can read it. That is a fact of how this works today: a node has to read the prompt to answer it. So do not send passwords, ID numbers or trade secrets.
The node cannot see who you are. The request a node receives carries no account name and no key, only an anonymous tag.
Babel Mesh does not store conversations. The gateway's records hold the time of a request, the model, the outcome and the usage. Conversations stay in your own client or browser.
Babel Mesh does not review content. The gateway does not check, block or filter inputs or outputs against content rules, and it does not keep excerpts or account names because of what a request says. Responsibility for how content is used lies with the user; do not send unlawful content.
Spot checks replay requests. To verify what contributors return, a small share of public-class requests is computed again on the operator's own nodes and the two results are compared.

Data classes

Every account and every request has a data class. Accounts that sign up themselves start at "public". Contributors' nodes only receive "public" requests. Higher classes go to the operator's own nodes only. Images and video are also served only by the operator's nodes for now, because their results cannot be spot-checked the way text can.

Connections and keys

The website and the API use HTTPS. The components behind them (controller, gateway, ledger, relay, nodes) talk over encrypted connections with mutual certificate authentication; a node's identity is in its certificate.
Nodes only connect outward. They open no inbound port and serve through a relay.
The client keeps your API key on your computer, readable only by your system account. The client's page never receives the key; the client makes requests for you.
Client updates are checked against a signed manifest: the public key is built into the client, and a bad signature or a version that is not newer is never installed.

Accounting and verification

Receipts signed by both sides. For each request the gateway and the node sign the same receipt, and the ledger records it only when they agree. A receipt holds hashes of the request and the result and the usage, not the content.
Random checks. New nodes are checked more often, nodes with a long clean record less often. A node whose results do not match is quarantined; once the operator confirms cheating, its earnings are forfeited and penalised under the rules.
Earnings are held. A contributor's income waits a few days, during which the checks continue.

Hive: the server cannot see your task

Hive is a different path: the tasks and files you give it are encrypted in your browser, and the dispatcher and the store only get ciphertext. This is what it does today, including what it cannot do.

Encryption happens in the browser. Each task has its own master key; the task, its files and its result are sealed with it, and the master key is sealed separately to each machine allowed to run the task. The dispatcher, the store and the gateway see ciphertext, sizes, times and your account id, not the content.
The machine that runs a task can read it. It has to open the task to do the work, and that cannot be avoided. So machines are separated by data class: public tasks may go to any admitted machine; trusted tasks only to the platform's own machines, contracted institutions and machines that passed remote attestation; confidential tasks only to the platform's own machines and attested ones. Your own machines always come first, and only your own machines may take your tasks regardless of class.
Machines run in isolation. A task runs in a gVisor sandbox with no network by default and access only to its own working folder. A new machine must pass several checks before it receives real tasks, and a machine that fails a check is quarantined or banned.
One one-time model key per task. Machines never get your account key; a task uses a key made for it alone, with a spending limit. The server revokes it as soon as the task ends, whether or not your page is open.
How long things are kept. A task and its result (ciphertext) are kept on the server for 7 days and then deleted; the page shows the date. Cancelling clears it at once. Your task records and the keys to open them stay only in your browser: if you clear its data or switch browsers they cannot be opened, unless you turn on cross-device sync (encrypted with a passphrase only you know; if you forget it nobody can recover it).
My library is encrypted in the browser too. Files are split into chunks and encrypted with a key of their own before upload; the store holds ciphertext, on more than one machine, and the index is encrypted. A file you share with a task is read-only, time-limited and limited to its chunks.
You can check it. The core code is planned to be open source; releases can already be built reproducibly, and their hashes will be logged in a transparency log so you can confirm that the program you run is the one built from the source (this step has not started); the browser-side cryptography is one separate file, cross-checked against the server's implementation with shared test vectors.

What Hive cannot do: it cannot stop the machine that runs a task from seeing what it processes (the confidential class relies on hardware attestation, so far only the platform's own machines); it cannot protect against a compromised browser or a computer with a malicious extension; the server still knows metadata such as "an account submitted a task of this size at this time"; public tasks may be processed by machines run by strangers, so do not put private content in them; there has been no third-party security audit.

What it cannot do

There is no trusted execution environment (TEE) yet: it cannot guarantee that a node cannot see content, which is why requests have classes.
It has not been through a third-party security audit.
No availability promise: nodes can go away at any time, and a request is retried on another node, but success is not guaranteed.

This page describes what the system actually does today. Formal terms of service and a privacy policy are published separately by the operating entity.