Qué puede ver el proveedor

La privacidad no es una casilla que una aplicación cumple o incumple: es una propiedad de una arquitectura frente a un adversario concreto, y sin nombrar al adversario la palabra no significa nada. La afirmación más repetida del sector —los datos están cifrados— es casi siempre cierta y casi siempre irrelevante, porque contesta a una pregunta que el usuario no estaba haciendo. Lo que el usuario quiere saber es si el proveedor puede leer su contenido, y la respuesta a eso no depende de que haya cifrado sino de quién custodia las claves y en qué momento existe el texto en claro. Esta lección ordena las arquitecturas posibles en un espectro según lo que cada una deja ver, explica por qué el cifrado en reposo protege contra un conjunto de amenazas mucho más estrecho del que se le atribuye, y examina lo que sigue filtrándose cuando el contenido ya está fuera del alcance de todos: los metadatos, que muchas veces dicen más que el contenido.

El modelo de amenaza que casi nadie escribe

La palabra privado funciona en el discurso comercial como funciona seguro: enuncia una cualidad sin decir respecto a quién, y esa omisión no es un descuido de redacción sino lo que hace útil la afirmación, porque permite que cada lector la complete con el adversario que a él le preocupa. Deshacer esa ambigüedad es el primer trabajo intelectual de la lección.

Antes de decir que algo es privado hay que responder tres preguntas: quién es el adversario, qué capacidades tiene y qué se pierde si triunfa. Sin las tres, la afirmación es decorativa. Los adversarios plausibles de un servicio de datos no son intercambiables: un ladrón que se lleva un disco de un centro de datos, un atacante externo que compromete un servidor de aplicación, un empleado con acceso legítimo que consulta lo que no debe, la propia empresa actuando dentro de sus condiciones, un comprador futuro que hereda los datos con otras intenciones y una autoridad que presenta un requerimiento legal. Cada uno tiene capacidades distintas y cada mecanismo defensivo cubre solo a algunos.

Merece la pena escribirlos con sus capacidades, porque solo así se ve qué defiende cada mecanismo:

1. Ladrón de hardware. Acceso físico a un disco fuera de servicio o a una máquina apagada. Sin credenciales de aplicación.
2. Atacante externo. Compromete un servidor en ejecución y hereda todos los privilegios que ese servidor tiene, incluidas sus claves.
3. Personal interno. Acceso legítimo a la capa de aplicación, limitado solo por controles internos y por la calidad de la auditoría.
4. El propio proveedor. Actúa dentro de sus condiciones, que él mismo redacta y puede modificar con preaviso.
5. Sucesor. Quien adquiere la empresa o sus activos en una quiebra, y hereda los datos sin heredar necesariamente las intenciones.
6. Autoridad con requerimiento legal. Obtiene lo que el proveedor pueda entregar, y solo lo que pueda entregar.

El error de razonamiento más común es tratar la lista como si fuera homogénea y concluir que una medida que detiene al primero detiene a todos. No es así, y la asimetría es sistemática: las medidas fáciles de implementar y de comunicar son justamente las que protegen contra los adversarios menos probables, mientras que los adversarios con acceso legítimo —la empresa, el empleado, el requerimiento— solo se detienen con medidas que cuestan funcionalidad.

El quinto adversario, el sucesor, merece una mención aparte porque es el que peor encaja en el razonamiento habitual. Un usuario evalúa a un proveedor por su conducta actual y por la reputación de su equipo, y ambas cosas son legítimas y a menudo tranquilizadoras. Pero los datos sobreviven a los equipos: sobreviven a la venta de la empresa, al cambio de propiedad, a la reorientación del modelo de negocio y a la liquidación de activos en un concurso. Confiar en un proveedor es, en rigor, confiar en toda la cadena de futuros titulares de esa base de datos, y esa cadena es desconocida por construcción. Cualquier evaluación de privacidad que se apoye en las intenciones presentes está midiendo la variable equivocada.

Cifrado en reposo: qué protege exactamente

El cifrado en reposo significa que los bloques del disco o del sistema de almacenamiento están cifrados con claves que gestiona el proveedor. Protege, y no es poco, contra un conjunto de escenarios reales: el robo físico de una unidad, un disco retirado que se revende sin borrar, una copia de seguridad abandonada en un depósito mal configurado, la incautación del hardware apagado.

Cruzado con la lista de adversarios, cubre exactamente al primero de los seis y a ninguno de los otros cinco:

