Categoría: Software libre

🐧🌍Comunes digitales y soberanía tecnológica: 📡las alternativas que ya funcionan📥💡

Inicio

Mientras el debate público sobre tecnología oscila entre el tecno-optimismo de Silicon Valley y el pesimismo ludita, hay una realidad que pasa desapercibida: existen infraestructuras tecnológicas construidas y gobernadas por comunidades, sin ánimo de lucro, que funcionan a escala planetaria y que, en muchos casos, superan en calidad y fiabilidad a sus equivalentes corporativos. No son experimentos marginales. Son los cimientos invisibles sobre los que se sostiene buena parte de la economía digital mundial.

Vintage typewriter alphabet Letter E 18796696 PNGste artículo examina cinco de esas experiencias —Linux, Wikipedia, guifi.net, Decidim y Som Energia— no como curiosidades, sino como pruebas empíricas de que otro modelo de desarrollo tecnológico es posible, viable y escalable. Y argumenta que, si queremos que esa posibilidad se convierta en transformación social, la clave está en la educación.

El oligopolio invisible 

Para entender por qué importan los comunes digitales, conviene primero dimensionar el problema que resuelven.

Cinco empresas —Alphabet (Google), Amazon, Apple, Meta y Microsoft— acumulan una capitalización bursátil combinada que supera los 12 billones de dólares (datos de 2024). Controlan las búsquedas en internet (Google: 91 % de cuota global), las redes sociales (Meta: 3.000 millones de usuarios activos mensuales solo en Facebook), el comercio electrónico (Amazon: 37 % de las ventas online en EE. UU.), los sistemas operativos de los teléfonos móviles (Android de Google + iOS de Apple: 99 % del mercado) y la infraestructura de computación en la nube (AWS de Amazon + Azure de Microsoft + Google Cloud: 66 % del mercado).

Esta concentración no es solo un problema económico. Es un problema político. Quien controla la infraestructura digital controla los flujos de información, los algoritmos que determinan qué vemos y qué no, los datos que generamos con cada clic y, en última instancia, las condiciones materiales de la participación democrática. Como señaló la politóloga Shoshana Zuboff en La era del capitalismo de la vigilancia, no somos los clientes de estas plataformas: somos la materia prima.

La pregunta no es si la tecnología transforma la sociedad —eso ya está ocurriendo—, sino quién la gobierna y en beneficio de quién.

Qué son los comunes digitales (y por qué importan)

El concepto de comunes —o commons en inglés— tiene una larga historia. Se refiere a recursos compartidos que una comunidad gestiona colectivamente, sin que sean propiedad privada de nadie ni estén controlados por el Estado. Los pastos comunales medievales, los sistemas de riego gestionados (la vega de Granada y sus sistema de riego, la huerta valenciana) por agricultores o los bancos de pesca regulados por comunidades costeras son ejemplos clásicos.

La economista Elinor Ostrom, primera mujer en recibir el Nobel de Economía (2009), demostró que las comunidades pueden gestionar recursos compartidos de forma sostenible y eficiente, sin necesidad de privatización ni de intervención estatal, siempre que se cumplan ciertos principios de diseño:

  • límites claros,
  • reglas adaptadas al contexto local,
  • participación de los usuarios en la toma de decisiones,
  • mecanismos de resolución de conflictos y
  • capacidad de autoorganización.

Los comunes digitales trasladan esta lógica al ámbito tecnológico. Son software, conocimiento, infraestructuras o plataformas creados y mantenidos colectivamente, con licencias que garantizan su acceso libre y su gobernanza comunitaria. A diferencia de los recursos naturales, los bienes digitales tienen una propiedad económica particular: son no rivales —el hecho de que yo use un programa de software libre no impide que tú lo uses— y su coste de reproducción es prácticamente cero. Esto los convierte en candidatos ideales para la gestión comunal.

El término soberanía tecnológica complementa esta idea. Se refiere a la capacidad de una comunidad —ya sea un barrio, una ciudad, un país o una red global de personas— para controlar las tecnologías de las que depende: entender cómo funcionan, modificarlas según sus necesidades, no depender de una corporación para acceder a ellas y participar en las decisiones sobre su desarrollo. No se trata de autarquía ni de reinventar la rueda, sino de que la dependencia tecnológica no se convierta en subordinación política. A continuación detallamos cinco comunes que funcionan.

1. Linux: el sistema operativo que sostiene internet 

Tux

Linux es un sistema operativo de código abierto —esto es, un programa cuyo código fuente es público y cualquier persona puede leer, modificar y redistribuir— creado en 1991 por Linus Torvalds, entonces un estudiante finlandés de 21 años. Lo que comenzó como un proyecto personal se convirtió en uno de los mayores esfuerzos colaborativos de la historia de la humanidad.

Los números son difíciles de asimilar. Más de 20.000 personas de 1.700 empresas distintas han contribuido al núcleo de Linux (kernel). El resultado es un sistema que, sin pertenecer a ninguna corporación, domina la infraestructura tecnológica global:

  • El 96 % de los servidores web del millón de sitios más visitados del mundo funcionan con Linux.
  • El 85 % de los teléfonos inteligentes usan Android, que está construido sobre Linux.
  • El 100 % de los 500 supercomputadores más potentes del mundo ejecutan Linux.
  • La Estación Espacial Internacional funciona con Linux. Los coches Tesla funcionan con Linux. La infraestructura de Amazon, Google, Facebook y Netflix funciona con Linux.

Dicho de otro modo: el software más importante del planeta no es propiedad de nadie. Es un bien común. Y no solo funciona, sino que es técnicamente superior a sus alternativas privativas en fiabilidad, seguridad y rendimiento para la inmensa mayoría de usos profesionales.

¿Cómo es posible? Porque la producción colaborativa entre iguales —lo que el profesor de Harvard Yochai Benkler denominó producción entre pares basada en el procomún (commons based peer production)— genera incentivos que el mercado no puede replicar: revisión constante del código por miles de ojos expertos, ausencia de obsolescencia programada, adaptabilidad a necesidades locales y una velocidad de innovación que ninguna empresa individual puede igualar.

GNU – Linux lleva 33 años demostrando que la cooperación a gran escala, sin jefes ni accionistas, produce resultados que superan al modelo corporativo.

2. Wikipedia: el conocimiento como bien común 

Wikipedia es la enciclopedia más grande jamás creada. Contiene más de 60 millones de artículos en más de 300 idiomas, escritos y editados por más de 300.000 personas voluntarias. Opera con un presupuesto anual de unos 150 millones de dólares —financiado íntegramente por donaciones— y un equipo técnico de apenas unos cientos de personas. Para ponerlo en perspectiva: la Enciclopedia Británica, con sus 4.000 articulistas profesionales y tres siglos de historia, publicó 120.000 artículos en su última edición impresa. Wikipedia tiene 500 veces más contenido.

Pero lo verdaderamente notable no es el volumen, sino la gobernanza. Wikipedia funciona con un sistema de autoorganización comunitaria que encaja punto por punto con los principios de Ostrom:

  • normas claras sobre qué constituye una fuente fiable,
  • mecanismos de resolución de disputas entre editores,
  • procesos democráticos para elegir administradores,
  • transparencia total (cada edición queda registrada y es reversible) y
  • sanciones graduales para quienes violan las normas.

¿Es perfecta? No. Tiene sesgos de género (solo el 15–20 % de editores activos son mujeres), sesgos lingüísticos (la Wikipedia en inglés es mucho más completa que la de lenguas minoritarias) y es vulnerable al vandalismo. Pero estas son limitaciones conocidas, documentadas por la propia comunidad, y objeto de esfuerzos activos de corrección. Lo relevante es que, con todos sus defectos, Wikipedia lleva 25 años demostrando que una comunidad global de voluntarios puede producir y mantener un recurso de conocimiento de referencia mundial, sin publicidad, sin muros de pago y sin control corporativo.

3. guifi.net: internet como infraestructura comunitaria 

Aquí la cosa se pone tangible. Porque si Linux y Wikipedia demuestran que el software y el conocimiento pueden ser comunes, guifi.net demuestra que la infraestructura física también puede serlo.

guifi.net es una red de telecomunicaciones comunitaria nacida en 2004 en Osona (Cataluña), en una zona rural donde las operadoras comerciales no ofrecían servicio de banda ancha porque no les resultaba rentable. La respuesta de la comunidad fue: «Si no nos dan internet, lo construimos nosotros».

Guifi.netHoy, guifi.net cuenta con más de 40.000 nodos operativos y más de 40.000 kilómetros de fibra óptica desplegada. Es la red comunitaria de telecomunicaciones más grande del mundo. Ofrece conectividad a hogares, empresas y administraciones públicas, y opera bajo el principio de procomún de red: la infraestructura es de titularidad colectiva, y cualquier persona u organización puede conectarse, usarla y ampliarla siempre que respete unas reglas básicas de interconexión abierta.

El modelo económico es ingenioso. guifi.net no es una empresa ni una ONG, sino una fundación que gestiona un bien común. Los operadores locales (pequeñas empresas, cooperativas, asociaciones) pueden ofrecer servicios comerciales sobre la infraestructura compartida, pero la red en sí no es propiedad de nadie. Es como una carretera pública sobre la que circulan distintos transportistas.

Lo que guifi.net demuestra es crucial: no solo el software inmaterial puede ser un común, sino también el hardware, los cables, las antenas, la infraestructura pesada. Y cuando una comunidad controla su propia conectividad, deja de depender de las decisiones de una corporación sobre dónde invertir y dónde no, qué velocidad ofrecer, a qué precio y con qué condiciones.

Nodos en el mundo guifi.net
Zone name Operatiu Planned Building Testing Inactive Total
Africa 8 62 1 4 1 78
America 20 215 5 13 1 258
Asia 11 22 2 0 0 35
Australia 0 1 0 0 0 1
Europe 37.590 22.140 469 659 8.161 69.627
Ukraine-test 0 1 0 0 0 1
37.629 22.441 477 676 8.163 70.000

4. Decidim: democracia participativa con código abierto 

Decidim (del catalán, “decidimos”) es una plataforma digital de participación democrática de código abierto, nacida en el Ayuntamiento de Barcelona en 2016. Permite a cualquier institución u organización crear procesos participativos: presupuestos participativos, consultas ciudadanas, debates públicos, recogida de propuestas, asambleas digitales y procesos de rendición de cuentas.

Lo que distingue a Decidim de otras plataformas de participación es su arquitectura política. No es solo una herramienta técnica: es un proyecto explícitamente comprometido con la democracia radical. Su código es libre (cualquiera puede auditarlo, modificarlo y usarlo), su gobernanza es comunitaria (las decisiones sobre el desarrollo del software se toman en asambleas abiertas llamadas Metadecidim) y su diseño incorpora deliberadamente salvaguardas contra la concentración de poder: transparencia, trazabilidad de todas las decisiones y resistencia a la manipulación.

Hoy, más de 400 instituciones en todo el mundo usan Decidim: desde el Ayuntamiento de Barcelona y el de Helsinki hasta la Comisión Europea, gobiernos regionales, universidades, cooperativas y movimientos sociales. En Barcelona, más de 70.000 personas han participado en procesos a través de la plataforma.

Decidim encarna un principio que el filósofo francés Bernard Stiegler llamó el carácter farmacológico de la tecnología —del griego phármakon, que significa simultáneamente remedio y veneno—:

la misma tecnología digital que permite la vigilancia masiva y la manipulación algorítmica puede, si se diseña y gobierna de otro modo, convertirse en herramienta de profundización democrática. La tecnología no es buena ni mala por naturaleza; lo que importa es quién la diseña, para qué y bajo qué reglas. 

5. Som Energia: energía renovable y cooperativa 

Som Energia (“Somos energía” en catalán) es una cooperativa de energía verde sin ánimo de lucro, fundada en 2010 en Girona. Sus más de 80.000 socias y socios —que son a la vez propietarios y usuarios— producen y comercializan electricidad 100 % renovable.

El modelo es sencillo y poderoso: cada socia aporta una cuota de capital (100 euros, recuperables si se da de baja), paga la electricidad que consume y participa en la gobernanza de la cooperativa según el principio de «una persona, un voto», independientemente del capital aportado. Los beneficios se reinvierten en nuevas instalaciones renovables: placas solares, parques eólicos, plantas de biogás.

Som Energia no es un caso aislado. Forma parte de un movimiento europeo de comunidades energéticas que está reconfigurando el sector eléctrico desde abajo. La Directiva Europea de Energías Renovables (2018/2001) reconoce explícitamente el derecho de la ciudadanía a producir, consumir, almacenar y vender su propia energía renovable. En Alemania, las cooperativas energéticas representan casi el 40 % de la capacidad renovable instalada. En Dinamarca, cooperativas ciudadanas fueron las pioneras de la energía eólica en los años 80.

Lo que Som Energia demuestra es que el modelo cooperativo funciona incluso en sectores intensivos en capital como la energía. Y que la transición energética no tiene por qué significar simplemente sustituir a Repsol por Tesla: puede significar que la energía sea un bien común, gestionado democráticamente por quienes la consumen.

El patrón: por qué funcionan 

Estos cinco casos son muy diferentes entre sí: software, conocimiento, telecomunicaciones, democracia digital, energía. Pero comparten una estructura común que explica su éxito:

1. Gobernanza comunitaria con reglas claras. Todos aplican, de forma más o menos explícita, los principios de Ostrom: normas de acceso y uso definidas colectivamente, mecanismos de resolución de conflictos, capacidad de los usuarios para participar en las decisiones y sanciones para quienes incumplen. 

2. Código abierto o infraestructura abierta. La transparencia técnica es condición necesaria para la soberanía tecnológica. Si no puedes ver cómo funciona un sistema, no puedes gobernarlo. Linux, Wikipedia, Decidim y guifi.net son radicalmente transparentes. Som Energia lo es en su gobernanza económica.

