Enrique Dans

Hay ideas que suenan aparentemente bien en un titular y que, cuando intentas bajarlas a una implementación real, se desmoronan completamente. La nueva oleada de «leyes de verificación de edad» están en esa categoría: una mezcla de pánico moral, presión política y fe ciega en que la tecnología puede imponer barreras limpias y perfectas entre «menores» y «adultos». El resultado, una vez más, es una exigencia técnica ambigua que no resuelve el problema que dice querer resolver… y que, de paso, castiga justo a quienes menos capacidad tienen de asumir el coste: comunidades abiertas, proyectos mantenidos por voluntarios y distribuciones Linux que, por diseño, no operan como una plataforma centralizada.

El caso más ilustrativo ahora mismo es California con su AB 1043, que entra en vigor el 1 de enero de 2027 y obliga a proveedores de sistemas operativos a pedir la edad (o la fecha de nacimiento) en la configuración de la cuenta y a exponer una «señal» de tramo de edad a las aplicaciones mediante una API. El propio texto de la ley deja claro el enfoque: categorizar a la persona usuaria en tramos (por ejemplo, «menor de 13», «de 13 a 15», «de 16 a 17», «Más de 18») y convertir esa señal en un elemento para desarrolladores y tiendas de aplicaciones. Que nadie se engañe: esto no es «verificar» la edad: es, en el mejor de los casos, pedirla. Y pedirla no impide mentir. Es exactamente el mismo teatro de seguridad que llevamos décadas viendo en la web, pero ahora trasladado al sistema operativo, y ahora con una supuesta amenaza de responsabilidad legal flotando sobre todo el ecosistema.

Lo interesante y preocupante es lo que esta presión regulatoria provoca en el tejido del software libre. En Ubuntu, por ejemplo, un desarrollador propone un estándar «mínimo» en forma de interfaz D-Bus, para que el sistema pueda almacenar y devolver el tramo de edad sin convertirlo en una pesadilla de privacidad, e incluso sugiere que se almacene solo el intervalo de edad y que sea el usuario quien tenga que actualizarlo cada vez que cambie de tramo. La reacción oficial de Canonical, sin embargo, es prudente y casi defensiva: reconocen que están revisando la legislación con su asesoría legal, pero que no hay plan concreto, ni siquiera decisión, sobre si Ubuntu cambiará algo, y remarcan que lo discutido es conversación informal, no anuncio. En Fedora el tono es parecido: el liderazgo del proyecto evita especular hasta hablar con apoyo legal, y la discusión comunitaria deriva rápidamente hacia «¿cómo diablos se interpreta esto en un sistema multiusuario, con live sessions, equipos compartidos, cuentas locales, etc.?»

Esto supone la primera gran fractura: estas leyes presuponen un modelo de «plataforma» con control central, con cuentas identificables y con la capacidad de imponer un flujo de registro uniforme. Linux, como ecosistema, es exactamente lo contrario: miles de combinaciones de instalación, despliegues sin cuenta, usuarios locales, máquinas compartidas, terminales, quioscos, laboratorios, live USB, imágenes para contenedores, entornos corporativos, entornos educativos… pretender que todo eso se pliegue a un mismo ritual de «dime tu edad y te doy una señal» es legislar sobre una caricatura del mundo real. Y cuando legislas sobre una caricatura, quienes ganan no son «los jóvenes», sino quien ya opera como plataforma centralizada y puede absorber el coste, convertir el cumplimiento en ventaja competitiva y empujar al resto a desaparecer o a autoexcluirse.

La segunda fractura es todavía más seria: la privacidad. La Electronic Frontier Foundation lleva tiempo advirtiendo que el «age gating» es, en la práctica, un mecanismo de censura y vigilancia, y que además suele chocar con derechos fundamentales. En 2023 ya señalaban cómo tribunales federales habían frenado leyes en Arkansas, California y Texas por su probable vulneración de la Primera Enmienda, precisamente porque la verificación de edad disuade el acceso a expresión protegida y erosiona el anonimato. Y más allá del debate constitucional estadounidense, hay un punto técnico que es casi universal: cualquier esquema que vincule identidad offline con actividad online crea un activo tóxico, irresistible para atacantes y demasiado tentador para usos secundarios. La propia EFF lo resume claramente: los sistemas de verificación de edad acaban siendo sistemas de vigilancia, y ya hemos visto filtraciones y brechas en proveedores de este tipo de servicios.

