# El agujero sostiene el edificio **Deck:** Hace seis días California empezó a entregar a cada intermediario de datos registrado la lista de las personas que pidieron ser borradas. Los identificadores están hasheados, sin sal, y un portátil vuelve a convertir uno de ellos en un número de teléfono en unos cuarenta y tres segundos. Durante la elaboración del reglamento, varios criptógrafos ofrecieron a la agencia una solución. Dijo no, por escrito, porque la solución impediría que los intermediarios te suprimieran para siempre. **By:** Redacción de URnetwork **Dateline:** San Francisco — 7 de agosto de 2026 **Category:** Noticias / Análisis --- ## Una lista de quienes pidieron desaparecer Las personas que figuran en la lista pidieron desaparecer: supervivientes de acoso (*stalking*) y de violencia doméstica, jueces, pacientes de servicios de salud reproductiva, cualquiera con un motivo para borrar su rastro. Desde enero vienen presentando su solicitud al amparo de la Delete Act de California, la ley estatal de borrado, un único sitio donde ordenar a todos los intermediarios de datos del estado —las empresas que compran y venden información personal de gente con la que nunca han tratado— que las eliminen. Hace seis días se encendió la otra mitad: desde el **1 de agosto de 2026**, el §1798.99.86(c)(1) del Código Civil obliga a cada intermediario registrado a *"access the accessible deletion mechanism … at least once every 45 days."* («acceder al mecanismo de borrado accesible … al menos una vez cada 45 días»). La lista se mueve ahora hacia fuera, hacia los sistemas de cientos de intermediarios —exactamente la industria de la que estas personas se escondían— y el primer ciclo obligatorio se cierra alrededor del **15 de septiembre**. Los identificadores están hasheados —pasados por una función que los convierte en una huella de longitud fija, en teoría irreversible—, lo que suena a protección. En un solo núcleo de un portátil, un número de teléfono de California que esté en la lista vuelve a ser un número de teléfono en unos **cuarenta y tres segundos**. La agencia que construyó la máquina, el regulador estatal de privacidad (la California Privacy Protection Agency, CPPA), sí avisó a los intermediarios de que esto llegaba: una entrada de su blog del 10 de julio dice que *"starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records."* («desde el 1 de agosto, los intermediarios de datos deben descargar las solicitudes de borrado hasheadas y compararlas con la información personal que consta en sus registros»). Lo que no ha hecho es decir nada sobre la exposición. Su sala de prensa, vuelta a consultar el 7 de agosto, sigue encabezada por una entrada del 4 de agosto sobre Vermont; la puesta en marcha del 1 de agosto tuvo una guía práctica para los intermediarios y ningún aviso en absoluto para las personas que están en la lista. ## El hash se deshace en segundos La lista lleva seis tipos de identificador, y solo uno de ellos aparece nombrado en el reglamento: **MAID**, un identificador publicitario móvil. Los otros cinco son etiquetas de la especificación técnica del DROP: **NDZ** (nombre, apellido, fecha de nacimiento y código postal), **Email** (correo electrónico), **Phone** (teléfono), **NameVIN** (nombre más el número de identificación del vehículo) y **CTVID**, un identificador de televisión conectada. Antes de hashear nada, la norma aplana la entrada —todo a minúsculas, puntuación eliminada, acentos deshechos—, de modo que su propio ejemplo convierte *"Björn O'Connor-López"* en *"bjornoconnorlopez"*. Las fechas pasan a ser ocho dígitos; un teléfono, sus últimas diez cifras; y una cláusula de cierre ordena al intermediario *"implement any other standardization that the data broker knows will increase the likelihood of a match."* («aplicar cualquier otra normalización que sepa que aumentará la probabilidad de una coincidencia»). Cada paso descarta entropía, y la entropía es lo único que separa un hash del valor a partir del cual se calculó. Recomputamos los dos ejemplos resueltos de la propia especificación técnica del estado. Todos los resúmenes de campo y los dos resúmenes compuestos salen idénticos, bit a bit, como un simple SHA-256 sobre UTF-8 codificado en Base64: sin sal —el valor aleatorio que se añade antes de hashear—, sin clave, nada que el registro público no contenga ya. Un hash sin clave de un valor de baja entropía no es un disfraz; es un acertijo que un portátil resuelve probando todas las respuestas, y SHA-256 responde unos **7,1 millones de intentos por segundo en un solo núcleo de CPU**, sin tarjeta gráfica de por medio. | Qué hay en la lista | Cuántas posibilidades | Tiempo en un núcleo de portátil | |---|---|---| | Un número de teléfono de California | 304.000.000 | **~43 segundos** | | Cualquier número de EE. UU. o Canadá | 6.400.000.000 | ~15 minutos | | Nombre, fecha de nacimiento y código postal, cotejados con el registro de votantes de CA | ~22.000.000 | **~3 segundos** | | Un identificador corto de televisión conectada | 2,8 × 10¹² | ~4,6 días | | Un identificador publicitario móvil | 2¹²⁸ | inviable | La lista de teléfonos no es seudónima. Es texto en claro con un paso más. La lista de nombre, fecha de nacimiento y código postal no exige adivinar nada: hasheas a la única persona que buscas y preguntas si la respuesta está en la lista —un oráculo de sí o no—, y el hash vuelve a ser un nombre. Incluso el identificador publicitario, que de verdad no se puede romper, no necesita que nadie lo rompa: es una clave de cruce que una empresa de publicidad digital ejecuta contra sus propios dispositivos para saber cuáles de ellos pertenecen a alguien que intenta borrarse. La primera idea obvia —basta con salar los hashes— no puede funcionar aquí. Salar protege las contraseñas almacenadas porque quien comprueba ya tiene el secreto que el usuario acaba de teclear. DROP, la plataforma estatal de solicitudes de borrado (Delete Request and Opt-out Platform), tiene la forma contraria: el intermediario compara *sus propios* registros, que California nunca ha visto, con la lista del estado, así que ambas partes deben llegar al mismo resumen de forma independiente; y una sal compartida con todos los intermediarios registrados del país no es un secreto. ## A California le ofrecieron la solución y la rechazó por escrito Esta es la parte que nadie ha contado. Durante la elaboración del reglamento, varios criptógrafos avisaron a la agencia de que esto pasaría. En el apéndice A de la Final Statement of Reasons —la declaración final de motivos, el documento donde la agencia responde a los comentarios públicos—, quienes comentaron propusieron la **intersección privada de conjuntos** (*private set intersection*), un protocolo que permite a dos partes conocer solo lo que tienen en común y nada más, o bien el cotejo dentro de un **entorno de ejecución confiable** (*trusted execution environment*), una zona del procesador aislada del resto del sistema. Fueron honestos sobre el coste: admitieron que impediría que «los intermediarios de datos supriman identificadores en el futuro», y sostuvieron que el intercambio valía la pena. La agencia dijo no, y su motivo es toda la historia: > «La Agencia toma nota de las alternativas al hasheo sugeridas por quien comenta, pero la Agencia ha > determinado que el hasheo es un método de protección de datos ampliamente utilizado, seguro y accesible, y > que **cualquier método que impida la supresión continuada de identificadores por parte de los intermediarios > de datos no aplica adecuadamente la ley**.» Lee despacio la segunda mitad. La Delete Act no le pide al intermediario que te olvide una vez; le exige que siga suprimiéndote —manteniéndote fuera de sus registros— de ahora en adelante. Para suprimirte para siempre, un intermediario tiene que conservar algo duradero que signifique *tú*, y un hash es exactamente eso: una ficha duradera y recalculable. Todos los esquemas que ofrecieron los criptógrafos funcionan *no* dejándole al intermediario esa ficha, y por eso la agencia los descartó. El agujero de privacidad no es un defecto que el diseño no logró cerrar. Es el mecanismo que el diseño se construyó para ofrecer. Y el §7620(c) cierra el círculo: *"By submitting a deletion request, a consumer consents to disclosure of their personal information to a data broker for purposes of processing their deletion request."* («Al presentar una solicitud de borrado, el consumidor consiente la divulgación de su información personal a un intermediario de datos a efectos de tramitar su solicitud de borrado»). Esa limitación de finalidad es real, y es la mejor respuesta que tiene este diseño: el consentimiento no es ilimitado. Pero rige lo que un intermediario puede *hacer* con la divulgación, no lo que la divulgación *es*. Pedirle a California que te conceda el olvido sigue significando que te incluyan en una lista que los intermediarios descargan. ## El argumento de la agencia es más sólido de lo que admiten sus críticos Nada de esto convierte a la agencia en descuidada. Rechazó el cifrado sin más porque dejaría a los intermediarios en posesión de las claves de descifrado, claramente peor. Endureció la regla de cotejo hasta exigir una **coincidencia del 100 %**, una salvaguarda real contra borrar a las personas equivocadas. Las listas están **segmentadas**, así que un intermediario que solo maneja correos electrónicos nunca recibe la lista de nombres y fechas de nacimiento; las descargas son **incrementales** después de la primera; y el acceso cuesta un registro anual de **6.000 dólares** con una cuenta nominal. Enviar nombres y números en texto claro a cientos de empresas sería peor que todo esto. Y el punto más difícil no es culpa de la agencia en absoluto. El §1798.99.86(b)(3) —un mandato que escribió el legislador, no la agencia— ordena un mecanismo que permita al intermediario determinar si presentaste una solicitud y que *"shall not allow the disclosure of any additional personal information … unless otherwise specified in this title."* («no permitirá la divulgación de ninguna información personal adicional … salvo que en este título se especifique otra cosa»). Deja a un lado la salvedad final y lo que queda es un problema de intersección privada de conjuntos, entregado a una agencia estatal y financiado como una descarga en CSV. Las defensas aguantan peor de lo que parecen, sin embargo. La entrega incremental no sirve de nada una vez que la primera descarga es el corpus entero y cada intermediario guarda una copia; la segmentación confía en que los intermediarios declaren con honestidad qué identificadores manejan; y las protecciones del §7616 son legales, no técnicas: nada impide que un intermediario *calcule* lo que quiera a partir de la lista, la norma solo prohíbe *usar* el resultado. ## Una sola cláusula podría cerrarlo antes de que acabe el primer ciclo Hay una palanca, y tirar de ella no requiere legislatura. El §7601(c) permite que la lista de borrado nombre su propio algoritmo de hasheo; la agencia bendijo SHA-256 en una respuesta a comentarios, pero se negó a escribirlo en la norma. Puede especificar Argon2id en su lugar, por vía reglamentaria, y el ataque de cuarenta y tres segundos se vuelve inviable de la noche a la mañana: la misma lista, otra función, ninguna ley de por medio. Debajo de esto hay dos límites honestos. Estamos informando sobre el reglamento y la especificación, no sobre el sistema en funcionamiento: el reglamento permite cualquier algoritmo y la API real para intermediarios está detrás de un inicio de sesión, así que no podemos confirmar qué emite hoy el DROP desplegado. Y el muy repetido «300.000+» es el propio recuento de la agencia del 2 de junio: personas, no solicitudes, y sin actualizar desde entonces. Lo que sí podemos confirmar es el diseño, y el diseño es lo que importa. ## Una máquina construida para recordarte para siempre Quita todo lo demás y queda una contradicción. Un sistema que tiene que reconocerte para siempre para poder seguir protegiéndote debe conservar algo que signifique tú, y cualquier cosa que signifique tú puede volver a convertirse en ti. La única salida es no ser identificable para la máquina en absoluto. Eso no es un detalle técnico; es una decisión sobre quién hace el trabajo: los intermediarios o las personas que intentan desaparecer de ellos. California la tomó durante la elaboración del reglamento, con la alternativa que funcionaba delante, y eligió a los intermediarios. --- ## Referencias - **Cal. Civ. Code § 1798.99.86** — `leginfo.legislature.ca.gov` — (b)(3), el mandato que crea un oráculo de pertenencia; (c)(1), *"Beginning August 1, 2026, a data broker shall access the accessible deletion mechanism … at least once every 45 days."* («Desde el 1 de agosto de 2026, un intermediario de datos accederá al mecanismo de borrado accesible … al menos una vez cada 45 días»). Ley: §1798.99.80 et seq. (SB 362); habilitación §1798.99.87. Consultado el 7 de agosto de 2026. - **11 CCR §§7601–7622**, "Data Broker Registration and Accessible Deletion Mechanism" («Registro de intermediarios de datos y mecanismo de borrado accesible»), en vigor desde el 1 de enero de 2026 — `cppa.ca.gov/regulations/pdf/data_broker_drop_reg.pdf`, 16 pp. §7601(c) (el algoritmo viaja con la lista); §7612(c) (descargas incrementales); §7613(a)(1)(A) (normalización, incluido el ejemplo *Björn O'Connor-López → bjornoconnorlopez*) y (a)(1)(A)(vi); §7613(a)(2)(A) (hashear cada campo, concatenar los resúmenes "without adding spaces or other characters" —«sin añadir espacios ni otros caracteres»— y hashear de nuevo); §7616 (límites de uso); §7620(b)–(c) (MAID; consentimiento para la divulgación). **Correcciones del 10 de agosto**, las tres planteadas por traductores que cotejaron las citas con la fuente. (1) El cuerpo del artículo atribuía los seis tipos de identificador al §7613; solo `MAID` aparece nombrado en el reglamento, y los otros cinco son etiquetas de la especificación técnica, como ya recogía más abajo la entrada «Especificación técnica del DROP». (2) El §7620(c) se citaba terminando en "to a data broker" («a un intermediario de datos») y se omitía "for purposes of processing their deletion request." («a efectos de tramitar su solicitud de borrado»). La limitación de finalidad es la respuesta más fuerte a la lectura que se construía sobre esa cita, así que ahora se cita y se responde en lugar de recortarla. (3) El §1798.99.86(b)(3) se daba como "no additional personal information" («ninguna información personal adicional») y se calificaba de cita «palabra por palabra»; la ley dice "shall not allow the disclosure of any additional personal information … unless otherwise specified in this title" («no permitirá la divulgación de ninguna información personal adicional … salvo que en este título se especifique otra cosa»), y ahora se muestra la salvedad. La corrección (3) se aplicó también a las hot takes, en el párrafo de la rama legal y en la entradilla. - **Final Statement of Reasons, apéndice A** (declaración final de motivos), 53 pp. — `cppa.ca.gov/regulations/pdf/drop_fsor_45day.pdf`. Comentarios 117–122, que proponen la intersección privada de conjuntos y un entorno de ejecución confiable, y la respuesta de la Agencia citada íntegra más arriba; el comentario 196 y el intercambio sobre SHA-256 en §7613(a)(1)(B); los comentarios 73–75 (cifrado rechazado porque los intermediarios tendrían las claves); la respuesta al comentario 216 (listas segmentadas); el comentario de la FTC (la Comisión Federal de Comercio de EE. UU.) y la respuesta de la Agencia de que "will also monitor the DROP" («también supervisará el DROP»). También `cppa.ca.gov/regulations/pdf/drop_fosr.pdf` y `cppa.ca.gov/regulations/drop.html`. - **Especificación técnica del DROP** — `privacy.ca.gov/drop-for-data-brokers/technical-specifications/working-with-data/`, v1.2.0, "Last updated July 2026" («última actualización: julio de 2026»), consultada el 7 de agosto de 2026. Reglas de hasheo ("SHA-256 using UTF-8 input encoding" —«SHA-256 con codificación de entrada UTF-8»—, "Output as Base64" —«salida en Base64»—), los seis tipos de lista y los dos ejemplos resueltos que esta redacción recomputó. - **Reproducción y mediciones, esta redacción, 7 de agosto de 2026.** Los ejemplos resueltos de la especificación, recomputados con `hashlib.sha256` y Base64: coinciden 7 de 7 resúmenes de campo y 2 de 2 resúmenes compuestos. Rendimiento medido localmente con `openssl speed sha256` (113.894,45 kB/s en bloques de 16 bytes ≈ 7,1 millones de hashes/s en un núcleo) y con un bucle de `hashlib` en Python (3.413.611 h/s). Espacios de búsqueda calculados a partir de los propios formatos del reglamento: teléfono, 6,4 × 10⁹ para el NANP completo (el plan de numeración de Norteamérica) y 3,04 × 10⁸ para los prefijos de California; CTVID, 36⁸ con el mínimo de 8 caracteres; MAID, 32 dígitos hexadecimales. `grep -ci 'salt\|pepper'` = 0 sobre el reglamento y la FSOR. - **Sala de prensa de CalPrivacy** — `privacy.ca.gov/about-us/newsroom/`, vuelta a consultar el 7 de agosto de 2026 y de nuevo el 10 de agosto: última entrada del 4 de agosto de 2026 (Vermont se suma al consorcio de reguladores), anterior del 21 de julio ("California Privacy Protection Agency Launches First Sectoral Audit, Targets Gig Economy Platforms", confirmada el 10 de agosto en el `privacy.ca.gov/sitemap.xml` renderizado en el servidor, ya que el índice de la propia sala de prensa se genera con JavaScript); **ninguna entrada de la sala de prensa sobre la obligación de los intermediarios del 1 de agosto**. **Corrección del 10 de agosto:** esta edición dijo en un primer momento que la agencia «no ha dicho nada sobre la puesta en marcha». Sí lo había hecho, en su *blog*, no en su sala de prensa: `privacy.ca.gov/2026/07/drop-data-broker-deletions-how-do-they-work/`, 10 de julio de 2026, dice a los intermediarios "starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records." («desde el 1 de agosto, los intermediarios de datos deben descargar las solicitudes de borrado hasheadas y compararlas con la información personal que consta en sus registros»). El cuerpo del artículo dice ahora lo que es cierto, que es más limitado y peor: la agencia informó a los intermediarios y nunca avisó a las personas que están en la lista. La cifra «300.000+» procede del comunicado del 2 de junio de 2026 "Privacy Momentum Builds: 300,000+ Californians Sign Up for DROP as Registered Data Brokers Hit a Record High", recuperado íntegro (HTTP 200); registra además 581 intermediarios de datos registrados. - **No establecido, informado como lagunas:** qué algoritmo emite el DROP desplegado (la documentación de la API para intermediarios de datos en `databroker.drop.privacy.ca.gov` exige inicio de sesión; existe un entorno de pruebas, pero su documentación no era accesible); cualquier recuento de *solicitudes* de borrado publicado por la CPPA; y cualquier cifra posterior al 2 de junio.