Seguridad y privacidad

Adónde va lo que envías

Tu petición llega a la pasarela de Babel Mesh, que elige un nodo según la clase de datos de la petición y se la reenvía. El nodo calcula el resultado con su modelo y lo devuelve a través de la pasarela.

El nodo que atiende una petición puede leerla. Así funciona hoy: un nodo tiene que leer el prompt para responder. Por eso no envíes contraseñas, números de documento ni secretos comerciales.
El nodo no puede ver quién eres. La petición que recibe un nodo no lleva nombre de cuenta ni clave, solo una etiqueta anónima.
Babel Mesh no guarda las conversaciones. Los registros de la pasarela contienen la hora de la petición, el modelo, el resultado y el uso. Las conversaciones se quedan en tu propio cliente o navegador.
Excepción: las reglas de contenido. La pasarela comprueba las entradas y salidas con reglas de contenido. Una petición que activa una regla deja un breve fragmento alrededor de la coincidencia y el nombre de la cuenta, para combatir el abuso; el texto completo no se guarda.
Las comprobaciones puntuales repiten peticiones. Para verificar lo que devuelven los colaboradores, una pequeña parte de las peticiones de clase pública se vuelve a calcular en los nodos propios del operador y se comparan los dos resultados.

Clases de datos

Cada cuenta y cada petición tiene una clase de datos. Las cuentas que se registran por sí mismas empiezan en "pública". Los nodos de los colaboradores solo reciben peticiones "públicas". Las clases superiores van solo a los nodos propios del operador. Por ahora, las imágenes y el vídeo también los sirven solo los nodos del operador, porque sus resultados no se pueden comprobar por muestreo como el texto.

Conexiones y claves

El sitio web y la API usan HTTPS. Los componentes que hay detrás (controlador, pasarela, libro mayor, relé, nodos) se comunican por conexiones cifradas con autenticación mutua de certificados; la identidad de un nodo está en su certificado.
Los nodos solo se conectan hacia fuera. No abren ningún puerto de entrada y sirven a través de un relé.
El cliente guarda tu clave de API en tu equipo, legible solo por tu cuenta del sistema. La página del cliente nunca recibe la clave; el cliente hace las peticiones por ti.
Las actualizaciones del cliente se comprueban con un manifiesto firmado: la clave pública está integrada en el cliente, y nunca se instala una firma incorrecta ni una versión que no sea más reciente.

Contabilidad y verificación

Recibos firmados por ambas partes. Por cada petición, la pasarela y el nodo firman el mismo recibo, y el libro mayor lo registra solo cuando coinciden. Un recibo contiene hashes de la petición y del resultado y el uso, no el contenido.
Comprobaciones aleatorias. A los nodos nuevos se les comprueba más a menudo; a los que tienen un historial limpio largo, menos. Un nodo cuyos resultados no coinciden se pone en cuarentena; cuando el operador confirma el engaño, sus ingresos se pierden y se penalizan según las reglas.
Los ingresos se retienen. Lo que gana un colaborador espera unos días, y durante ese tiempo las comprobaciones continúan.

Lo que no puede hacer

Todavía no hay un entorno de ejecución de confianza (TEE): no puede garantizar que un nodo no vea el contenido, y por eso las peticiones tienen clases.
No ha pasado por una auditoría de seguridad de terceros.
Sin promesa de disponibilidad: los nodos pueden desaparecer en cualquier momento y una petición se reintenta en otro nodo, pero el éxito no está garantizado.
Las reglas de contenido no son perfectas: pueden bloquear por error y pueden pasar por alto cosas.

Esta página describe lo que el sistema hace realmente hoy. Las condiciones de servicio y la política de privacidad formales las publica por separado la entidad operadora.