• No protege contra el proveedor, porque el proveedor tiene la clave y la usa en cada petición.
• No protege contra un servidor comprometido, porque ese servidor descifra por definición y el atacante hereda esa capacidad.
• No protege contra el personal interno, porque el acceso ocurre en la capa de aplicación, por encima del cifrado.
• No protege frente a un sucesor, porque lo que se transfiere en una adquisición son los datos y las claves juntos.
• No protege contra un requerimiento legal, porque quien puede descifrar puede entregar el texto en claro.

La razón es una sola y es estructural: para servirte una vista, el contenido tiene que existir en claro en la memoria de una máquina ajena. El cifrado en reposo protege los datos cuando están quietos y el sistema apagado; la vida útil de un servicio transcurre casi entera con el sistema encendido.

La pregunta correcta, entonces, no es si hay cifrado sino quién puede computar sobre el texto en claro. La custodia de la clave es toda la cuestión, y todo lo demás es implementación.

Vale la pena reconocer, para no caer en el desprecio fácil, que el cifrado en reposo sí resolvió un problema que era grave y frecuente. Antes de que se generalizara, la retirada de hardware, el extravío de cintas de respaldo y los depósitos de almacenamiento mal configurados produjeron filtraciones masivas de forma rutinaria. Que hoy esa clase entera de incidentes sea rara es un logro real de higiene operativa. El reproche no es que la medida sea inútil: es que se comunica como si respondiera a una pregunta distinta de la que responde, y esa distancia entre lo que se dice y lo que se hace es la que produce decisiones mal informadas.

El espectro de lo que el proveedor observa

Las arquitecturas no se dividen en privadas y no privadas: forman un espectro en el que cada peldaño reduce lo que el proveedor puede computar y cobra un precio en funcionalidad. Recorrerlo entero es la única manera de situar honestamente una decisión, y también la única manera de detectar cuándo un producto se describe con el vocabulario de un peldaño mientras opera en otro.

flowchart TD
A[Texto en claro en el proveedor] --> B[Cifrado en reposo con claves del proveedor]
B --> C[Claves gestionadas por el cliente pero descifrado en el servicio]
C --> D[Computo en entorno de ejecucion confiable]
D --> E[Extremo a extremo con servidor ciego]
E --> F[Solo local sin servidor]
A --> A1[Ve todo y puede indexar buscar y analizar]
B --> B1[Ve todo en ejecucion protege discos parados]
C --> C1[Ve todo mientras sirve deja rastro de auditoria]
D --> D1[Confianza trasladada al fabricante del hardware]
E --> E1[No ve contenido si ve metadatos]
F --> F1[No ve nada y no puede ayudarte en nada]
style A1 fill:#f38ba8,color:#11111b
style B1 fill:#f38ba8,color:#11111b
style C1 fill:#f9e2af,color:#11111b
style D1 fill:#f9e2af,color:#11111b
style E1 fill:#a6e3a1,color:#11111b
style F1 fill:#89b4fa,color:#11111b

Cada peldaño compra una reducción de exposición y paga con funcionalidad, y la transacción conviene enunciarla explícitamente:

1. Texto en claro. Búsqueda instantánea, vistas previas, análisis, funciones de modelos de lenguaje. Exposición total y permanente.
2. Cifrado en reposo. Idéntica funcionalidad, coste operativo casi nulo. Solo cubre el escenario del hardware apagado.
3. Claves del cliente. Añade auditoría y un interruptor de corte inmediato. El texto en claro sigue pasando por el servicio.
4. Entorno de ejecución confiable. El operador no inspecciona el cómputo. La confianza se traslada al fabricante del procesador y a la atestación.
5. Extremo a extremo. El servidor no ve contenido. Desaparecen búsqueda en servidor, filtrado, deduplicación y soporte con visibilidad.
6. Solo local. No hay exposición y no hay servicio: ni sincronización, ni colaboración, ni recuperación tras perder el dispositivo.

Merece subrayarse el peldaño de las claves gestionadas por el cliente, porque es el que más confusión genera en contratos corporativos. Que la organización controle la clave maestra añade auditoría y la capacidad de cortar el acceso de golpe, lo cual tiene valor real; pero mientras el servicio necesite descifrar para funcionar, el texto en claro pasa por sus manos en cada operación. Es un control de gobernanza, no una barrera criptográfica. Los entornos de ejecución confiables prometen cerrar esa brecha ejecutando el cómputo en una región que el operador no puede inspeccionar, y son un avance genuino; pero trasladan la confianza al fabricante del procesador y a la corrección de una atestación, y su historial de vulnerabilidades por canales laterales aconseja tratarlos como mitigación fuerte y no como garantía.

