Segurança e privacidade

Para onde vai o que você envia

Sua requisição chega ao gateway do Babel Mesh, que escolhe um nó conforme a classe de dados da requisição e a encaminha. O nó calcula o resultado com seu modelo e o devolve pelo gateway.

O nó que atende uma requisição pode lê-la. É assim que funciona hoje: um nó precisa ler o prompt para responder. Por isso, não envie senhas, números de documento ou segredos comerciais.
O nó não vê quem você é. A requisição que o nó recebe não traz nome de conta nem chave, apenas uma etiqueta anônima.
O Babel Mesh não guarda conversas. Os registros do gateway contêm o horário de uma requisição, o modelo, o resultado e o uso. As conversas ficam no seu próprio cliente ou navegador.
Exceção: regras de conteúdo. O gateway verifica entradas e saídas com regras de conteúdo. Uma requisição que aciona uma regra deixa um pequeno trecho ao redor da ocorrência e o nome da conta, para lidar com abusos; o texto completo não é guardado.
Verificações por amostragem repetem requisições. Para conferir o que os colaboradores devolvem, uma pequena parte das requisições de classe pública é calculada de novo nos nós do próprio operador e os dois resultados são comparados.

Classes de dados

Cada conta e cada requisição tem uma classe de dados. Contas que se cadastram sozinhas começam em "pública". Os nós de colaboradores só recebem requisições "públicas". Classes mais altas vão apenas para os nós do próprio operador. Imagens e vídeo, por ora, também são atendidos só pelos nós do operador, porque seus resultados não podem ser verificados por amostragem como o texto.

Conexões e chaves

O site e a API usam HTTPS. Os componentes por trás (controlador, gateway, livro-razão, relay, nós) se comunicam por conexões criptografadas com autenticação mútua de certificados; a identidade de um nó está no certificado dele.
Os nós só se conectam para fora. Não abrem porta de entrada e atendem por um relay.
O cliente guarda sua chave de API no seu computador, legível apenas pela sua conta do sistema. A página do cliente nunca recebe a chave; o cliente faz as requisições por você.
As atualizações do cliente são conferidas com um manifesto assinado: a chave pública está embutida no cliente, e uma assinatura inválida ou uma versão que não seja mais nova nunca é instalada.

Contabilidade e verificação

Recibos assinados pelas duas partes. Para cada requisição, o gateway e o nó assinam o mesmo recibo, e o livro-razão só o registra quando os dois concordam. Um recibo contém hashes da requisição e do resultado e o uso, não o conteúdo.
Verificações aleatórias. Nós novos são verificados com mais frequência, nós com longo histórico limpo, com menos. Um nó cujos resultados não batem é colocado em quarentena; quando o operador confirma a fraude, os ganhos são perdidos e penalizados conforme as regras.
Os ganhos ficam retidos. A renda de um colaborador espera alguns dias, durante os quais as verificações continuam.

O que ele não pode fazer

Ainda não há ambiente de execução confiável (TEE): não é possível garantir que um nó não veja o conteúdo, e é por isso que as requisições têm classes.
Não passou por uma auditoria de segurança de terceiros.
Sem promessa de disponibilidade: os nós podem sair a qualquer momento e uma requisição é tentada de novo em outro nó, mas o sucesso não é garantido.
As regras de conteúdo não são perfeitas: podem bloquear por engano e podem deixar passar coisas.

Esta página descreve o que o sistema realmente faz hoje. Termos de serviço e política de privacidade formais são publicados separadamente pela entidade operadora.