Quien piense eso de «vale, entonces usemos criptografía y ya está» debería leer a Steven Bellovin: en su análisis sobre verificación de edad preservando privacidad sostiene que, técnicamente, construir un esquema basado en credenciales puede ser «razonablemente directo», pero que los obstáculos legales, económicos y sociales son formidables, hasta quizá insalvables en ciertos países. Y remata con una obviedad incómoda: la auto-declaración de edad es puro teatro, no seguridad. Traducido: o lo haces intrusivo y centralizador (IDs, biometría, terceros), o lo haces inútil. Y en ambos casos introduces externalidades enormes.

Mientras tanto, otras jurisdicciones avanzan por el mismo camino, con matices que no cambian el fondo. En el Reino Unido, Ofcom publicó guías para «age checks» y «age assurance» bajo el Online Safety Act, exigiendo métodos «altamente efectivos» para impedir acceso de menores a pornografía y otros contenidos dañinos. En la UE se habla ya de un «mini wallet» alineado con el European Digital Identity Wallet, con la promesa de estandarizar verificación de edad con enfoque de privacidad y facilidad de uso. Y en think tanks tecnológicos se proponen mecanismos como zero-knowledge proofs como vía para minimizar exposición de datos. Todo suena muy sofisticado… hasta que recuerdas el incentivo real: si obligas a «probar la edad» a escala, acabas construyendo un sistema que permite rastrear, excluir y condicionar el acceso. La tentación de extenderlo más allá de «proteger menores» es prácticamente inevitable. Hoy es la pornografía o las redes sociales; mañana será la «información sensible», el «contenido político», la «salud», la «protesta», el «periodismo incómodo». La infraestructura queda ahí para el gobierno de turno que la quiera utilizar.

¿Y qué hace la comunidad Linux ante esto? La reacción natural es la mínima viable: definir un estándar común y delegar, como intenta la propuesta de recurrir al D-Bus, para que no sean miles de aplicaciones inventando cada una su propio mecanismo y multiplicando riesgo y complejidad. Pero incluso ese «camino mínimo» tiene trampas: normaliza la idea de que el sistema operativo debe etiquetar a su usuario por edad, y abre una interfaz que, por muy bien diseñada que esté, se vuelve un punto de presión regulatoria y un objetivo de abuso. Además, no arregla lo esencial: un menor puede mentir en el setup del sistema, y si la ley empuja a «subir el nivel» hacia verificación real, el salto natural será a documentación, biometría o proveedores externos. Ahí el software libre pierde por partida doble: por recursos (implementación, auditoría, mantenimiento, cumplimiento) y por principios (anonimato, control local, minimización de datos).

La forma sensata de enfrentarse a esto, si de verdad nos preocupa el bienestar de los menores online, empieza por admitir lo obvio: estas medidas son una mala abstracción del problema. Pretenden sustituir educación, acompañamiento, alfabetización digital y diseño responsable por un «check» que, o bien es trivialmente evadible, o bien se convierte en una máquina de recopilar datos. Por eso, el mejor frente es político y legal: apoyar impugnaciones cuando corresponda, pedir marcos de privacidad integrales que reduzcan incentivos de explotación y perfilado (en vez de construir peajes de acceso), y exigir que cualquier obligación técnica sea proporcional, verificable y compatible con los derechos fundamentales.

En paralelo, el ecosistema debería reaccionar como sabe: con estándares abiertos y mínimos, con implementaciones de referencia transparentes, y con una obsesión por la reducción de daño. Ya hay incluso repositorios en Github que se autodefinen como implementación de referencia de esa interfaz, precisamente para evitar la aparición de una explosión de soluciones ad hoc. Si la presión legal se convierte en inevitable, el único terreno defendible es el de «mínimos datos, control local, sin terceros, sin identidad»: almacenar solo tramos, no fechas; evitar tokens persistentes reutilizables entre servicios; y diseñar para que nada de eso pueda utilizarse como identificador transversal. Pero no nos engañemos: eso sigue sin resolver el objetivo declarado (porque se basa en la auto-declaración) y, por tanto, seguirá alimentando la escalada regulatoria hacia soluciones más invasivas.

La conclusión incómoda es que estas leyes, tal como se están planteando, no son tanto una «protección de menores» como una reconfiguración del equilibrio de poder en la capa base de la informática personal. Colocan a pequeños proyectos y comunidades ante una disyuntiva absurda: o incorporan mecanismos que erosionan la privacidad y abren las puertas a futuros abusos, o asumen riesgos legales y presión reputacional. Y en ese pulso, el software libre, que históricamente ha sido una válvula de escape contra el control centralizado, se convierte en un objetivo colateral perfecto. Quizá por eso el debate en Linux está siendo tan intenso: porque, bajo la excusa de «la edad», lo que se está discutiendo es quién diablos manda en tu ordenador.