Metadatos y el precio de la ceguera

Supón resuelto el problema del contenido: cifrado extremo a extremo, servidor ciego, claves solo en tus dispositivos. Queda una capa entera de información que el servidor sigue observando y que a menudo es más reveladora que el texto:

• Con quién. El grafo de sincronización revela la estructura completa de tus relaciones y colaboraciones.
• Cuándo. Los momentos de actividad revelan horarios, huso horario, vacaciones, insomnio y cambios de rutina.
• Cuánto. Los tamaños y el ritmo de crecimiento distinguen una nota de un manuscrito y un proyecto vivo de uno abandonado.
• Con qué frecuencia. La cadencia de las escrituras distingue el trabajo intensivo del mantenimiento ocasional.
• Desde dónde. Direcciones de red e identificadores de dispositivo revelan ubicación, desplazamientos y número de terminales.

La frase de Michael Hayden, exdirector de la Agencia de Seguridad Nacional estadounidense, sigue siendo la formulación más brutal de este punto: matamos gente basándonos en metadatos. Se puede discutir el contexto en que la dijo, pero la afirmación técnica que contiene es correcta y está bien establecida: sobre un conjunto suficientemente grande de personas, el patrón de comunicación permite inferencias que el contenido apenas mejora.

El caso local-first tiene además una fuga específica que conviene nombrar. La sincronización de un CRDT cifrado transmite operaciones, y el patrón de operaciones filtra estructura: número de ediciones, ráfagas de escritura, tamaño de cada delta, orden causal entre participantes. Un servidor que no puede leer una palabra puede reconstruir quién escribió, cuándo, cuánto y en compañía de quién. Ocultar eso exige relleno de mensajes, retrasos artificiales y mezcla de tráfico, y esas técnicas cuestan latencia y ancho de banda, exactamente los recursos que la arquitectura quería ahorrar.

Conviene también matizar en la otra dirección, porque hay una diferencia real a favor. Un servidor de sincronización que solo transporta operaciones cifradas acumula un registro mucho más pobre que un servicio que aloja el contenido: no puede reconstruir el texto, no puede buscar en él, no puede clasificarlo ni derivar de él un perfil temático, y no tiene nada que entregar si alguien se lo pide. Que la fuga de metadatos exista no la iguala con la exposición del contenido, y decir lo contrario sería el error simétrico al que critica esta lección.

Y una vez contabilizada la fuga, queda por contabilizar el coste, porque el argumento contrario es fuerte y hay que sostenerlo entero. El cifrado extremo a extremo elimina la búsqueda en servidor, la generación de vistas previas, el filtrado de correo no deseado, la deduplicación entre usuarios, la ayuda humana de soporte —nadie puede mirar tu documento para diagnosticar por qué se rompió— y cualquier función que requiera cómputo sobre el contenido, incluida la mayoría de las capacidades de modelos de lenguaje que hoy definen la competencia de producto. Elimina también la moderación, que la lección quinta trata en serio. Y añade un modo de fallo nuevo y absoluto: la pérdida de la clave es la pérdida irreversible de los datos, sin apelación y sin soporte.

La objeción más incómoda para el bando local-first no es ninguna de esas, sino esta: el dispositivo del usuario es, casi siempre, el eslabón peor protegido de toda la cadena. Un centro de datos tiene actualizaciones automáticas, detección de intrusiones, segmentación de red y personal dedicado; un portátil compartido con la familia, sin cifrado de disco activado y con el bloqueo de pantalla desactivado por comodidad, no tiene nada de eso. Mover los datos allí reduce la exposición ante el proveedor y la aumenta ante el robo físico, el software malicioso y la persona que se sienta a esa mesa. Es un intercambio, no una mejora unilateral, y presentarlo como mejora unilateral es exactamente el tipo de argumento que esta lección quiere evitar.

Frente a eso, el modelo de amenaza realista del usuario medio no es que su proveedor lea sus notas: es el robo de credenciales, la reutilización de contraseñas, el engaño por suplantación y la pérdida del dispositivo. Contra esos vectores, un proveedor centralizado con detección de accesos anómalos, verificación en dos pasos y un procedimiento de recuperación funciona mejor que una arquitectura soberana sin red de seguridad. Cada mecanismo de rescate que se añade —depósito de claves, recuperación social, sincronización de claves en la nube del fabricante— vuelve a abrir, en distinto grado, el agujero que el cifrado había cerrado. Esa circularidad no tiene una salida limpia, y quien la presente como resuelta está vendiendo algo.