3. Federación, no centralización. Ninguno de estos proyectos funciona con una estructura jerárquica centralizada. Linux se desarrolla de forma distribuida entre miles de colaboradores. Wikipedia tiene ediciones independientes por idioma. guifi.net es una red de redes locales. Decidim se despliega como instancias autónomas. Som Energia es una cooperativa con grupos locales. Esta estructura federada es lo que les da resiliencia: no tienen un punto único de fallo.

4. Motivación no exclusivamente económica. Las personas que contribuyen a estos proyectos lo hacen por razones diversas: aprendizaje, reputación profesional, compromiso político, sentido de comunidad, satisfacción intrínseca. Esto no significa que sean «gratis» (todos necesitan financiación), sino que su motor principal no es la maximización del beneficio privado, y eso los hace más robustos ante las presiones del mercado.

5. Escala demostrada. No son prototipos ni utopías. Linux sostiene el 96 % de la web mundial. Wikipedia es la quinta web más visitada del planeta. guifi.net tiene más nodos que muchas operadoras comerciales regionales. Decidim lo usan más de 400 instituciones. Som Energia tiene 80.000 socios (y nacida Gerona tiene grupos locales de socios en Granada, Costa Granadina, Sevilla, Málaga). Funcionan a escala real, con usuarios reales, durante años o décadas.

Lo que falta: la brecha entre lo posible y lo real 

Si estas alternativas existen, funcionan y son escalables, ¿por qué no son hegemónicas? ¿Por qué la mayoría de la población sigue usando Windows, buscando en Google, comunicándose por WhatsApp y comprando electricidad a Iberdrola?

La respuesta no es técnica. Es política y cultural.

Primero, hay un problema de poder económico. Las grandes corporaciones tecnológicas invierten miles de millones en crear ecosistemas cerrados que generan dependencia (lock-in): si usas Gmail, es más fácil usar Google Drive, que te lleva a Google Docs, que te lleva a Android, que te lleva a Google Play. Migrar de un ecosistema corporativo a alternativas libres tiene costes de transición reales, aunque sean temporales.

Segundo, hay un problema de desconocimiento. La inmensa mayoría de la población no sabe que Linux existe, no sabe que guifi.net es posible, no sabe que puede ser socia de una cooperativa energética. Y no lo sabe porque el sistema educativo no se lo ha enseñado.

Y aquí llegamos al argumento central de este artículo.

La educación como infraestructura de transformación 

Si los comunes digitales demuestran que otro modelo tecnológico es posible, la pregunta inmediata es cómo hacer que esa posibilidad se convierta en realidad amplia. Y la respuesta, aunque no sea la más espectacular, es probablemente la más sólida: educación.

No hablo de educación como eslogan vacío. Hablo de cambios concretos en lo que enseñamos, cómo lo enseñamos y para qué lo enseñamos.

Primero: alfabetización tecnológica real, no instrumental. En la mayoría de los colegios e institutos, la «competencia digital» se reduce a saber usar procesadores de texto, hojas de cálculo y presentaciones —es decir, a saber usar los productos de Microsoft o Google—. Esto no es alfabetización tecnológica; es adiestramiento como consumidores. Una alfabetización tecnológica real incluiría entender qué es el software libre y por qué importa, saber qué hace una aplicación con tus datos, conocer alternativas a las plataformas corporativas y tener nociones básicas de cómo funciona internet (no para ser ingenieros, sino para ser ciudadanos informados, igual que enseñamos biología sin pretender que todos sean médicos).

Segundo: enseñar cooperación, no solo competición. Nuestro sistema educativo sigue estructurado, en gran medida, alrededor de la evaluación individual y la competencia entre estudiantes. Pero los cinco ejemplos que hemos visto —Linux, Wikipedia, guifi.net, Decidim, Som Energia— son logros colectivos. Nadie construyó Linux solo. Nadie escribió Wikipedia solo. Si queremos que las personas sean capaces de construir y sostener comunes, necesitamos que desde la escuela practiquen la colaboración, la deliberación, la toma de decisiones colectiva y la gestión de conflictos. No como contenido teórico, sino como método pedagógico.

Tercero: enseñar gobernanza de lo común. Los principios de Ostrom —cómo se gestiona un recurso compartido sin que se destruya ni se privatice— deberían ser parte de la formación básica de cualquier ciudadana, igual que lo son las nociones de democracia representativa. Si una comunidad de adolescentes puede gestionar un huerto escolar con reglas acordadas colectivamente, está aprendiendo los mismos principios que permiten que funcione guifi.net o Wikipedia. No hace falta esperar a la universidad para entender qué es un bien común y cómo se cuida.

Cuarto: hacer visibles las alternativas. Uno de los efectos más perversos del oligopolio tecnológico es la invisibilización de las alternativas. Cuando un niño de 12 años cree que «internet» es sinónimo de Google y que «comunicarse» es sinónimo de WhatsApp, el problema no es tecnológico: es de imaginación política. Las escuelas podrían usar software libre en sus aulas. Podrían contribuir a Wikipedia como ejercicio educativo. Podrían tener sus propias instancias de Decidim para tomar decisiones escolares. No como gesto testimonial, sino como práctica que demuestra que otro modo de hacer es real.

Reflexión final: la fuerza social necesaria 

Los cinco ejemplos que hemos recorrido en este artículo son la prueba de algo que a menudo se descarta como ingenuo: que la cooperación voluntaria entre personas libres, organizada con reglas claras y tecnología abierta, puede producir resultados que igualan o superan a los del capital concentrado y a los de la burocracia estatal.

Linux no necesitó un oligopolio para convertirse en el sistema operativo dominante del planeta. Wikipedia no necesitó un consejo de administración para reunir todo el conocimiento humano. guifi.net no necesitó a Telefónica para llevar internet a zonas rurales. Decidim no necesitó a Facebook para crear espacios de deliberación democrática. Som Energia no necesitó a Iberdrola para generar electricidad limpia.

Si se ha podido con el software, con el conocimiento, con las telecomunicaciones, con la democracia digital y con la energía, ¿por qué no con la alimentación, la vivienda, la salud, el transporte, la educación?

La respuesta honesta es: se puede, pero no se podrá sin una masa crítica de personas que sepan que es posible, que entiendan cómo funciona y que estén dispuestas a sostenerlo. Y esa masa crítica no surge espontáneamente. Se construye. Se construye con educación, desde las etapas más tempranas, que enseñe a cooperar y no solo a competir; que muestre alternativas y no solo productos; que forme ciudadanas y no solo consumidores.

No estamos hablando de una revolución violenta. Estamos hablando de algo más profundo y más lento: una transformación cultural que cambie las condiciones de posibilidad. Los comunes digitales ya han demostrado que funciona. Lo que necesitan ahora no es más tecnología, sino más personas que sepan construirlos, usarlos y defenderlos.

El filósofo anarquista Piotr Kropotkin escribió en 1902, en El apoyo mutuo, que la cooperación —no la competencia— es el factor decisivo en la evolución de las especies más exitosas. Más de un siglo después, Linux, Wikipedia, guifi.net, Decidim y Som Energia le dan la razón con datos, código y fibra óptica.

La pregunta ya no es si las alternativas son posibles. La pregunta es si seremos capaces de educar a las generaciones que las conviertan en norma.

El artículo y el autor

Este artículo se basa en el paper académico «Peaceful Anarcho-Accelerationism: Decentralized Full Automation for a Society of Universal Care» (Garrido-Merchán, 2026), disponible en acceso abierto.

Eduardo C. Garrido-Merchán es investigador en Inteligencia Artificial y profesor en la Universidad Pontificia Comillas (ICAI). Su investigación explora la intersección entre tecnología, ética y transformación social.

☮️Contra la guerra del Capital, ahora también en Irán

🖌La batalla decisiva para la fase final de la Guerra Total ha comenzado:  Objetivo Irán 

 

🐧Linux 7.0: el nuevo ciclo del kernel y todo lo que cambia🐧

Tras la publicación estable de Linux 6.19, el proyecto del kernel inicia oficialmente una nueva etapa. Linus Torvalds, fiel a su estilo práctico y sin dramatismos, ha decidido dar el salto a Linux 7.0.

Letter E Magazine Cut-Out Element 23204016 Vector Art at Vecteezyl domingo 8 de febrero de 2026, Torvalds envió un mensaje a la lista de correo de desarrolladores del kernel anunciando (junto con su predicción correcta de que la mayoría de los anuncios de la Super Bowl serían generados por IA) que la próxima iteración del kernel de Linux se llamaría 7.0.

En ese tema, afirmó: «Tengo más de tres docenas de solicitudes de extracción para cuando se abra la ventana de fusión mañana; gracias a todos los primeros mantenedores. Y como la gente se ha dado cuenta en su mayoría, estoy llegando al punto de que me pierdo en los números grandes (casi me quedo sin dedos de manos y pies nuevamente), por lo que el próximo kernel se llamará 7.0.»

Una cosa a tener en cuenta es que Linus a menudo ha dicho que el número de versión principal no tiene relación con los cambios realizados en el kernel. En otras palabras, solo porque estamos a punto de alcanzar el hito 7, no hay por que esperar que este sea un kernel innovador. Este cambio en los números de lanzamiento es solo que Torvalds no quiere mantenerse al día con el esquema de numeración que actualmente es de hasta 19.

No se trata de una ruptura radical del código, sino de una cuestión de numeración: el contador de versiones menores estaba llegando a su límite habitual.

Sin grandes declaraciones épicas, pero con importantes implicaciones técnicas, comienza el ciclo que marcará el rumbo del ecosistema GNU/Linux en 2026.

El salto de numeración no significa que el Kernel vaya a sufrir una revolución técnica, más bien lo contrario. Linus Torvalds ya ha dejado claro que la versión 7.0 del núcleo va a estar centrada, sobre todo, en mejorar la estabilidad, seguridad y fiabilidad de todo el sistema, con nuevas versiones de todos los componentes, una importante limpieza, pero sin grandes cambios revolucionarios en el núcleo.

Una lista breve de todo lo que veremos en esta nueva versión de Linux es:

  • Nuevos drivers para mejorar la compatibilidad con el hardware más reciente.
  • Soporte ampliado para GPUs de próxima generación, asegurando compatibilidad nativa con AMD GFX 12.1, Intel Nova Lake e Intel Battlemage.
  • Mejoras internas en las arquitecturas soportadas.
  • Habilitación de Intel TSX (Intel Transactional Synchronization Extensions) por defecto, recuperando rendimiento que había sido limitado por mitigaciones de seguridad.
  • Actualizaciones en los sistemas de archivos, sobre todo en NTFS y en unidades SSD.
  • Se introduce la nueva funcionalidad OpenTree namespace, que aporta mejoras tanto en seguridad como en rendimiento para tecnologías de contenedorización como Docker y Kubernetes.
  • Optimización de memoria RAM, con parches que aceleran la liberación de memoria hasta un 75% en arquitecturas ARM64 y más del 50% en x86.
  • Seguridad reforzada con la eliminación del soporte para la firma de módulos con el algoritmo SHA-1, obsoleto y vulnerable, mitigando así posibles ataques.
  • Optimización y limpieza de todo el código heredado.
  • Linux 7.0 comienza la integración de Rust como lenguaje de programación alternativo a C.

Está claro que, sin ser un cambio radical, Linux 7.0 va a marcar un antes y un después en este sistema operativo libre. Y, puesto que ya ha llegado a la Release Candidate, podemos instalarla hoy mismo en nuestro sistema para ir probando las novedades en las que tanto ha trabajado la comunidad de Linux liderada por el señor Torvalds.

Conclusión

Linux 7.0 no es una revolución simbólica, pero sí representa una evolución técnica sólida. El cambio de número responde a una tradición práctica, mientras que las mejoras internas fortalecen el rendimiento, compatibilidad y modernización del núcleo.

En un panorama tecnológico dominado por versiones “Pro” y “Ultra”, el kernel Linux sigue demostrando que la innovación real no siempre necesita marketing, sino consistencia, comunidad y software libre.

💚💛❤️Bayık: «La sociedad democrática y la voluntad kurda están siendo atacadas en Rojava»

✊🏽Los trabajadores organizados de Amazon lanzan el tercer número de “The Amazon Worker” con conflictos y victorias sindicales internacionales

🕸Google asesina el internet libre II💩

Google is killing the open web –

En el capítulo anterior narramos🖌

Por qué es importante

