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.
• Exception: content rules. The gateway checks inputs and outputs against content rules. A request that triggers a rule leaves a short excerpt around the match and the account name, to deal with abuse; the full text is not stored.
• 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.

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.
• Content rules are not perfect: they can block by mistake and they can miss things.

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