C letter logo, png | PNGWinguando se lanzó la especificación XML en 1998, ganó fuerza muy rápidamente, a pesar de su mayor verbosidad, porque al perder parte de la flexibilidad de SGML (la especificación excesiva de la cual HTML era la encarnación más famosa:

«Hay quien dice que HTML no es realmente una aplicación de SGML; esto es discutible: TBL pretendía que fuera uno, e incluso si hubo algunas divergencias significativas en las primeras iteraciones, la especificación HTML 4, que era la definición estándar de HTML en el momento al que me refiero, en realidad lo definió como un lenguaje SGML compatible, incluso si los navegadores nunca lo adoptaron como tal».

favoreció la desambiguación y simplificó el análisis sintáctico de documentos de tipo arbitrario. Combinado con XSLT, permitió que documentos de cualquier tipo estuvieran «listos para Internet» y, lo que es más importante, listos para la World Wide Web, ayudando a impulsar la WWW hacia su objetivo diseñado de un «sistema universal de información vinculada».

Aunque los beneficios de XML y el poder transformador de XSLT llamaron principalmente la atención de profesionales en una gran variedad de campos, a principios de siglo su flexibilidad se extendió también a la más generalizada población de usuarios de la Web a través de la encarnación específica de los RSS y los canal web Atom, que permitían a los usuarios mantenerse informados sobre las noticias y actualizaciones en sus sitios web favoritos sin estar constantemente «entrando y saliendo».

RSS y otras tecnologías basadas en XML como los Pingbacks fueron la columna vertebral de los blogs, la red social distribuida que caracteriza la primera década del siglo XXI.

Con los blogs comunes y distribuidos en múltiples plataformas, la posibilidad de agregar información de fuentes dispares y aún verla presentada como una página web normal, en todos los navegadores, sin necesidad de secuencias de comandos, en una época en la que las implementaciones eran lentas y (gracias a Microsoft, intencionalmente) incompatibles entre sí, se consideró una clara victoria.

A pesar de los esfuerzos de Google para eliminarlo desde 2013, el formato RSS sigue siendo un componente esencial de una web abierta e independiente, todavía en uso generalizado tanto en el lado del servidor como del cliente: se estima que hay más de 500 millones de sitios web que usan WordPress, y todos cuentan con fuentes RSS, incluso cuando no se anuncian adecuadamente; la mayoría, si no todas, las plataformas fediversas también ofrecen fuentes RSS, y algunas (por ejemplo, Friendica) también pueden importarlas y, por lo tanto, funcionar como agregadores; y posiblemente lo más importante, los RSS son el componente fundamental de los podcasts («no es un podcast si no es RSS»), un formato de distribución multimedia con cientos de millones, si no miles de millones, de usuarios en todo el mundo.

Como ya se ha dicho, se está experimentando un resurgimiento a medida que la gente comienza a darse cuenta de lo catastrófica que fue, es, ha sido y será para la web la centralización impulsada por los GAFAM durante la segunda década del siglo XXI (aunque demasiados aún no han aprendido la lección correcta, y simplemente han saltado de un chiringuito nazi al siguiente, o han caído en el disfraz de federación porque es más brillante que la federación real).

XSLT es un complemento esencial de RSS, ya que permite leer detenidamente el feed en el navegador (a menos, por supuesto, que el navegador haga un esfuerzo adicional para evitar que lo visualice, como lo hace Firefox). Esto permite que los sitios con cientos de feeds utilicen el feed en sí (diseñado con XSLT) como página de índice (ejemplo), lo que reduce los costos de alojamiento y ancho de banda. Y, por supuesto, también se puede utilizar para dar estilo a cualquier otro documento XML «estándar» que se pueda encontrar en un sitio: por ejemplo, lo he descubierto recientemente gracias a @[email protected], que WordPress proporciona una hoja de estilo XSLT predeterminada para sus mapas de sitio (aunque curiosamente, ¿parece que no para sus feeds web? Por supuesto, aún puedes enrollar el tuyo y conectarlo en el lugar correcto.)

Como señala @[email protected], XML se usa ampliamente en humanidades digitales (y muchos otros campos), y TEI ofrece un amplio conjunto de hojas de estilo XSLT para transformar marcas comunes de TEI en una variedad de formatos, entre los que se encuentra XHTML, lo que permitiría la visualización directa de los documentos XML.

Y esto es solo el comienzo: como he mostrado en este mismo sitio, es posible usar XSLT para trazar datos XML y, en general, para producir documentos ricos y complejos sin JavaScript, y nuevamente con reducciones potencialmente significativas en los costos de alojamiento y ancho de banda.

Puntos extra: parece que la horda de raspadores LLM que están causando problemas por todas partes tienen algunas dificultades con XML general, por lo que cambiar a XML + XSLT podría funcionar realmente para la autoprotección.

¿Recuerdas AMP? Si realmente quisieras seguir enviando las toneladas habituales de basura inútil al escritorio, pero no al móvil, podrías poner el contenido real en un archivo XML y luego proporcionar dos hojas de estilo XSLT triviales separadas, una para transformarla en la página de escritorio hinchada habitual y otra para transformarla en la abominación simplificada (y menos hinchada) que es AMP HTML, lo que habría sido útil cuando Google introdujo el requisito de que AMP y la página estándar tuvieran que presentar el mismo contenido. Pero, de nuevo, ¿por qué enviar esas toneladas de basura inútil en el escritorio en primer lugar?

Y para ser honesto, las plantillas HTML se ven muy poco impresionantes en comparación con XSLT. Peor aún, ¿por qué la gente reinventa las plantillas sin tan siquiera mencionar XSLT? Cualquier cosa que discuta la creación de plantillas para HTML sin una comparación directa y concreta con XSLT debería descalificarse automáticamente por no estar bien investigada.

Pero lo más importante, incluso si personalmente no te gustan XML y/o XSLT, ¿por qué dejamos que Google decida lo qué es aceptable y lo qué no (y lo más importante, nunca más) en la World Wide Web?

Seguiremos…

💩La fábrica del miedo usa a la infancia como moneda política en Cartes

🎓Revocan la prescripción del caso por las amenazas del policía infiltrado a un militante

HISTORIA SOCIAL DEL JAZZ PRIMITIVO. Capítulo 10

«Renacimiento Negro, Harlemania y Jungle Jazz»

 

🧅La reinterpretación artesanal de un protocolo de Internet: WebTunnel👁

https://medios.centroculturadigital.mx/ccd/contenidos/webtunnel.png

Jacobo Nájera

En tiempos de hipervigilancia, el anonimato también es una forma de resistencia. En este texto, el autor expone uno de múltiples proyectos que buscan crear, desde saberes artesanales, otro tipo de arquitectura de red que haga frente a bloqueos de internet intencionados por entes gubernamentales y corporativos.  

La web alrededor del mundo presenta obstáculos de acceso. Uno de ellos son los bloqueos de internet a nivel capa de red, mismos que consisten en medidas técnicas deliberadas e intencionadas que gobiernos y empresas de telecomunicaciones colocan para imposibilitar la conexión a internet desde diferentes regiones y geografías. 

Sin embargo, hay comunidades que reinterpretan los protocolos de internet —aquellos acuerdos sobre cómo se maneja el flujo de nuestros datos— para ofrecer alternativas de acceso y, así, hacer frente a estas medidas. Así nace WebTunnel, una reinterpretación de uno de los acuerdos de intercambio de datos más extendidos en internet: la web (HTTP). Esta tecnología, localizada en el ecosistema del proyecto Tor, ha recibido contribuciones desde Latinoamérica, entre ellas varias provenientes de Acuarela Taller, un espacio dedicado al desarrollo de tecnologías computacionales y electrónicas artesanales para el ejercicio de los derechos a la comunicación, fundado en Guanajuato, México, en 2019.

Anonimato, enrutamiento y reinterpretación

Tor permite brindar alternativas de acceso con privacidad y anonimato. Esta red de computadoras es operada por personas voluntarias alrededor del mundo. Una de las maneras más conocidas de utilizarla es por medio del Tor Browser, disponible para dispositivos móviles y computadoras.

Su software es desarrollado por la organización Tor Project, que, en sus palabras, tiene como misión: 

Promover los derechos humanos y las libertades mediante la creación y el desarrollo de tecnologías de anonimato y privacidad libres y de código abierto, apoyando su disponibilidad y uso sin restricciones, y fomentando su comprensión tanto científica como general. 

Además, su comunidad está compuesta por diseñadoras, desarrolladoras y activistas. Se trata, pues, de un conjunto de personas que acuerdan tener una arquitectura de red llamada ‘enrutamiento cebolla’, que aporta alternativas de acceso para sortear bloqueos regionales y locales, con capas de privacidad y anonimato al estar utilizando internet. No obstante, esta red tampoco está exenta de bloqueos. Para eludirlos, se requieren los llamados ‘puentes conectables’. Así, dentro del ecosistema Tor nace WebTunnel en diciembre de 2022, con el objetivo de ofrecer una nueva alternativa para que las personas puedan conectarse a la red Tor cuando ésta es bloqueada.

El diseño de este transporte conectable se basó en el artículo “HTTPT: A Probe-Resistant Proxy”, escrito por Sergey Frolov y Eric Wustrow en 2020. Su característica principal es que actúa como un puente de acceso que hace que el tráfico parezca navegación web común y corriente. Ante los ojos de quienes intentan vigilar o bloquear la conexión, parece un simple tráfico cifrado HTTPS, por lo que no lo identifican como parte de la red Tor.

En 2023, Acuarela Taller decidió acompañar el proceso de desarrollo e implementación de esta tecnología mediante el proyecto Arrecife, enfocado en arquitecturas de red centradas en el derecho a la comunicación. El taller colabora en el estudio, desarrollo y despliegue de redes de enrutamiento de tráfico de internet distribuidas en Latinoamérica.

Accesibilidad, documentación y automatización 

Cuando iniciaron las primeras pruebas de WebTunnel, se identificaron algunas necesidades para su implementación y operación. El primer paso, en ese sentido, fue la  elaboración de un manual en castellano e inglés para asegurar un lenguaje común durante las pruebas, tanto dentro como fuera del taller. La documentación, además, permite llevar un registro de la evolución y los cambios que la tecnología experimenta con el tiempo, así como de los obstáculos, decisiones, ideas y necesidades que la influyen y determinan. 

Gracias al manual y a un análisis de la arquitectura de esta tecnología,  se comprendieron cada uno de sus componentes y las funciones que debían cumplir para lograr su propósito. Se identificaron cuáles son las configuraciones más adecuadas, los posibles usos  sociales de la tecnología y los retos para su implementación. En concreto, WebTunnel se presenta como una tecnología valiosa para hacer frente a bloqueos de internet al imitar el tráfico web común y corriente, con potencial de ser más efectiva en escenarios y contextos con medidas de este tipo. 

Sin embargo, también se observó que trabajar con los diferentes componentes de software para implementar los puentes podría dificultar su implementación, debido a la cantidad de estos y a las complejidades de mantenimiento y operación. Por lo tanto, se consideraron dos líneas de exploración en el taller. La primera consistió en reducir la cantidad de componentes de software, donde logramos que pasaran de cuatro a tres, y, la segunda, en automatizar su despliegue a fin de facilitarlo.

Esto resultó en la construcción y publicación de un segundo manual y una herramienta de automatización que, por un lado, explica los pasos del proceso de instalación y, por otro, permite que otras personas voluntarias puedan contribuir a la red Tor instalando puentes WebTunnel con mayor confianza. 

La herramienta de automatización y  los manuales fueron el resultado del aprendizaje y estudio de la instalación de puentes en el sistema de ruteo Arrecife, también parte de Acuarela Taller, compuesto por las regiones Pacífico, Atlántico, Caribe y Golfo de México, nomenclaturas utilizadas para distinguir la ubicación de la infraestructura instalada en Latinoamérica.

Si bien las instancias de WebTunnel fueron habilitadas en Latinoamérica, la intención de este tipo de tecnologías es que estén disponibles alrededor del mundo como opciones de conexión para las personas, en espacios donde hay restricciones o algún tipo de bloqueo de acceso en Internet. Estas limitaciones pueden incluir la imposibilidad de acceder a redes sociales, dificultades para ingresar a sitios web de noticias o interrupciones completas del servicio durante contextos de tensión política o manifestaciones.  

Confiabilidad y publicación de herramientas

Durante varios meses de pruebas y monitoreo, se verificó que la implementación fuera confiable en términos de estabilidad y seguridad, y que fuera de las condiciones del taller pudiera funcionar, desde la instalación del software y su configuración, hasta la actualización y administración. Tras ello, se publicó la herramienta de despliegue  automatizado, que permite instalar, configurar y operar puentes WebTunnel de la red Tor.

Lanzamiento oficial 

Finalmente,  el 12 de marzo de 2024, el Tor Project anunció oficialmente los puentes WebTunnel. Tras este anuncio, se superó el umbral de mil personas usuarias. Las instancias de WebTunnel hospedadas en Arrecife recibieron conexiones de personas usuarias georreferenciadas desde veinte países. En el top diez se encuentran Rusia, Irán, Turkmenistán, China, Estados Unidos, Reino Unido, Alemania, India, Países Bajos y la República de Bielorrusia, algunos de ellos con antecedentes de restricciones, bloqueos o políticas de vigilancia. 

El promedio de personas usuarias que manejaron el total de regiones de Arrecife fue de setecientos y un máximo de mil ochocientos, con velocidades máximas de tráfico de red ascendentes y descendentes de 160 Mbps. El máximo de datos transferidos en diciembre de 2024 fue de cuarenta terabytes. A continuación, desglosamos los porcentajes de uso.

Código  País  Porcentaje 
ru Rusia  44.44%
ir Irán 15.11%
tm Turkmenistán  12.44%
cn China 9.78%
us Estados Unidos  4.89% 
gb Reino Unido  3.56%
de Alemania  2.22%
in India  1.78%
nl Países Bajos  1.78%
by Bielorrusia  0.89%
fr Francia  0.89%
tr Turquía  0.89%
ae Emiratos Árabes Unidos  0.44% 
at Austria  0.44%
au Australia  0.44%
az Azerbaiyán  0.44%
bg Bulgaria  0.44%
br Brasil  0.44%
ca Canadá  0.44%
ch Suiza  0.44%

La red Tor cuenta ahora con más de trescientos puentes WebTunnel, operados por una comunidad que ha contribuido voluntariamente a su implementación y mantenimiento. Estos puentes han registrado un máximo de 5 mil personas usuarias diarias hacia mediados de 2025.

F2FLa identidad visual fue hecha por @kalogatias. Esta imagen está bajo la licencia de producción de pares feminista (F2F-BY). 

💩¿El mundo digital y la inteligencia artificial hacia dónde nos llevan?

🤝Se presenta la publicación ¿Las cooperativas construyen un mundo mejor?

⛓️‍💥Por qué liberé la W.W.W.🏄🏽‍♀️

Mi visión se basaba en compartir, no en explotar – y he aquí por qué vale la pena luchar por ello.

Tim Berners-Lee

Tenía 34 años cuando tuve la idea de la World Wide Web por primera vez. Aproveché todas las oportunidades para hablar de ello: presentándolo en reuniones, dibujándolo en una pizarra para cualquiera que estuviera interesado, incluso dibujando la telaraña en la nieve con un bastón de esquí para un amigo en lo que estaba destinado a ser un día tranquilo.

Me puse muy pesado con los jefes de la Organización Europea para la Investigación Nuclear (Cern), donde trabajaba en ese momento, quienes inicialmente encontraron la idea «un poco excéntrica», pero finalmente cedieron y me dejaron trabajar en ella. Me cautivó la idea de combinar dos tecnologías informáticas preexistentes: Internet e hipertexto, que toma un documento ordinario y le da vida agregando «enlaces».

Creía que ofrecer a los usuarios una forma tan sencilla de navegar por Internet desbloquearía la creatividad y la colaboración a escala global. Si pudieras ponerle algo, luego de un tiempo, tendría todo.

Pero para que la web tuviera todo en ella, todos tenían que poder usarla y querer hacerlo. Esto ya era pedir mucho. Tampoco podría pedirles que pagaran por cada búsqueda o carga que realizasen. Por lo tanto, para tener éxito, tendría que ser libre. Es por eso que, en 1993, convencí a mis gerentes del Cern de donar la propiedad intelectual de la World Wide Web, poniéndola en el dominio público. Regalamos la web a todo el mundo.

Hoy, miro mi invento y me veo obligado a preguntar si sigue siendo libre hoy en día. No, para nada. Vemos un puñado de grandes plataformas recolectando datos privados de los usuarios para compartirlos con corredores comerciales o incluso gobiernos represivos. Vemos algoritmos omnipresentes que son adictivos por diseño y dañinos para la salud mental de nuestros adolescentes. El intercambio de datos personales para su uso ciertamente no encaja con mi visión de una web libre.

En muchas plataformas, ya no somos los clientes, sino que nos hemos convertido en el producto. Nuestros datos, incluso si son anónimos, se venden a actores a los que nunca pretendimos que llegaran, quienes luego pueden dirigirnos contenido y publicidad. Esto incluye contenido deliberadamente dañino que conduce a la violencia en el mundo real, difunde información errónea, causa estragos en nuestro bienestar psicológico y busca socavar la cohesión social.

Tenemos la capacidad técnica para devolver ese poder al individuo. Solid es un estándar interoperable de código abierto que mi equipo y yo desarrollamos en el MIT hace más de una década. Las aplicaciones que se ejecutan en Solid no poseen implícitamente sus datos – tienen que solicitárselos y usted elige si acepta o no. En lugar de estar en innumerables lugares separados en Internet en manos de quienquiera que haya sido revendido, sus datos están en un solo lugar, controlados por usted.

Almacenar su información de una manera inteligente también puede liberarla. ¿Por qué su reloj inteligente escribe sus datos biológicos en un silo en un formato? ¿Por qué su tarjeta de crédito escribe sus datos financieros en un segundo silo en un formato diferente? ¿Por qué sus comentarios de YouTube, publicaciones de Reddit, actualizaciones de Facebook y tweets se almacenan en diferentes lugares? ¿Por qué es la expectativa predeterminada de que se supone que no debes poder ver nada de esto? Generas todos estos datos: tus acciones – tus elecciones, tu cuerpo, tus preferencias, tus decisiones. Deberías poseerlo. Deberías estar empoderado para ello.

En algún lugar entre mi visión original de la web 1.0 y el auge de las redes sociales como parte de la web 2.0, tomamos el camino equivocado. Ahora nos encontramos en una nueva encrucijada, una en la que debemos decidir si la IA se utilizará para mejorar o en detrimento de la sociedad. ¿Cómo podemos aprender de los errores del pasado? En primer lugar, debemos asegurarnos de que los responsables políticos no terminen jugando el mismo juego de ponerse al día de una década que han hecho en las redes sociales. El momento de decidir el modelo de gobernanza de la IA fue ayer, por lo que debemos actuar con urgencia.

En 2017, escribí un experimento mental sobre una IA que funciona para ti. Lo llamé Charlie. Charlie trabaja para usted como su médico o su abogado, sujeto a la ley, las regulaciones y los códigos de conducta. ¿Por qué no se pueden adoptar los mismos marcos para la IA? Hemos aprendido de las redes sociales que el poder recae en los monopolios que controlan y recopilan los datos personales. No podemos permitir que suceda lo mismo con la IA.

Entonces, ¿cómo avanzamos? Parte de la frustración con la democracia en el siglo XXI es que los gobiernos han sido demasiado lentos para satisfacer las demandas de los ciudadanos digitales. El panorama de la industria de la IA es ferozmente competitivo, y el desarrollo y la gobernanza los dictan las empresas. La lección de las redes sociales es que esto no creará valor para el individuo.

Codifiqué la world wide web en una sola computadora en una habitación pequeña. Pero esa pequeña habitación no me pertenecía, estaba en el Cern. El Cern fue creado tras la segunda guerra mundial por las Naciones Unidas y los gobiernos europeos que identificaron un punto de inflexión histórico y científico que requería colaboración internacional. Es difícil imaginar que una gran empresa de tecnología acepte compartir la World wide web sin una recompensa comercial como me permitió el Cern. Es por eso que necesitamos un organismo sin fines de lucro similar al Cern que impulse la investigación internacional de IA.

Regalé la world Wide web de forma libre porque pensé que solo funcionaría si funcionaba para todos. Hoy, creo que eso es más cierto que nunca. La regulación y la gobernanza global son técnicamente factibles, pero dependen de la fuerza de voluntad política. Si somos capaces de reunirlo, tenemos la oportunidad de restaurar la web como una herramienta de colaboración, creatividad y compasión a través de las fronteras culturales. Podemos volver a empoderar a las personas y recuperar la web. No es demasiado tarde.

✍🏼No a la implantación de Chat Control 📲Hoy lanzamos la campaña #TerritorioMóvil, una serie en 5 entregas en la que miramos críticamente el dispositivo más utilizado en la era digital

🕸Google asesina el internet libre I💩

Google is killing the open web

Google está logrando lo que Microsoft no pudo: acabar con la web abierta. Los esfuerzos de los gigantes tecnológicos para hacerse con el control y encerrar los bienes comunes con fines extractivos resultan claros para cualquiera que haya estado siguiendo la historia de Internet durante al menos la última década, y las estrategias adoptadas son tan variadas en técnica como en el éxito que alcanzan, desde Abrazar, Extender, Extinguir (#EEE) a la monopolización y el encierro.

De lo que quiero hablar en este artículo es de la guerra que Google lleva librando contra XML durante más de una década, por qué importa que finalmente hayan invadido lo suficiente como para obtener lo que quieren, y qué podemos hacer para luchar contra esto.

Un poco de historia

Google ingresó en el mercado de los navegadores en un momento en que el desarrollo web comenzaba a ver la luz nuevamente después de la «victoria» de Microsoft en la Primera guerra de los navegadores mediante el abuso del monopolio de su sistema operativo al enviar su Internet Explorer de forma gratuita y, por lo tanto, cortar el «suministro de aire de Netscape», según lo previsto.

Lo que logró romper la corta victoria de Microsoft fue una alianza de navegadores (Opera con su motor Presto, Firefox de Mozilla con su motor Gecko y el recién nacido Safari de Apple, cuyo motor WebKit se bifurcó del motor KHTML que se estaba desarrollando para el entorno de escritorio KDE GNU Linux) que decidieron aprovechar el cumplimiento de sus estándares para reforzar la posición de los demás contra el efecto paralizante del dominio de Microsoft, un dominio que Microsoft trató de proteger recurriendo a los trucos más viles.

Google ingresó al mercado abusando en gran medida de su dominio en la búsqueda web para impulsar la adopción de su navegador Chrome, una práctica no muy diferente a la utilizada por Microsoft para impulsar la adopción de IE, y de legalidad y moralidad igualmente cuestionables, algo que con frecuencia se pasaba por alto con varias excusas, entre ellas el hecho de que Chrome se construyó sobre un núcleo de código abierto, Chromium, que se ensambló principalmente a partir de software y bibliotecas desarrolladas por otras compañías (principalmente, Mozilla y Apple).

En los años del lanzamiento de Chrome, Internet estaba experimentando cambios masivos, con la aparición de plataformas de redes sociales centralizadas como Facebook que comenzaron a erosionar la red social distribuida anterior de plataformas de blogs, el propio servicio de correo Gmail de Google ganando terreno tanto a la oferta de ISP como a otras ofertas «en la nube» como Yahoo! y el Hotmail de Microsoft, y la conectividad móvil creciendo más allá de los «profesionales», gracias principalmente al iPhone de Apple y la reciente adquisición de Android por parte de Google en ese momento, además de algunos jugadores menores de los que he hablado anteriormente.

Para los propósitos de nuestra discusión, estos cambios tuvieron dos puntos principales de enfoque en términos de desarrollo de sitios web.

Por un lado, los desarrolladores web comenzaron a prestar más atención al cumplimiento de los estándares, ya que les brindaba más oportunidades para la creciente base de usuarios de dispositivos móviles, que era poco probable que tuvieran el Internet Explorer dominante en el escritorio como navegador. Esto ayudó a acelerar la desaparición de IE (que todavía era fuerte cuando Chrome se lanzó por primera vez), cuyo cumplimiento de los estándares escamosos fue en última instancia responsable de su desaparición casi una década después y, posteriormente, de la descontinuación completa de su línea (después del breve intento de una repetición bajo el apodo heredado de Edge), y envalentonó a los «desvalidos» del momento (Mozilla, Apple, Opera).

Por otro lado, hubo un claro cambio hacia la centralización de los servicios web, lo que a su vez aceleró el desarrollo de aplicaciones web, interfaces gráficas de usuario para los servicios subyacentes (centralizados) que dependían efectivamente de los navegadores como kits de herramientas multiplataforma, un enfoque que más tarde daría a luz a la abominación conocida como Electron y la pesadilla de seguridad mejor conocida como node.js.

Por supuesto, Google tenía un interés fundamental en hacer de las aplicaciones web una alternativa creíble a las aplicaciones de escritorio, con su servicio de correo ya mencionado y la aplicación Google Maps adquirida y convertida en web. Y dado que su navegador era principalmente una colección de software #FLOSS ya existente y grapado, podían enfocar su esfuerzo de desarrollo en crear una implementación más rápida de #JavaScript, más conocido como V8. No importa el hecho de que incluso años después, las implementaciones nativas de cualquier característica útil seguirían siendo más rápidas y económicas que JavaScript.

Pero incluso antes de su participación directa en el desarrollo de navegadores, Opera y Mozilla habían comenzado a distanciarse de los esfuerzos de estandarización del W3C y establecieron WHATWG, un consorcio de desarrolladores de navegadores dedicado a coordinar el rápido desarrollo de nuevas funciones web sin pasar por el lento proceso de estandarización percibido del W3C.

En verdad, como quedaría claro unos años más tarde, y más aún con Google asumiendo efectivamente el WHATWG y convirtiéndose en un títere de calcetín para dar una apariencia de independencia a sus elecciones, el objetivo principal del WHATWG era secuestrar el desarrollo de tecnologías web en beneficio de los inversores corporativos, mientras que el W3C, con todos sus defectos, había dado prioridad principalmente a las características que serían de interés más general.

(No es casualidad que el estándar más controvertido que haya salido del W3C haya sido probablemente las Extensiones de Medios Cifrados, lanzadas como un intento fallido de seguir siendo relevantes en el espacio web, y que, en cambio, resultaron en un ataque crítico contra su propia credibilidad como administradores de la web abierta.)

La guerra de Google contra XML como proxy de la guerra contra la web abierta:

Podría decirse que el punto de inflexión para la centralización de la web fue el año 2013. Este es esencialmente el año en que GAFAM dejó de intentar fingir que le gustaba el juego limpio y comenzó a «tomar las riendas» de la interoperabilidad. Casualmente, también es el año en que Ópera dejó de ser Ópera, pero hablaré de esto más adelante.

Veamos algunos de los principales hechos relevantes para nuestra discusión:
⮵
1.- 2013 es el año en que Google decide poner fin a Google Reader, un agregador de feeds web (si no el más utilizado) (para feeds #RSS y Atom); la razón oficial dada es que el uso fue declinando; «casualmente» esto sucede poco después de que cierren su AdSense para Feeds (por razones no especificadas, que probablemente se puedan resumir como «nadie quiere anuncios en sus feeds», y especialmente no anuncios de video, no es que no sigan intentándolo);
⮵
2. 2013 es el año en que Google decide cerrar la federación de servidor a servidor XMPP en su servicio de Chat de Google; Facebook hará lo mismo con su producto Messenger el año siguiente;

⮵
3. 2013 es el año en que Google propone por primera vez la eliminación de XSLT, una propuesta tan impopular que seguirá recibiendo comentarios en su contra hasta 5 años después (el último comentario
en el hilo es de 2018);

4. 2013 es el año en que Google elimina el soporte MathML recién introducido de Chrome; se necesitarán 10 años y una empresa externa para devolver el soporte #MathML al navegador.

Esto fue solo el comienzo. Se emprendieron otras acciones diferentes e intentos en los años siguientes.
⮵
1. en 2015, WHATWG presenta la API Fetch, supuestamente pensada como el reemplazo moderno de la antigua XMLHttpRequest; falta de manera destacada en la nueva especificación cualquier mención o método para administrar documentos # XML, a favor de JSON que, en cambio, obtiene un dedicado método de presentación del cuerpo del documento;
⮵
2. en 2015, Google propone desaprobar SMIL, el estándar de animación declarativa e interactividad en SVG; He escrito en el pasado sobre la utilidad de #SMIL y por qué no solo no debe desaprobarse, sino que su uso debería integrarse en # HTML, como señala el W3C;
⮵
3. en 2015, Google también anuncia el proyecto Accelerated Mobile Pages, supuestamente como una forma de hacer que las páginas web sean más accesibles y más rápidas de cargar en dispositivos móviles, que casualmente dependía en gran medida de aprovechar grandes CDN como Google para almacenar en caché el contenido (y opcionalmente pre-renderizarlo); no importa el hecho de que el artículo seminal de Diseño Web Receptivo sobre cómo diseñar para diferentes tamaños de pantalla era de 2010, que el atributo srcset para que las imágenes admitan pantallas de diferentes tamaños ya era compatible con los navegadores actuales de escritorio y móviles en ese momento, y que las razones principales por las que las páginas web no se cargaban rápidamente en dispositivos móviles se debían a la llamada crisis de obesidad web que se conocía al menos desde 2012., y que la razón principal por la que las páginas AMP se cargaban más rápido era porque venían con una décima parte de la basura inútil adjunta a las páginas «normales», por lo que el único beneficio real de AMP era obligar a los dispositivos web a escribir páginas más ágiles, con al menos un mínimo de capacidad de respuesta (y, por supuesto, para Google, para alentarlos a canalizar todo a través de los servidores de Google, o de cualquier otro gigante tecnológico, para facilitar la recopilación de métricas, la publicación de anuncios más rápida y más perfiles de usuarios);

⮵

4. todavía en 2015, Google anuncia la intención de desaprobar el elemento keygen, una característica de seguridad poco conocida pero poderosa que simplificó la generación de pares de claves criptográficas controladas por el usuario para una comunicación segura entre el cliente y el servidor; puede leer más sobre esto en la reacción de Tim Berners-Lee y en las relevantes «Memorias de la vieja web» de Hugo Landau.; cabe destacar que el interés principal de TBL en este elemento era ayudar a construir Solid, una mejora incremental en la WWW para hacerla más resistente a la centralización en la que se había pervertido su idea original (ver también el problema relevante en el rastreador de problemas de Solid); la importancia del manejo simplificado de los certificados de usuario y el papel que desempeñan en la autenticación mutua también se puede suponer por ser una de las características del protocolo Gemini liviano que también nació como respuesta a la centralización y la consiguiente complejidad de la World Wide Web.;
⮵
5. en 2018, Mozilla elimina el soporte RSS de Firefox a partir de la versión 64 y evita activamente abrirlos en el navegador, dándoles un trato aún peor que los archivos XML genéricos, para los que sigue mostrando la estructura (por ejemplo: compare cómo maneja su navegador el XML de estadísticas de uso para esta columna con la forma en que maneja el feed RSS y el feed Atom); la razón oficial es que la función «Marcadores activos» no se pudo portar fácilmente a la nueva arquitectura; el hecho de que el soporte para RSS aún pudiera implementarse a través de extensiones, que Mozilla no enviara una extensión para reemplazar ni siquiera parcialmente la función de Marcadores activos, dejando a sus usuarios en manos de extensiones de terceros potencialmente inseguras, y que los feeds recibieran un trato aún peor que el documento XML genérico muestran que la razón oficial es solo una excusa; esta es una de las principales grietas en la fachada de Mozilla, ya que comienza a mostrar que su existencia es solo una oposición controlada para que Google evite problemas antimonopolio: lo que Google quiere se va, y Google no quiere feeds web, por lo que los feeds web tienen que irse.;
⮵
6. en 2019, Google anuncia una serie de cambios para supuestamente hacer que las extensiones del navegador sean «más seguras» para los usuarios, comenzando a trabajar en lo que luego se convertiría en el Manifiesto de extensión V3; es inmediatamente evidente que al menos algunos de los cambios introducidos están destinados principalmente a evitar que funcionen los bloqueadores de anuncios y, en realidad, no hacen mucho para mejorar la seguridad o la privacidad.; a pesar de varios informes en contra de los cambios propuestos, en el mejor de los casos, ineficaces y, en el peor, perjudiciales, en los años siguientes Google continuará con el cronograma para desaprobar las API de extensión anteriores y finalmente tener éxito en sus esfuerzos de bloqueo de anuncios; aunque este cambio no es relevante actualmente para el enfoque XML/XSLT de este artículo, lo menciono no solo porque es uno de los muchos ejemplos de Chrome convirtiéndose menos en un Agente de usuario y más en una «herramienta de Google en tu ordenador» con el tiempo, sino porque este aspecto es importante para el futuro de XML y XSLT del lado del cliente, como diré más adelante.;
⮵
7. en 2021, Google intentó eliminarperiodistas a este ritmo, pronto no quedará ninguno en Gaza para informarte. algunos modismos comunes de interacción de JavaScript, blandiendo de nuevo la «seguridad» como razón, a pesar de que los cambios propuestos son mucho más extensos que la supuesta amenaza a la seguridad y se proponen mejores soluciones; puede leer sobre esto aquí y notar patrones de comportamiento similares al asalto del que quiero hablar aquí;
⮵
8. en 2023, Google cambia el nombre de su chatbot de Bard a Gemini, eclipsando así por completo el protocolo independiente de 4 años con el mismo nombre; posiblemente sea una coincidencia, lo que lo convertiría en el único ataque involuntario a la web abierta por parte de Google en los últimos 15 años aproximadamente —y en este momento incluso eso es dudoso;
⮵
9. en 2023, Google propone la API de Integridad del Entorno Web, de la que he hablado en su momento; aunque esto solo está relacionado tangencialmente con las iniciativas centradas en XML que es el tema de este artículo, resulta relevante mencionarlo aquí, ya que es otro ejemplo indicativo del impulso para hacer que los navegadores tengan menos Agentes de usuario y más spyware controlado por la empresa;
⮵
10. en 2023, Google elimina el soporte para el formato de imagen JPEG XL, introducido apenas dos años antes, privando a Internet de un formato que finalmente habría cumplido la promesa de un formato unificado para proporcionar compresión competitiva, tanto sin pérdidas como con pérdidas, decodificación progresiva, transparencia y animación, lo que le habría permitido reemplazar los formatos JPEG, PNG y GIF generalizados (y menos eficientes) que han sido el elemento básico de la web durante las últimas décadas. ; esto tampoco está directamente relacionado con XML (a menos que el motivo del odio sea que JPEG XL admita metadatos XMP), pero debe archivarse como «contra la web abierta e independiente», ya que evita al menos la reducción de costos de alojamiento y ancho de banda que ofrecería una transición a JPEG XL.
⮵
11. en 2023, después de reducir la clasificación de los sitios web HTTP simples durante años, Google anuncia una postura aún más agresiva para impulsar la adopción de HTTPS.; Tengo mucho que decir sobre la supuesta «seguridad» de HTTPS (y en particular sobre cómo no significa lo que la mayoría de la gente piensa que significa, particularmente en lo que respecta a la distinción entre la integridad de la conexión entre el cliente y el servidor versus la autenticidad del contenido, particularmente de relevancia tanto para los silos corporativos como para las redes sociales federadas), pero eso es material para un artículo diferente, así que aquí solo vincularé algunos artículos de Dave Winer (uno de los inventores de RSS), especialmente este particularmente profético, y señale la hipocresía de reclamar un interés por la seguridad por parte de la misma compañía que presionó para la eliminación del keygen;
⮵
12. en 2024, Google descontinúa la posibilidad de enviar feeds RSS para su revisión para incluirlos en Google News; la forma en que Google descubre ahora nuevos sitios de noticias o cómo recopila información sobre noticias publicadas es completamente opaca.
⮵

13. en 2025, Google anuncia un cambio en su Política del Programa Raíz de Chrome que, en 2026, dejará de admitir certificados con un Uso Extendido de Claves que incluya cualquier uso que no sea el servidor (subproceso Fediverso relevante, otro hilo Fediverso relevante); esto elimina efectivamente los certificados comúnmente utilizados para la autenticación mutua (¡oye, mira, es el tema de supresión de keygen nuevamente!) que incluyen roles tanto de cliente como de servidor; casualmente, esto también dificulta la implementación de S/MIME, a menos que pase por los servicios de Google, por supuesto, pero la guerra de Google contra el correo electrónico autohospedado merece su propio artículo, así que eso será para otro momento.

Y finalmente llegamos a estos días. Justo cuando las fuentes RSS están regresando y los usuarios comienzan a volverse escépticos de los silos corporativos, Google hace otra carrera para matar a XSLT, esta vez usando WHATWG como títere de calcetín. Particularmente digno de mención, el problema de Chromium correspondiente se creó antes del problema de Github de WHATWG. Por lo tanto, no sorprende a nadie que las reacciones abrumadoramente negativas al problema, las explicaciones detalladas sobre por qué #XSLT es importante y útil, las recomendaciones de que, en lugar de eliminarlo, los navegadores deberían pasar a versiones más recientes del estándar e incluso las indicaciones de bibliotecas mejores y más seguras existentes en las que basar estas nuevas implementaciones, todos los contrapuntos a la eliminación se hayan ignorado por completo.

Aún así, las reacciones negativas fueron tan extensas que, en última instancia, el problema quedó bloqueado, particularmente cuando la gente comenzó a señalar que «no tenemos suficientes recursos para gastar en esta» fue una excusa completamente idiota de compañías multimillonarias, o incluso de empresas más pequeñas como Mozilla que aparentemente tienen suficiente dinero para desperdiciar en funciones que nadie quiere como la integración de chat LLM: esto finalmente ha confirmado que el propósito del problema nunca fue realmente discutir si XSLT debería eliminarse o no, sino solo proporcionar una excusa endeble para pretender que la eliminación fue impulsada por un consenso en lugar de una directiva de arriba hacia abajo de Google.

Las únicas frases verdaderas declaradas por el Google responsable de este problema fueron que los navegadores han estado atascados con una versión obsoleta de XSLT durante más de dos décadas, y que las implementaciones en las que confían (Google y Apple) tienen algunos problemas de seguridad. El Googler en cuestión también omitió convenientemente varios otros hechos importantes.

Por ejemplo, omitió que se han lanzado dos nuevas versiones principales de XSLT desde que esta tecnología se implementó por primera vez en los navegadores: XSLT 2 en 2007 y XSLT 3 en 2017. Esto significa que cuando Google propuso por primera vez eliminar XSLT, ya se había lanzado una versión más nueva y considerablemente más poderosa del estándar durante seis años. Y ya en ese momento la gente pedía que se actualizara el soporte de los navegadores a la nueva versión.

Por lo tanto, no es por casualidad o por falta de recursos que los navegadores se queden atascados con el XSLT 1 de 1999: ha sido una elección intencionada contra la voluntad de los usuarios desde al menos 2013, el año que ya mencionamos como el punto de inflexión para la centralización de la web. XSLT ha sido boicoteado intencionalmente por Google, Apple y Mozilla: usar la excusa de que no se usa ampliamente en la actualidad, después de décadas de socavar cualquier esfuerzo en adopción, negarse a corregir errores o incluso a propperiodistas a este ritmo, pronto no quedará ninguno en Gaza para informarte.orcionar errores significativos para ayudar a depurar problemas relacionados, es una completa burla de las víctimas de estas políticas.

El Googler también omite mencionar que la implementación XSLT de Google y Apple (no la de Mozilla, que desarrolló la suya propia) se basa en un conjunto de bibliotecas de software libre cuyo mantenedor ha sufrido recientemente un bombardeo de informes de problemas casi abusivos de la explotación corporativa característicamente extractiva de # FLOSS, con solicitudes para brindar servicios profesionales sin pagarlos de ninguna manera. Repitámoslo de nuevo: estamos hablando de empresas multimillonarias que han estado explotando el trabajo de los mantenedores de software libre, exigiendo un trato preferencial sin costo para ellos, limitando sus esfuerzos a encontrar errores, sin mover un dedo para solucionarlos realmente, casi como si la intención principal fuera encontrar excusas para borrar la biblioteca en lugar de trabajar para mejorar los bienes comunes. (Y esto es incluso antes de entrar en la forma irresponsable en que se usaban estas bibliotecas.)

Pero, por supuesto, cualquiera que cuestione los motivos de las corporaciones que controlan el WHATWG o señale la abundancia de recursos que tienen, y cómo estos podrían gastarse fácilmente en llevar el soporte de XSLT al siglo XXI en lugar de gastarse en características antagónicas con el usuario, está «fuera de tema» y «en violación del código de conducta».

Al final, el WHATWG se vio obligado a cerrar los comentarios al proMemorias de la vieja webblema de Github para detener la avalancha de comentarios negativos, de modo que el Googler pudiera dar al siguiente paso: comenzar el proceso de formalizar el despido de XSLT.

Y sí, ese problema es una mina de oro si está buscando ejemplos de comportamiento abusivo: en el clásico gaslighting DARVO, el último comentario actual del Googler que abrió el problema en primer lugar es realmente una obra maestra. Y como no puedo responder allí, permítanme responder aquí:

Solo soy un ingeniero y no tengo un presupuesto ilimitado.;

Tú no, Google sí. Pide un presupuesto mayor. La necesidad de solucionar un riesgo de seguridad que, según tu, es tan importante debería ser una muy buena excusa para obtener más recursos. Si fallas en eso, ese es tu problema, no el nuestro, y no es, de ninguna manera, una razón válida para acabar con la web abierta. Los problemas de seguridad no están en el estándar web, están en la implementación que está utilizando (o más específicamente: leeching off).

Solo trato de hacer mi trabajo.

⮵
Esa excusa tampoco funcionó en los juicios de Nuremberg.

Me preocupo mucho por la salud de la web en general.

Mentira patente. Si te importara, tu única prioridad sería cómo mantener XSLT, ya que esa es la única solución que no afecta a los millones de usuarios que todavía usan XML y XSLT en la actualidad. Pero en realidad no te importa la salud de la web, solo te importan los resultados finales de tu empleador. Noticias instantáneas, serás despedido como todos los demás, independientemente de lo duro que los aguantes.

Quiero encontrar soluciones a problemas reales,

No hay nada que encontrar. Todo el hilo de comentarios está lleno de soluciones a los problemas reales. Simplemente no te gusta la respuesta. Han dicho repetidamente que las vulnerabilidades de seguridad se solucionan corrigiendo los errores en la biblioteca que usa Chrome o cambiando a bibliotecas más robustas y modernas como xrust o xee.

Entonces ya has encontrado las soluciones. Pero esa no es la solución que querías encontrar, porque esos «problemas» son solo excusas para finalmente hacer lo que Google ha estado intentando (hasta ahora sin éxito) durante más de diez años: matar XSLT.

y quiero minimizar el dolor que siente la gente por esta discusión sobre la eliminación de XSLT.

Ajá, y aquí vemos el desliz: la discusión nunca fue sobre si debería eliminarse o no. Siempre se trató de: vamos a eliminarlo sin importar lo que pienses; prepárate para sufrir.

Pero es importante recordar que los usuarios comunes que son víctimas de vulnerabilidades de seguridad también sienten dolor, y estoy tratando de minimizarlo también.

Hay una solución muy simple para resolver el «dolor» de tales usuarios, y como todos te han dicho, es arreglar la biblioteca o cambiar a una diferente.

Propuse algunas soluciones a los casos de uso concretos que escuché sobre este asunto. Si todavía hay brechas, me gustaría trabajar para cerrarlas.

Lo siento, pero eso es una completa mierda. Literalmente, no hay forma de resolver todos los casos de uso que XML+XSLT puede y para los que se está utilizando.

Es una lástima que no podamos tener esa discusión aquí; supongo que no podemos reabrir este problema para comentarios externos, debido al tono general de los comentarios anteriores. De cualquier manera, de ahora en adelante, solo responderé a conversaciones técnicas e ignoraré el resto, por mi propia cordura.

Eso es hilarante. Nunca has suministrado un argumento técnico para la eliminación de XSLT.  Literalmente, ni uno solo.

«La biblioteca XSLT que estamos utilizando tiene errores» no es un argumento técnico para eliminar el soporte XSLT del lado del cliente de las especificaciones.

«XSLT «solo» solo lo utilizan millones de personas para decenas de millones de cargas de página por mes» no es un argumento técnico para eliminar el soporte XSLT del lado del cliente. Las métricas ni siquiera son una excusa válida según las propias reglas de Chrome sobre cómo leer datos de telemetría.

«Una empresa de un billón de dólares no tiene los recursos para arreglar o cambiar la biblioteca XSLT», además de ser una completa estupidez, no es un argumento técnico de por qué no debería arreglar o cambiar la biblioteca XSLT.

Todos los comentarios sobre el tema han sido muy técnicos hasta que comenzó a decir tonterías y se negó a proporcionar respuestas técnicas a los comentarios técnicos que había recibido. Usted y sus colegas son los únicos que nunca han presentado un solo argumento técnico para defender su posición de que se debe eliminar el XSLT del lado del cliente. Porque esa nunca fue la intención en primer lugar: solo se trataba de «con qué queremos reemplazar nuestro antiguo soporte XSLT 1.0 con errores».

Y la verdad, independientemente de cuánto no le guste y de cuánto intente suprimirlo, es que solo hay una respuesta a eso, y es: un soporte XSLT más moderno del lado del cliente.

Se espera una actualización aquí como respuesta rápida a esta ridícula defensa de Google y del ingeniero que propuso el cambio, una defensa que procede de un ingeniero que trabajaba para Igalia, la misma compañía que implementó MathML para Chrome 10 años después de que Google lo eliminara, difícilmente un tercero objetivo.

En primer lugar, que Apple y Mozilla estén de acuerdo con algo que Google ha estado presionando para hacer durante más de 10 años no es la defensa de Google y Mason Freed por el cambio que crees que es. Apple no es menos #GAFAM que Google, y Mozilla es una oposición controlada.

Tratar de justificar este acuerdo como una oportunidad para «adelgazar su base de código» también es una completa tontería, cuando esos mismos ingenieros siguen presionando para agregar funciones y API de JavaScript que nadie necesita o desea, o que a veces incluso los usuarios rechazan activamente. Fue una excusa de mierda cuando Mozilla la usó para no restaurar el soporte para el formato de archivo MNG y sigue siendo una excusa de mierda en la actualidad.

La excusa del presupuesto tampoco cuela. Como ya dije anteriormente, si la compatibilidad con XSLT en Chrome tiene tantos errores que se considera un problema de alta seguridad, el enfoque correcto es enfocar los recursos en solucionar ese problema de seguridad, no en cambiar la especificación para que pueda justificar la eliminación del componente defectuoso. Si los equipos de Chrome, Safari y Mozilla no tienen suficientes recursos para solucionar sus problemas de seguridad, nadie debería usar esos navegadores. Y no, cambiar la especificación HTML para eliminar cualquier mención de XSLT para que pueda eliminarse de los navegadores no cuenta como «solucionar el problema de seguridad». Nadie en Google, Apple o Mozilla ha propuesto eliminar el soporte de JavaScript del navegador cada vez que surge un nuevo problema de seguridad relacionado con JavaScript, ¿verdad? Entonces tampoco hagas eso con XSLT.

Si Mozilla realmente se preocupa por aligerar su base de código de Firefox, puede comenzar eliminando todas las funciones de ML que nos han estado empujando con fuerza en contra de nuestra voluntad. Entonces podemos empezar a hablar de «recursos limitados», «aligerar la base de código» e incluso «la seguridad y privacidad del usuario». Lo mismo ocurre con Apple y Google. Por enésima vez: los «recursos limitados» no pueden usarse como excusa cuando los desarrolladores siguen agregando funciones que nadie quiere y se niegan a arreglar cosas de las que la gente se queja: ese no es un problema de recursos limitados, es un problema de recursos mal asignados. Es una cuestión de política.

Además, informarnos sobre el procedimiento de eliminación no tiene sentido, cuando Google ya ha dejado muy claro que en realidad no escucha los comentarios de los usuarios cuando su política lo requiere (¿Alguien manifiesta la eliminación de V2?

Y su TL; DR se equivoca en algo extremadamente importante: nunca se ha dado una buena razón para eliminar el soporte XSLT de los navegadores. Literalmente nunca y ninguna. El hilo estaba bloqueado porque la gente señalaba que las excusas dadas eran todas una mierda, y una mierda son.

(En la segunda entrega continuamos el viaje entre el nazismo web y la libertad)

‼️ La derecha utiliza una denuncia por violación a una menor en el barrio de Hortaleza para cargar contra las personas migrantes. 📰 Si el Ejército israelí sigue asesinando
periodistas a este ritmo, pronto no quedará ninguno en Gaza para informarte.

🗝🔐Securonis GNU/Linux🐃🐧

Securonis GNU/Linux es una distribución centrada en la privacidad y la seguridad basada en la distribución «en pruebas» de Debian. Cuenta con una herramienta preconfigurada que enruta todo el tráfico a través de la red Tor e incluye varias herramientas de privacidad y utilidades personalizadas.

Usando el escritorio ligero MATE, Securosis puede ejecutarse en modo en live o instalarse permanentemente a través del instalador Calamares. Su objetivo es ofrecer un sistema seguro y respetuoso con la privacidad que sea adecuado para su uso diario.

Distribución Centrada en la Privacidad

Securonis GNU/Linux es un sistema operativo ligero y de alto rendimiento basado en Debian Trixie, priorizando la privacidad y la seguridad.

En su núcleo se encuentra una herramienta personalizada llamada Sections, que fuerza todo el tráfico entrante y saliente a través de la red Tor. Esta herramienta también modifica las configuraciones del kernel y de la red para minimizar el riesgo de fuga de datos.

El sistema incluye una amplia gama de herramientas de cifrado, seguridad y borrado de datos. Las consultas DNS se cifran a través de DNSCrypt-Proxy, lo que garantiza una resolución DNS segura.

Anonimato en Todo el Sistema

Securonis viene preinstalado con el Enrutador I2P, una interfaz gráfica de usuario y un navegador preconfigurado, lo que hace que el acceso a la red I2P sea perfecto.

Con el Script de refuerzo del sistema, la configuración del kernel y de la red está reforzada para protegerse contra el acceso no autorizado.

También viene con una herramienta personalizada llamada System Knight, diseñada para escanear el sistema en busca de malware y rootkits.

Securonis Linux viene con docenas de aplicaciones, herramientas, scripts y automatizaciones personalizadas, todas desarrolladas exclusivamente para el sistema. Estas herramientas están totalmente integradas e incrustadas en el sistema operativo.

¿Por qué Securosis?

Securosis ofrece un entorno informático seguro y protegido para el uso diario sin sacrificar la usabilidad o el rendimiento.

Olvídate de depender de máquinas virtuales o unidades flash. No más configuraciones complejas de enrutamiento Tor: todo lo manejas tu.

Puedes ejecutarlo en modo en live sin instalación, o instalarlo permanentemente usando el instalador Calamares.

Su objetivo es ofrecer una experiencia informática segura, minimalista y respetuosa con la privacidad para el uso diario.

Te la puedes bajar en 👇🏼👇🏼👇🏼👇🏼

🤔¿Por qué es tan caro reparar mis dispositivos?

👮🏼Ciberpatrullaje: cuando vigilar se justifica en nombre de la seguridad

HISTORIA SOCIAL DEL JAZZ PRIMITIVO. Capítulo 4 – Nueva Orleans Band Ball (El baile de las bandas de Nueva Orleans)

✊🏽La empresa de software libre más comunista🙄

Igalia, la consultoría coruñesa de Open Source que prioriza el compromiso por el medio ambiente y la inclusión en el mundo tecnológico

Reconozcamos ya que el título ha sido puesto a la ligera y que «compañía comunista» es un oxímoro. La mejor opción hubiera sido: «¿cuál es la cooperativa de trabajadores, más igualitaria y libre de estructuras de poder?«, pero los expertos me dijeron que era un título demasiado largo. Dicho esto, déjame hablar de Igalia y otras cooperativas tecnológicas.

Igalia es una consultora de código abierto con sede en España centrada en navegadores, «tecnologías web del lado del cliente» y mucho más. Es la compañía contratada para trabajar en Servo, el motor de navegador independiente de código abierto después de que Mozilla lo abandonara. Hasta ahora todo bien. La compañía fue fundada en 2001 y ahora emplea a 140 personas en 25 países; son un jugador bastante importante en el espacio de código abierto.

También han sido el segundo mayor contribuyente tanto de Chromium (después de Google) como de WebKit( después de Apple), tienen una asociación con Valve para trabajar en SteamDeck y mucho más. Entonces, ¿qué tienen de diferente?

Bueno, en Igalia no hay CEO, gerentes, jefes, todos tienen el mismo sueldo y la misma capacidad de decisión. También es propiedad total de los trabajadores. Este es un discurso bastante interesante, ¿no? ¿Pero cómo funciona?

Ahora, muy rápido: Igalia no me paga por hablar de ellos, no tengo ningún vínculo con ellos en absoluto. Acabo de enterarme de cómo hacen las cosas y pensé que valía la pena destacarlo.

Etapas

Cuando te contratan para trabajar en Igalia, entras en la etapa de «Personal«, que dura un año. Es similar a un año de incorporación. Luego, se convierte en socio previo durante dos años, lo que lo convierte en un tomador de decisiones completo. Después del tercer año, se convierte en socio, que es copropietario pleno de la empresa.

El objetivo es que todos se puedan convertir e socios; la mayoría de las personas son socios, lo que contrasta con las empresas «normales«, donde solo unas pocas personas tienen plenos poderes en la toma de decisiones.

Los socios y pre-socios componen la Asamblea de Igalia, donde se toman las decisiones; hablaré más adelante sobre esto. Igalia señala que esperar un año antes de dar acceso a la Asamblea a los nuevos empleados da tiempo para que todos confíen plenamente en el nuevo empleado, sí, pero también para que confíen en que la Asamblea realmente está funcionando en su mejor interés.

A los socios también se les paga «un poco más para dar cuenta de sus responsabilidades legales adicionales«, lo cual es razonable.

Antes de hablar sobre la Asamblea, quiero mencionar que también brindan algunos beneficios sólidos a quienes trabajan en Igalia. No solo son muy amistosos en la distancia (¡de nuevo, 140 personas de 25 países!), pero todos los padres (de cualquier género) tienen 8 semanas de permiso de paternidad remunerado, puedes diseñar tu propio horario de trabajo, se cubren los costos de hardware relacionados con el trabajo y otras cosas.

Cada dos meses, la Asamblea se reúne y celebra dos reuniones de medio día para discutir cualquier cosa relacionado con la empresa. De lo contrario, todos los temas se discuten en una lista de correo electrónico.

La Asamblea

Cuando lo piensas, resulta un poco loco: significa que toda la gestión de toda la empresa se realiza a través de:

  1. (a) una lista de correo y
  2. (b) medio día de reuniones al mes.

El objetivo de la Asamblea es mantener informados a los igalianos sobre el estado de la empresa, discutir los problemas que deben resolverse, obtener comentarios sobre las propuestas de toda la empresa y, finalmente, aprobarlas. Esto incluye si aceptar nuevos clientes o contratos, si contratar gente nueva, si cambiar salarios, hacer donaciones, cambiar las condiciones de trabajo, etc.: todo se hace a través de la Asamblea.

También es raro que se «voten» estas propuestas en la Asamblea; en cambio, trabajan en un modelo de creación de consenso en el que un pequeño grupo de igalianos crea una propuesta, recibe comentarios al respecto, tal vez realiza algunas encuestas no vinculantes para recopilar la opinión de los colegas y, finalmente, la propuesta ajustada se convierte en parte de los Acuerdos. Bien, hablemos de esos.

Los Acuerdos

Los Acuerdos son los documentos que contienen los valores de la empresa, sus estatutos, condiciones de empleo (como salario y días de vacaciones), beneficios,etc. Están escritos y controlados por versiones.

Contiene información sobre cómo avanzar en las etapas de Igalia, como ya se ha dicho; pero también contiene información sobre cómo manejar los tiempos financieros difíciles, cómo enmendar los acuerdos, qué decisiones necesitan consenso de la asamblea,etc.

Entre los valores de los Acuerdos, está el Software Libre: establece específicamente que Igalia dará mayor prioridad a los proyectos (internos y externos) donde el resultado de nuestro trabajo se licencie y publique de forma abierta y libre, y prefiere el uso de software libre y de código abierto (cuando sea posible).

Los Acuerdos se pueden cambiar, pero algunas partes requieren un consenso total; el hecho de que a todos se les pague lo mismo es un ejemplo. ¡Imagínese que la Asamblea votara unánimemente que a algunas personas se les debería pagar menos!

Equipos y Comisiones

Si no hay jefes y gerentes, todavía hay una pregunta abierta sobre cómo se gestiona y distribuye el trabajo entre las personas. La respuesta es: equipos y comisiones.

En primer lugar, hay equipos de tecnología que son consultores para un tipo específico de tecnología; actualmente, los equipos son: plataformas web, compiladores, gráficos, chromium, webkit, core, multimedia y sistemas. Cada equipo tiene personas «consultoras» (como programadores) y personas de «apoyo» (que administran ventas, negociación de contratos, organizan reuniones de equipo, etc.). Algunas personas también hacen ambas cosas, ¿por qué no?

Luego, hay un equipo de soporte completo (que incluye a algunas personas de los equipos de tecnología y más), que hace más trabajo en toda la empresa. Estos mantienen los sistemas financieros y de nómina, administran el sistema y trabajan en herramientas internas, realizan reuniones de asambleas y encuestas, realizan comunicaciones y marketing, y más.

A los igalianos también se les asignan roles dentro de sus equipos; estos son cosas como «trabajar en ventas«, «trabajar en estrategia«, «reclutar y entrevistar», «comunicación«, etc. Es un trabajo que solo debería tomar unas pocas horas al mes, y eso lo comparten tanto los consultores como las personas de apoyo.

Luego, la asamblea puede crear una comisión en todos los equipos. Estos trabajan en tareas de coordinación de toda la empresa; ejemplos son la comisión DEI, las comisiones de estrategia, la comisión de responsabilidad social corporativa,etc.

Como ejemplo, la comisión de responsabilidad social corporativa, o CSR, dona el 0,7% de sus ingresos a ONG y organizaciones sin fines de lucro decididas por los igalianos. ¡Como ejemplo, donaron a los esfuerzos de reforestación de árboles nativos en España!

Las funciones, comisiones y equipos son «voluntarios y dinámicos«, lo que significa que cambian según el interés, la necesidad y el estímulo de cada persona. Algunas comisiones rotan a través de miembros, que tienen un mandato de tiempo limitado.

Me encanta esta cita:

en Igalia, no te contratan con una descripción de trabajo específica para que se ajuste como un engranaje a una máquina, te gusten o no sus partes o incluso seas bueno en las partes (que se enumeran en esa descripción del trabajo), no tienes un jefe que te esté microgestionando o interesado en descargarte tipos específicos de trabajo.

¿Esto funciona?

Bueno, hay algunos problemas con los que están lidiando. En primer lugar, incorporar y capacitar a nuevos miembros es difícil, especialmente atraer desarrolladores junior; «tienes que ser bastante bueno para aprender por ti mismo«. Hay un esfuerzo por abordar esto, pero es un problema continuo.

En general, sin embargo, funciona. Igalia tiene una tasa de rotación de empleados del 5%, es decir, el número de personas que se marchan dividido por el número medio de empleados ese año. El promedio de la industria es del 13%, casi tres veces más alto. E, Iqalia sigue creciendo y lleva viviendo y bien más de 20 años, sin experimentar un solo año de contracción, con menos empleados que el anterior.

Ha habido problemas en el pasado; como ejemplo, se menciona una ocasión en la que perdieron un gran cliente que, en ese entonces, era una buena parte de los ingresos de la empresa. Nadie fue despedido, pero tuvieron que «ajustar» los salarios hasta que todos estuvieran completos nuevamente, y ese dinero finalmente se devolvió. Entonces, al final funcionó.

¿Es legal?

La legislación española sí contempla las cooperativas, al igual que en la mayoría de los países. Sin embargo, eso conlleva algunos requisitos adicionales, como que el 85% de los socios sean de España, una limitación que Igalia no quería. Por lo tanto, no están registradas como cooperativas, sino como sociedades anónimas de responsabilidad limitada.

Si eres de España, puedes ser un empleado directo del italiano; si estás fuera de él, serás un profesional independiente. Después de tres años, tiene la opción de convertirse en socio legal del negocio, comprando una parte igual del mismo a un precio fijo. No es obligatorio, pero se espera.

Técnicamente hablando, sí tienen algún administrador legal, ya que así lo exige la ley; sin embargo, el puesto rota cada tres años.

Finalmente, quiero mencionar que hay muchas cooperativas tecnológicas, todas trabajando de diferentes maneras. ¡Incluso puedes tener listas interminables en la web! Sin embargo, creo que Italian es la cooperativa más grande que ha tenido un impacto tan directo en el mundo del software libre, ¡y me encanta cómo funcionan!

📞La mayoría compra un teléfono nuevo cada 2.5 años, hay mejor opción

💩El Costo Oculto de las Imágenes Generadas por IA

😡Empresas de IA están atacando la infraestructura del Software Libre👎🏽

LibreNews

Los scrapers de los grandes modelos de lenguaje (LLM) están atacando la infraestructura de los proyectos de software libre, y va a más.

Hace unos días, Drew DeVault, fundador y director ejecutivo de SourceHut, publicó en su blog un artículo titulado «Por favor, deje de externalizar sus costos en mis narices«, donde se quejaba de que las empresas de LLM estaban rastreando datos sin respetar los robots.txt y provocando interrupciones graves en SourceHut.

Por favor, deje de externalizar sus costos en mis narices

17 de marzo 2025 en Drew DeVault’s blog

Esta publicación de blog expresa experiencias y opiniones personales y no refleja ninguna política oficial de SourceHut.

En los últimos meses, en lugar de trabajar en nuestras prioridades en SourceHut, he tenido que dedicar entre el 20 y el 100% de mi tiempo en una determinada semana a mitigar los rastreadores LLM hiperagresivos a gran escala. Esta no es la primera vez que SourceHut ha estado en el lado equivocado de alguna mierda maliciosa o ha pagado los costos externos de otra persona; cada dos años alguien inventa una nueva forma de arruinar mi día.

Hace cuatro años, decidimos exigir el pago para usar nuestros servicios CI porque se estaba abusando de ellos para extraer criptomonedas. Alternamos entre períodos de diseño e implementación de herramientas para frenar este abuso y períodos de interrupción casi completa cuando se adaptaron a nuestras mitigaciones y saturaron toda nuestra computación con mineros que buscaban ganancias. Ya era bastante malo tener que rogarle a mis amigos y familiares que evitaran «invertir» en la estafa sin que la estafa ingresara a mi negocio y me destrozara el lugar todos los días.

Hace dos años, amenazamos con incluir en la lista negra el espejo del módulo Go porque, por alguna razón, el equipo de Go piensa que ejecutar terabytes de clones de git todo el día, todos los días para cada proyecto Go en git.sr.ht es más barato que mantener cualquier estado o usar webhooks o coordinar el trabajo entre instancias o incluso simplemente diseñar un sistema de módulos que no requiera que Google haga dos forjas git cuyos presupuestos anuales completos sean considerablemente más pequeños que el salario de un solo ingeniero de Google.

Ahora es LLMs. Si crees que estos rastreadores respetan a los robots.txt entonces son varias suposiciones de buena fe alejadas de la realidad. Estos bots rastrean todo lo que pueden encontrar, robots.maldita sea txt, incluidos puntos finales costosos como git blame, cada página de cada registro de git y cada confirmación en cada repositorio, y lo hacen utilizando Agentes de usuario aleatorios que se superponen con los usuarios finales y provienen de decenas de miles de direcciones IP, en su mayoría residenciales – en subredes no relacionadas, cada una haciendo no más de una solicitud HTTP durante cualquier período de tiempo que intentamos medir, adaptándose y mezclándose de manera activa y maliciosa con el tráfico del usuario final y evitando intentos de caracterizar su comportamiento o bloquear su tráfico.

Estamos experimentando docenas de interrupciones breves todas las semanas, y tengo que revisar nuestras mitigaciones varias veces al día para evitar que ese número aumente. Cuando tengo tiempo para trabajar en otra cosa, a menudo tengo que abandonarla cuando se encienden todas nuestras alarmas porque nuestro conjunto actual de mitigaciones dejó de funcionar. Varias tareas de alta prioridad en SourceHut se han retrasado semanas o incluso meses porque seguimos siendo interrumpidos para lidiar con estos bots, y muchos usuarios se han visto afectados negativamente porque nuestras mitigaciones no siempre pueden distinguir de manera confiable a los usuarios de los bots.

Todos mis amigos administradores de sistemas están lidiando con los mismos problemas. Le estaba pidiendo a uno de ellos comentarios sobre un borrador de este artículo y nuestra discusión fue interrumpida para tratar con una nueva ola de bots LLM en su propio servidor. Cada vez que me siento a tomar una cerveza, cenar o socializar con mis amigos administradores de sistemas, no pasa mucho tiempo antes de que nos quejemos de los bots y preguntemos si el otro ha descifrado el código para deshacerse de ellos de una vez por todas. La desesperación en estas conversaciones es palpable.

Ya se trate de estafadores de criptomonedas que extraen recursos informáticos de software libre o ingenieros de Google demasiado perezosos para diseñar su software correctamente o Silicon Valley estafando todos los datos que pueden tener en sus manos a expensas de los demás… estoy harto y cansado de tener todos estos costos externalizados directamente en mi puta cara. Haz algo productivo para la sociedad o aléjate de mis servidores. Ponga todos esos miles de millones y miles de millones de dólares en el bien común antes de que los administradores de sistemas comiencen colectivamente una revolución para hacerlo por usted.

Deja de legitimar LLM o los generadores de imágenes de IA o Copiloto de GitHub o cualquiera de esa basura. Te ruego que dejes de usarlos, que dejes de hablar de ellos, que dejes de hacer otros nuevos, simplemente detente. Si lanzar CO2 al aire y arruinar toda nuestra agua dulce y traumatizar a los trabajadores mal pagados y hacer miserables a todos los administradores de sistemas que conoces y robar códigos, libros y arte a gran escala y arruinar nuestra maldita democracia no es suficiente para que dejes esta mierda en paz, ¿qué es?

Si trabaja personalmente en el desarrollo de LLMs, sepa esto: Nunca volveré a trabajar con usted y recordaré qué lado eligió cuando estalle la burbuja.

Me dije: «¡Interesante!«, y seguí adelante.

Después, ayer por la mañana, la infraestructura de KDE GitLab se vio abrumada por otro rastreador de IA, con IP de un rango de Alibaba; esto provocó que GitLab estuviera temporalmente inaccesible para los desarrolladores de KDE.

Luego descubrí que, hace una semana, una chica de Anime comenzó a aparecer en la instancia de GNOME GitLab, a medida que se cargaba la página. Resulta que es la página de carga predeterminada de Anubis, un retador de prueba de trabajo que bloquea los scrapers de IA que están causando interrupciones.

A estas alturas, debería estar bastante claro que esto no es una coincidencia. Los scrapers de IA se están volviendo cada vez más agresivos y, dado que el Software Libre depende de la colaboración pública, mientras que las empresas privadas no tienen ese requisito, esto está imponiendo una carga adicional a las comunidades de código abierto.

Así que intentemos obtener más detalles, volviendo a la publicación del blog de Drew. Según Drew, los rastreadores LLM no respetan a los robots.requisitos de txt e incluyen puntos finales costosos como git blame, cada página de cada registro de git y cada confirmación en su repositorio. Lo hacen utilizando Agentes de usuario aleatorios de decenas de miles de direcciones IP, cada una de las cuales no realiza más de una solicitud HTTP, tratando de mezclarse con el tráfico de usuarios…

Debido a esto, es difícil salir con un buen conjunto de mitigaciones. Drew dice que varias tareas de alta prioridad se han retrasado durante semanas o meses debido a estas interrupciones, los usuarios se han visto afectados ocasionalmente (porque es difícil distinguir bots y humanos) y, por supuesto, esto provoca interrupciones ocasionales de SourceHut.

Estamos experimentando docenas de interrupciones breves todas las semanas, y tengo que revisar nuestras mitigaciones varias veces al día para evitar que ese número aumente. Cuando tengo tiempo para trabajar en otra cosa, a menudo tengo que abandonarla cuando se encienden todas nuestras alarmas porque nuestro conjunto actual de mitigaciones dejó de funcionar. Varias tareas de alta prioridad en SourceHut se han retrasado semanas o incluso meses porque seguimos siendo interrumpidos para lidiar con estos bots, y muchos usuarios se han visto afectados negativamente porque nuestras mitigaciones no siempre pueden distinguir de manera confiable a los usuarios de los bots.

Drew no distingue aquí entre qué empresas de IA son más o menos respetuosas con los robots.archivos txt, o más precisos en sus informes de agentes de usuario; podremos ver más sobre eso más adelante.

Finalmente, Drew señala que este no es un tema aislado. Nos dice:

Todos mis amigos administradores de sistemas están lidiando con los mismos problemas. Le estaba pidiendo a uno de ellos comentarios sobre un borrador de este artículo y nuestra discusión fue interrumpida para tratar con una nueva ola de bots LLM en su propio servidor. Cada vez que me siento a tomar una cerveza, cenar o socializar con mis amigos administradores de sistemas, no pasa mucho tiempo antes de que nos quejemos de los bots y preguntemos si el otro ha descifrado el código para deshacerse de ellos de una vez por todas. La desesperación en estas conversaciones es palpable.

Lo que me lleva de vuelta a los problemas de KDE GitLab de ayer. Según Ben, parte del equipo de administradores de sistemas de KDE, todas las IP que realizaban este DDoS afirmaban ser MS Edge y se debían a empresas chinas de IA; menciona que los operadores occidentales de LLM, como OpenAI y Anthropic, al menos estaban estableciendo una UA adecuada, nuevamente, más sobre esto más adelante.

La solución, por ahora, ha sido prohibir la versión de Edge que los bots decían ser, aunque es difícil creer que esta sea una solución definitiva; estos bots parecen interesados en cambiar los agentes de usuario para tratar de integrarse lo más posible.

De hecho, GNOME ha estado experimentando problemas desde noviembre pasado; como solución temporal, limitaron la velocidad de los usuarios que no habían iniciado sesión para que no vieran solicitudes de fusión y confirmaciones, lo que obviamente también causó problemas para invitados humanos reales.

La solución por la que se decidieron finalmente fue cambiar a Anubis. Esta es una página que presenta un desafío para el navegador, que luego tiene que dedicar tiempo a hacer algunos cálculos y presentar la solución al servidor. Si es correcto, obtienes acceso al sitio web.

Según el desarrollador, este proyecto es «una respuesta un poco nuclear, pero los robots de los scrapers de IA tan agresivos me han obligado. Odio tener que hacer esto, pero esto es lo que obtenemos del Internet moderno porque los bots no se ajustan a los estándares como los robots.txt, incluso cuando dicen«.

Sin embargo, esto también está causando problemas a los usuarios. Cuando muchas personas abren el enlace desde el mismo lugar, puede suceder que reciban algún ejercicio de mayor dificultad que les llevará algún tiempo completar; hay usuarios que hablan de un minuto de retraso y otros, desde sus móviles, tienen que esperar hasta dos minutos.

¿Por qué? ¡Bueno, se publicó un enlace de GitLab en una sala de chat! Del mismo modo, lo mismo sucedió cuando la solicitud de fusión de GNOME con almacenamiento en búfer Triple se publicó en Hacker News y, por lo tanto, recibió mucha atención allí. Como dijo el desarrollador, es una opción nuclear para los rastreadores, pero también tiene consecuencias humanas.

En Mastodon, un administrador de sistemas de GNOME, Bart Piotrowski, compartió amablemente algunos números para que la gente entendiera completamente el alcance del problema. Según él, en aproximadamente dos horas y media recibieron 81 mil solicitudes en total, y de esas solo el 3% pasó la prueba de trabajo de Anubi, lo que indica que el 97% del tráfico eran bots, ¡un número increíble!

Dicho esto, al menos eso funcionó. Otras organizaciones están teniendo dificultades para lidiar con estos scrapers.

Como ejemplo, Jonathan Corbet, quien dirige la fuente de noticias de software libre LWN, advierte a los usuarios que el sitio web puede ser «ocasionalmente lento», debido a los DDoS de los bots scrapers de IA. Afirma que «solo una pequeña fracción de nuestro tráfico está sirviendo a lectores humanos reales» y, en algún momento, los bots «deciden atacarnos desde cientos de direcciones IP a la vez. [..] No se identifican a sí mismos como bots y robots.txt es lo único que no leen del sitio«.

Muchos expresaron solidaridad, incluido Kevin Fenzi, administrador de sistemas del proyecto Fedora. También han tenido problemas con los scraper de IA: en primer lugar, hace un mes tuvieron que luchar para obtener pagure.io para seguir con vida:

Sin embargo, las cosas han empeorado con el tiempo, por lo que han tenido que bloquear un montón de subredes, lo que también ha afectado a muchos usuarios reales. Por desesperación, en un momento Kevin tuvo que prohibir todo Brasil para que las cosas volvieran a funcionar; según tengo entendido, esta prohibición sigue vigente y no está tan claro dónde se podría encontrar una solución a más largo plazo.

Y, como señala Neal Gompa, incluso este bloqueo de un país entero solo te lleva hasta cierto punto, y aparentemente la infraestructura de Fedora ha estado «inactiva regularmente durante semanas» debido a los scrapers de IA.

Otro proyecto que se ha visto afectado por este problema en la última semana es Inkscape. Según Martin Owens, no se trata de » los DDoS chinos habituales del año pasado, sino de un montón de empresas que comenzaron a ignorar nuestra configuración de red y comenzaron a falsificar la información de su navegador. Ahora tengo una lista de bloqueo Prodigiosa. Si trabajas para una gran empresa que hace IA, es posible que ya no obtengas nuestro sitio web«.

Y, bueno, Martin no es el único desarrollador que ha creado una «lista de bloqueo prodigiosa«. Incluso BigGrizzly de Frame software se vio inundado por un rastreador LLM defectuoso y creó una lista de 460 KIPs con agentes de usuario falsificados para prohibir; se ofrece a compartir la lista.

Un intento más integral de esto es la » ia.robots.proyecto «txt», una lista abierta de rastreadores web asociados con empresas de IA. Ofrecen robots.txt que implementa el Protocolo de Exclusión de Robots y a .archivo htaccess que devolverá una página de error al recibir una solicitud de cualquier rastreador de IA en su lista.

Podemos obtener más números sobre los rastreadores si retrocedemos unos meses. Aquí hay una publicación de Dennis Schubert sobre la infraestructura de la Diáspora (una red social descentralizada de código abierto), donde dice que «mirar los registros de tráfico lo enojó de manera impresionante«.

En la publicación del blog, afirma que una cuarta parte de todo su tráfico web se debe a bots con un agente de usuario OpenAI, el 15% se debe a Amazon, el 4,3% se debe a Anthropic, etc. En general, estamos hablando de que el 70% de todas las solicitudes provienen de empresas de IA.

Según él,

no solo rastrean una página una vez y luego siguen adelante. Oh, no, vuelven cada 6 horas porque jajaja por qué no. Tampoco les importan un carajo los robots voladores.txt, porque ¿por qué deberían? […] Si intentas limitarles la velocidad, simplemente cambiarán a otras IP todo el tiempo. Si intentas bloquearlos mediante una cadena de agente de usuario, simplemente cambiarán a una cadena UA que no sea de bot (no, de verdad). Esto es literalmente un DDoS en todo Internet.

fullscreen

Un número similar se da en el proyecto Read the Docs. En una publicación de blog llamada «Los rastreadores de IA deben ser más respetuosos«, afirman que bloquear a todos los rastreadores de IA disminuyó inmediatamente su tráfico en un 75%, pasando de 800 GB/día a 200 GB/día. Esto hizo que el proyecto perdiera alrededor de 1.500 $ al mes.

El resto del artículo también es bastante impresionante; habla de rastreadores que descargan decenas de terabytes de datos en unos pocos días, o más. Es difícil bloquearlos por completo, ya que usan varias IP diferentes.

Me pregunto cuánto de esto es scrapear datos de capacitación y cuánto, en cambio, es la función de «búsqueda» que brindan la mayoría de los LLM; sin embargo, según Schubert, los rastreadores «normales» como los de Google y Bing solo suman una fracción de un solo punto porcentual, lo que sugiere el hecho de que otras empresas están abusando de su poder en la web.

Pero no se trata solo de raspadores, o lo habría titulado «scrapers de IA«, no «empresas de IA«. Otro problema con el que la comunidad de código abierto ha estado luchando son los informes de errores generados por IA, como ejemplo.

Esto fue informado por primera vez por Daniel Stenberg del proyecto Curl, en una publicación de blog titulada «The I in LLM significa Inteligencia«. Curl ofrece un proyecto de recompensas por errores, pero últimamente, se han dado cuenta de que muchos informes de errores son generados por IA. Estos parecen creíbles y requieren mucho tiempo del desarrollador para verificarlos, pero también contienen las alucinaciones típicas que esperarías de las IA.

fullscreen

Es una locura tener que revisar tu propio código porque un informe de error te dice en confianza que hay algún problema de seguridad crítico que solucionar y no encontrarlo, porque el problema es solo una alucinación de la IA.

fullscreen

Seth Larson informó de un problema similar, Larson forma parte del equipo de triaje de informes de seguridad para Python, pip, urllib3, Requests y ogtros. Dice,

He notado recientemente un aumento en los informes de seguridad de muy baja calidad, spam y alucinaciones de LLM para proyectos de código abierto. El problema es que en la era de los Lms, estos informes parecen a primera vista ser potencialmente legítimos y, por lo tanto, requieren tiempo para refutarlos.

fullscreen

Este es un problema bastante grande. Como señala, responder a los informes de seguridad es costoso, y responder a informes de errores inventados pero creíbles causa una carga adicional significativa para los mantenedores, lo que podría expulsarlos del mundo del código abierto.

fullscreen

El artículo termina con una solicitud: por favor, no use sistemas AI o LLM para detectar vulnerabilidades. Dice:

«Estos sistemas de hoy en día no pueden entender el código, encontrar vulnerabilidades de seguridad requiere comprender el código Y comprender conceptos a nivel humano como intención, uso común y contexto.«.

Quiero señalar de nuevo que estos problemas impactan de forma desproporcionada en el mundo del Software Libre; no solo los proyectos de código abierto a menudo tienen menos recursos en comparación con los productos comerciales, sino que, al ser proyectos impulsados por la comunidad, mucha más de su infraestructura es pública y, por lo tanto, susceptible tanto a rastreadores como a informes de errores o problemas generados por IA.

Negras tormentas agitan los aires…

Sobre: Rocío (documental)

Rocío (Fernando Ruiz Vergara, 1980)_Versión íntegra

🦊Mozilla nos pega un susto⛵️

The Hacker News

Mozilla ha actualizado los términos de uso de Firefox después de la reacción en contra por el lenguaje de ampliación de la licencia de datos

Alphabet Mozilla, el fabricante del navegador Firefox, actualizó el viernes sus Términos de uso por segunda vez en la misma semana, tras recibir fuertes criticas por un lenguaje demasiado nebuloso que parecía otorgar a la compañía los derechos de toda la información cargada por los usuarios.

Los Términos de Uso ahora revisados establecen:

Otorgas a Mozilla los derechos necesarios para operar Firefox. Esto incluye procesar tus datos como se describe en el Aviso de Privacidad. de Firefox. También incluye una licencia no exclusiva, libre de regalías y mundial con el propósito de hacer lo que solicite con el contenido que ingrese en Firefox. Esto no otorga a Mozilla ninguna propiedad sobre ese contenido.

Una versión anterior de esta cláusula, que entró en vigencia el 26 de febrero, decía:

Cuando carga o ingresa información a través de Firefox, por la presente nos otorga una licencia mundial no exclusiva, libre de regalías para usar esa información para ayudarlo a navegar, experimentar e interactuar con el contenido en línea como lo indique con su uso de Firefox.

El desarrollo se produjo días después de que la compañía introdujera por primera vez los Términos de uso (TOU) de Firefox, junto con un Aviso de Privacidad actualizado que tiene como objetivo brindar a los usuarios más transparencia en sus prácticas de datos.

«Hemos escuchado algunas de las preocupaciones de nuestra comunidad con partes de la TOU , en concreto las licencias«, declaró Ajit Varma, vicepresidente de Producto de Mozilla, en un comunicado. «Nuestra intención era ser lo más claros posible sobre cómo hacemos que Firefox funcione, pero al hacerlo hemos creado también cierta confusión y preocupación.»

Mozilla remarcó que ni compra ni vende datos sobre sus usuarios, y que realizó los cambios porque ciertas jurisdicciones definen el término «vender» de manera más amplia que otras, incorporando las diversas formas en que la información personal de un consumidor cambia de manos con otra parte a cambio de beneficios monetarios o de otro tipo.

Además de eso, dijo que ya recopila y comparte algunos datos con sus socios de anuncios opcionales publicados en pestaña Nueva y sugerencias patrocinadas en la barra de búsqueda como un medio para mantenerse «comercialmente viable«.

Mozilla también señaló que, si bien no accede a las conversaciones de los usuarios con chatbots de inteligencia artificial (IA) de terceros habilitados a través de la barra lateral (y mediante un acceso directo), sí recopila datos técnicos y de interacción sobre cómo se usa esta función para ayudar a mejorar el navegador Firefox.

Esto incluye la frecuencia con la que se elige a cada proveedor externo de chatbot, la frecuencia con la que se utilizan las indicaciones sugeridas y la longitud del texto seleccionado.

«Cada vez que compartimos datos con nuestros socios, trabajamos mucho para asegurarnos de que los datos que compartimos estén desprovistos de información potencialmente identificable, o compartidos solo en conjunto, o se pongan a través de nuestras tecnologías de preservación de la privacidad (como OHTTP)«, dijo Varma.

El rechazo a los Términos de uso de Mozilla sigue a la nueva política de seguimiento de anuncios de Google que ha atraído el escrutinio de reguladores y organismos de control que dicen que plantea problemas de privacidad.

Las políticas del programa de plataformas de anuncios, que se pusieron en marcha el 16 de febrero de 2025, permiten el uso de direcciones IP para tomar huellas de los usuarios y llegar a ellos en todas las plataformas sin la necesidad de volver a identificarlos. La Oficina del Comisionado de Información del Reino Unido (ICO, por sus siglas en inglés) lo ha calificado de cambio «irresponsable«.

«Las organizaciones que busquen implementar técnicas de huellas para publicidad deberán demostrar cómo cumplen con los requisitos de la ley de protección de datos«, declaró la ICO en un comunicado. «Estos incluyen brindar transparencia a los usuarios, garantizar el consentimiento otorgado libremente, garantizar un procesamiento justo y defender los derechos de información, como el derecho a borrar.«

Para saber más, o no:

🦊Mozilla responds to backlash over new terms, saying it’s not using people’s data for AI

⛵️Mozilla flamed by Firefox fans after promises to not sell their data go up in smoke

Betterworld Logo

Mozilla Responds to User Backlash with Revised Firefox Terms