¿Alguien puede explicar si Cloudflare chantajeó a Canonical?
(flyingpenguin.com)- Los servicios web públicos de Canonical estuvieron caídos unas 20 horas desde el 30 de abril de 2026 a las 16:33 UTC, y los endpoints de los repositorios de Ubuntu también terminaron fallando más tarde
- Un grupo proiraní que se atribuyó la responsabilidad del ataque dijo que usó el servicio pago de DDoS Beamed, que anuncia evasión de Cloudflare y rotación de IP residenciales
- La infraestructura de registro y enrutamiento vinculada al dominio de Beamed conduce a registros de Cloudflare AS13335, Immaterialism, AS39287 y Materialism s.r.l.
- La reasignación de AS39287 y la renovación de certificados apex de Canonical para archive.ubuntu.com y security.ubuntu.com ocurrieron dentro de la misma ventana de 24 horas el 27 de febrero de 2026
- Durante el ataque, Canonical movió solo security.ubuntu.com y archive.ubuntu.com a Cloudflare, y en los registros públicos parece que lo que se desplazó fue una suscripción pagada en lugar de un rescate
La caída de Canonical y el cambio a Cloudflare
- El 30 de abril de 2026 a las 16:33:37 UTC, el sistema de monitoreo de Canonical marcó blog.ubuntu.com como Service Down y, en unos 10 minutos, también cayeron junto con él ubuntu.com, la API de avisos de seguridad, el portal para desarrolladores, el sitio corporativo y la plataforma educativa, entre otros servicios web públicos
- La interrupción duró unas 20 horas y quedó registrada como Service Restored el 1 de mayo de 2026 a las 12:44 UTC
- El grupo que se adjudicó el ataque se presentó como Islamic Cyber Resistance in Iraq o 313 Team, un grupo de tendencia proiraní, y dijo que había usado un servicio pago
- La herramienta de ataque señalada, Beamed, es un producto comercial de denegación de servicio vendido en varios TLD; beamed.su se usa como sitio de marketing y blog, y beamed.st como portal de acceso para clientes
- Una entrada del blog de Beamed de abril de 2026 anuncia “evasión de Cloudflare” y destaca tres técnicas, entre ellas la rotación de IP residenciales y la “endpoint hunting” manual para encontrar el servidor de origen
- Incluso una semana después del ataque, beamed.su y beamed.st seguían en línea, y ambos resolvían a direcciones de Cloudflare AS13335
- Los dos endpoints de repositorio de Canonical, security.ubuntu.com y archive.ubuntu.com, también pasaron después a usar direcciones de Cloudflare AS13335
Beamed y la infraestructura de registro y enrutamiento
- Los dominios de consumo de Beamed fueron registrados mediante un registrador llamado Immaterialism Limited, que vende registro de dominios con tarifa fija y API basada en JSON
- Immateriali.sm está proxificado mediante los nameservers de Cloudflare tani.ns.cloudflare.com y trey.ns.cloudflare.com
- Immaterialism Limited está registrada en el Companies House del Reino Unido con el número de empresa 15738452 y fue constituida el 24 de mayo de 2024
- Al momento de su constitución, la directora era Nicole Priscila Fernandez Chaves, de Costa Rica, y usaba una dirección de buzón masivo en Great Portland Street, Londres
- El 11 de abril de 2025, Fernandez Chaves dejó el cargo de directora, pero conservó más del 75% de interés económico, y en la misma dirección fue nombrada como directora sucesora Naomi Susan Colvin, residente en el Reino Unido
La reasignación de AS39287 del 27 de febrero de 2026
- El 26 de febrero de 2026, Immaterialism Limited presentó dos cambios el mismo día ante Companies House
- Cambió su oficina registrada de 85 Great Portland Street a 167-169 Great Portland Street
- Modificó los datos de person with significant control de Fernandez Chaves
- Al día siguiente, 27 de febrero de 2026, la infraestructura de enrutamiento que anunciaba el espacio IP de Beamed y servicios relacionados cambió de jurisdicción
- El sistema autónomo que anuncia el espacio de direcciones de Materialism es AS39287, y RIPE asignó ese número AS el 24 de enero de 2006
- La identidad de enrutamiento de AS39287 se mantuvo, pero los registros del operador y del país cambiaron dos veces
-
Etapa de Privactually Ltd y FLATTR-AS
- Aproximadamente entre 2017 y 2020, AS39287 perteneció a la empresa chipriota Privactually Ltd y operó bajo el nombre FLATTR-AS
- Flattr está vinculado al proyecto de micropagos de Peter Sunde Kolmosoppi, uno de los cofundadores de The Pirate Bay
- Bajo ese registro, el contacto de abuso de los prefijos era abuse@shelter.st
-
Etapa de ab stract ltd
- De 2020 a 2026, el mismo número AS fue reasignado a la empresa finlandesa ab stract ltd, ubicada en Urho Kekkosen katu 4-6E, Helsinki
- El objeto maintainer en los registros de RIPE era BKP-MNT, y la persona que figuraba en el registro era Peter Kolmisoppi, otro de los fundadores de The Pirate Bay
- Los nameservers autoritativos del dominio del operador abstract.fi eran los tres nameservers de Njalla: njalla.fo, njalla.no y njalla.in
- Njalla es un proxy de dominios privacy-as-a-service creado por Peter Sunde y operado a través de 1337 Services LLC en San Cristóbal y Nieves
-
Reasignación a Materialism s.r.l.
- El 27 de febrero de 2026 a las 12:11:48 UTC, RIPE registró una tercera reasignación y AS39287 pasó a ser propiedad de Materialism s.r.l., ubicada en Bulevardul Metalurgiei, Bucarest, Rumania
- La reasignación incluyó 45.158.116.0/22, 2001:67c:2354::/48 y 2a02:6f8::/32; este último prefijo IPv6 había sido asignado originalmente en agosto de 2008 bajo el régimen anterior
- Durante los tres periodos de transición, la configuración de peering se mantuvo y AS39287 siguió con la misma configuración de import/export con AS42708(Telia), AS37560(GTT), AS12552(GlobalConnect), AS34244(Voxility) y AS54990
- Las mismas rutas siguieron saliendo por las mismas redes upstream, y en los registros públicos lo único que cambió fue el nombre visible del operador
- En la lista de registradores de dominios acreditados de IANA, la base de clientes de Immateriali.sm incluye a 1337 Services LLC, la entidad comercial detrás de Njalla
La rotación de certificados de Canonical ocurrida el mismo día
- En los registros de transparencia de certificados de los endpoints de repositorio de Canonical aparecen varias entradas dentro de la misma ventana de 24 horas en la que ocurrió la reasignación de enrutamiento
- El 27 de febrero de 2026 a las 06:14:03 UTC, Let’s Encrypt emitió un nuevo certificado apex para archive.ubuntu.com
- Ese mismo día, a las 19:13:35 UTC, Let’s Encrypt emitió un nuevo certificado apex para security.ubuntu.com
- Antes de esta entrada, en los registros de transparencia de certificados de 2026 de security.ubuntu.com solo había certificados de mirrors regionales, y no aparece ningún certificado apex anterior en los registros visibles
- Ese mismo día, a las 22:14:03 UTC, se emitió un nuevo certificado para clouds.archive.ubuntu.com
- Durante los 9 días siguientes, el mismo patrón se repitió en azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com y wildcard-ec2.archive.ubuntu.com
- Cada uno de los nuevos certificados fue emitido para hostnames apex, no para mirrors regionales
- Un certificado de origen válido para un hostname apex se considera una condición previa para poner ese hostname detrás de una red de distribución de contenido
- La simultaneidad entre la reasignación de enrutamiento y la rotación de certificados de Canonical ocurridas el 27 de febrero de 2026 no queda explicada solo con los registros públicos
Cronología del ataque
- La cronología se basa en el registro minucioso por minuto de la caída que aparecía en la página status.canonical.com de Canonical, conservado en una captura publicada alrededor de las 22:52 UTC del 30 de abril en el hilo 81470 de Ubuntu Discourse
-
Los primeros 10 minutos: caída general de la web pública
- 16:33:37: blog.ubuntu.com aparece por primera vez como Down y queda registrado como Incident Start Time
- 16:34:10: canonical.com Down
- 16:34:45: academy.canonical.com Down
- 16:35:15: developer.ubuntu.com Down
- 16:35:22: maas.io Down
- 16:36:09: jaas.ai Down, Ubuntu Security API(CVEs) Down
- 16:37:13: Ubuntu Security API(Notices) Down
- 16:41:57: assets.ubuntu.com Down
- 16:43:25: ubuntu.com Down
- El feed de avisos de seguridad cayó dentro de los primeros 3 minutos desde el inicio, y el apex de marketing cayó en 10 minutos
- En ese momento, los hosts que aún no estaban siendo atacados eran security.ubuntu.com y archive.ubuntu.com; esos dos endpoints son los repositorios que podrían provocar fallas de
apt updateen todas las instalaciones de Ubuntu
-
Tres horas después, ataque a los endpoints de repositorio
- 19:34:38: security.ubuntu.com aparece por primera vez como Down
- 19:40:01: archive.ubuntu.com Down
- Los endpoints del repositorio entraron en falla aproximadamente 3 horas después de iniciado el ataque
- Desde las 19:40 UTC y durante los siguientes 70 minutos, ambos endpoints alternaron entre Down y Operational en el panel de estado
- El registro de estado anota durante ese periodo 5 cambios Down/Operational para security.ubuntu.com y 4 cambios para archive.ubuntu.com
- Este patrón coincide con un escenario donde se intentaron mitigaciones en origen, como limitación de tasa, filtrado regional o scrubbing de tráfico, pero fallaron bajo la carga sostenida anunciada de 3.5 Tbps
-
Estabilización después de las 20:50 UTC
- 20:50:29: archive.ubuntu.com Operational
- 20:51:13: security.ubuntu.com Operational
- Después de este intervalo de 44 segundos, en la captura que continúa hasta las 22:52 UTC ninguno de los dos hosts vuelve a aparecer como Down
- El flapping se detuvo y ambos endpoints se estabilizaron juntos con menos de un minuto de diferencia, 4 horas y 17 minutos después del inicio del ataque
- Al momento de redactar, security.ubuntu.com y archive.ubuntu.com resuelven a 104.20.28.246 y 172.66.152.176, direcciones operadas por Cloudflare en AS13335
- Otros hosts afectados, como ubuntu.com, canonical.com, launchpad.net, snapcraft.io y login.ubuntu.com, siguen resolviendo al espacio AS41231 de Canonical, 185.125.189.x y 185.125.190.x
- Los nameservers autoritativos de ubuntu.com siguen siendo ns1.canonical.com, ns2.canonical.com y ns3.canonical.com
Cambio selectivo a Cloudflare
- Canonical movió a Cloudflare solo los dos registros A de security.ubuntu.com y archive.ubuntu.com, que eran justo los objetivos del atacante para negar el acceso a los repositorios
- El resto de los servicios permanecieron en la infraestructura propia de Canonical y resistieron el ataque bajo las mitigaciones existentes
- Los hosts que no eran repositorios siguieron con flapping hasta el final de la captura y luego se recuperaron por una combinación de filtrado upstream y mitigación o cese del ataque
- El primer reconocimiento público de Canonical apareció el 1 de mayo a las 07:13 UTC, 10 horas después de que los endpoints de repositorio se estabilizaran detrás de Cloudflare
- La recuperación total de todos los componentes fue confirmada el 1 de mayo a las 12:44 UTC, aproximadamente 20 horas después del inicio del ataque
La estructura detrás de si fue “chantaje”
- En la ruta públicamente verificable no se ve ningún pago de rescate
- Tampoco aparece en los registros públicos un flujo de criptomonedas de esa magnitud
- No se publicó ninguna nota de exigencia y, si hubo negociación, probablemente ocurrió en privado
- Lo que sí se movió en los registros públicos fue una suscripción pagada
- Los dos endpoints más valiosos de Canonical, es decir, los repositorios capaces de provocar fallas globales en las actualizaciones automáticas de seguridad, pasaron a una relación de servicio con Cloudflare
- Al mismo tiempo, entre otros clientes actuales de Cloudflare figura el operador de booter que estaba atacando a Canonical
- Como Beamed siguió disponible para contratación y el tiempo de caída de la infraestructura de Canonical funcionó como si fuera una fecha límite, la estructura puede interpretarse como una transacción cerrada sin necesidad de una demanda pública separada
- El protector obtiene ingresos de ambos lados y, al mismo tiempo, en cada momento se mantiene formalmente neutral respecto al contenido y dentro del texto de sus términos de servicio
Comparación con el monopolio de las redes telegráficas de carreras
- En la década de 1930, el General News Bureau de Moses Annenberg vendía rápidamente resultados de carreras a bookmakers de todo Estados Unidos
- La comparación dice que los bookmakers suscritos sobrevivían, mientras que los que no se suscribían perdían la capacidad de fijar cuotas frente a competidores que sí estaban suscritos
- Los ingresos de Annenberg dependían del monopolio sobre la verificación de resultados de carreras, y ese monopolio hacía que los bookmakers informales dependieran de su wire para operar
- El gobierno federal rompió ese monopolio con una acusación fiscal en 1939, y los servicios de wire posteriores fueron perseguidos hasta la década de 1940
- Un reporte de 1942 sobre el alcalde LaGuardia dice que 9 personas fueron arrestadas en una redada contra un “wire service de un millón de dólares al año” para operadores de apuestas de carreras y poolroom bookmakers en Nueva York, Nueva Jersey, Westchester y Nassau County
- Hoy esto lleva a una crítica según la cual el mercado de protección DDoS ocupa una posición similar en su relación con el mercado booter
- Los ingresos de Cloudflare dependen de su posición para verificar si un servicio es alcanzable en la Internet pública, y cuando la misma empresa también es proveedora de hosting para un booter, los papeles de amenaza y protección quedan fusionados en una sola corriente de ingresos
El rastro que quedó en los registros públicos
- El rastro de este incidente quedó disperso entre varios registros y divulgaciones corporativas
- En Companies House están los documentos corporativos, en la base de datos de RIPE está la reasignación de enrutamiento, en los registros de transparencia de certificados están las fechas de rotación de certificados apex y en la página de estado de Canonical quedaron las horas en que cambiaron los registros
- El 27 de febrero de 2026 se completaron tres preparativos dentro de la misma ventana del calendario
- Materialism s.r.l. tomó posesión de AS39287 y del antiguo prefijo IPv6 asociado
- Immaterialism Limited presentó documentación ante Companies House
- Del lado de Canonical, los dos hostnames apex que más tarde serían movidos detrás de una red de distribución de contenido renovaron sus certificados de origen
- El intervalo de 4 horas entre el inicio del ataque y la aparición de direcciones de Cloudflare en los hostnames de repositorio de Canonical puede interpretarse como el tramo en el que se desplazó la decisión de compra
- El 30 de abril de 2026 a las 20:50:29 UTC, la nueva relación comercial se volvió visible públicamente
1 comentarios
Comentarios de Hacker News
Según entiendo, la expresión “alquilar capacidad de ataque de Cloudflare” es imprecisa
Es cierto que ese grupo alojó su sitio detrás de Cloudflare, pero no he visto que se afirme que la infraestructura de Cloudflare se haya usado para el ataque
Todo el texto parece mezclar alojar el sitio informativo operado por el atacante con alojar el ataque en sí
Tanto los sitios web como la infraestructura de control eran objetivos
La defensa contra DDoS la ofrecían empresas como Akamai, había que pedir cotización, solo estaba al alcance de grandes empresas y jamás permitían registro anónimo
Cloudflare cambió la industria al ofrecer defensa DDoS gratis para cualquiera, incluso para servicios de DDoS-for-hire, y al ya no poder sacarse entre sí de línea, la industria del DDoS pudo crecer de verdad
Y no parece ser por tráfico proxificado; al menos no viene el encabezado
CF-Connecting-IpNo sé si se usaron en este ataque, pero sí se usan en algunos ataques
Aun así, Cloudflare sigue siendo mucho menos molesto que casi cualquier otro proveedor de infraestructura
Tampoco sé si la lógica se sostiene bien
Hay muchos servidores de mando y control alojados en AWS y también muchas víctimas en AWS, pero de ahí no se sigue que AWS sea responsable o esté extorsionando, y en general diría que la respuesta es no
Cualquiera puede elegir algunos sitios que cree que no deberían poder usar el hosting de Cloudflare
El problema es que esa lista cambia según la persona
Cloudflare debería alojar cualquier cosa hasta recibir una orden legal válida
Si empieza a decidir con algún criterio ambiguo si el contenido de un sitio es “apropiado”, la gente con razón se va a enojar mucho
La afirmación de que “alquilan capacidad de ataque de Cloudflare” necesita pruebas, y hasta donde sé los atacantes no están usando realmente la infraestructura de Cloudflare para los ataques
Me desconcierta bastante lo distinta que es la tonalidad general de este texto frente a la de textos sobre Google
No estoy seguro de que Cloudflare sea un actor malicioso, pero creo que todos deberíamos actuar como si pudiera serlo
Si el servicio anunciado ataca explícitamente a Cloudflare, parecería una violación obvia bajo términos razonables
Y eso efectivamente aparece en los términos de Cloudflare
https://www.cloudflare.com/en-ca/website-terms/
En “7. PROHIBITED USES” dice que no se puede usar el sitio web o los servicios en línea de forma que dañe, desactive, sobrecargue, interfiera o perjudique los servidores o APIs de Cloudflare ni las redes conectadas, ni transmitir elementos destructivos como virus, gusanos o troyanos, ni intentar acceso no autorizado mediante hacking o minería de criptomonedas, entre otros
También dice que Cloudflare se reserva el derecho de bloquear en su Distributed Web Gateway contenido que, a su exclusivo criterio, considere ilegal, dañino o violatorio de sus términos, incluyendo distribución de malware, facilitación de phishing y otros abusos técnicos
Aunque bajaran el sitio informativo del atacante, lo moverían a GitHub Pages o a cualquiera de los muchos hostings gratuitos de sitios estáticos
Por lo que veo, no hay absolutamente ninguna prueba de que Cloudflare haya hecho posible el ataque en sí
No decidió mantenerse completamente al margen
La afirmación de no intervenir debe leerse como una aprobación implícita
Porque sabemos que sí expulsa a usuarios que le desagradan lo suficiente
Este tipo de textos parecen partir de la extraña creencia de que Cloudflare no responde a reportes de seguridad ni a órdenes legales
En mi experiencia, Cloudflare responde de manera adecuada y relativamente rápida en comparación con la industria en general
Podría actuar de forma más proactiva o poner más fricción en el proceso de alta, pero entiendo que no quiera jugar a ser la policía de Internet
No creo que para alojar contenido en Internet te deban exigir tarjeta de crédito, número telefónico y hasta copia de identificación
Si no lo hacían, las otras islas les cortaban la conexión
La aplicación de la ley era el último recurso, porque los tribunales no se mueven a la velocidad de Internet y, por la naturaleza transfronteriza de Internet, nadie quería regulación gubernamental impuesta desde arriba
Cloudflare usó capital de riesgo para regalar cosas caras y comprar cuota de mercado
Si haces que todas las tiendas de abarrotes se muden a tu isla, puedes operar una guarida de actividad criminal sin preocuparte de que otros te excluyan
Pregúntale a cualquiera que combata botnets, malware o fraudes en línea
Cuando llegas a un callejón sin salida de Cloudflare, simplemente tienes que rendirte
Ninguna autoridad va a tomar un caso de apenas 7,000 computadoras infectadas, y Cloudflare tampoco investigará ni actuará por su cuenta
Yo, de hecho, no lo hago
Les di evidencia suficiente para iniciar una investigación interna o contactar a su cliente abusivo, pero no lo hicieron
En un stresser, desde fuera lo único visible sería el panel de login
Tampoco es que estos sitios anuncien abiertamente lo que hacen
Cloudflare se posiciona como infraestructura
Es decir, considera que no es responsable del contenido que transporta
En condiciones normales, para proteger mi sistema de sistemas malos en Internet, puedo bloquear a nivel IP
Pero Cloudflare proxifica a nivel IP tanto sistemas buenos como malos y todo lo que hay entre medio
Normalmente puedes bloquear a nivel IP un sitio operado por una organización criminal, o contactar al
abuse@de la organización que aloja el contenido para denunciarlo o lograr que lo bloqueenCloudflare impide ambas cosas
Y cuando envías un reporte de abuso a Cloudflare, tampoco hay garantía de que no reenvíe literalmente tu información de contacto a la parte que denunciaste
En estos años ha ido cambiando su postura para parecer más responsable, pero el fondo sigue igual
Incluso si quieres mandar un reporte a
abuse@de un sistema escondido detrás de Cloudflare, no puedes estar seguro de que no se limitarán a reenviarlo sin más, sin que sepas a quién se lo entreganPublicación relacionada de la semana pasada:
“Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
https://news.ycombinator.com/item?id=48025001
No me gusta el papel de CF en el Internet moderno, pero este texto parece un paquete de especulaciones que intenta unir puntos sin más base que el hecho de que la renovación de certificados de Canonical y el cambio de empresa ocurrieron el mismo día
Aun así, hay una historia lateral que sí vale la pena mirar
Al parecer Njalla hizo recientemente una reestructuración silenciosa o un cambio de propiedad[1], y Njalla e immateriali.sm parecen ser entidades relacionadas[2]
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
Como dice el texto de forma muy concisa, Cloudflare protege gratis al atacante en el frente y le cobra a la víctima por la remediación
Los servicios de mitigación DDoS pueden verse como una especie de extorsión digital por protección, y eso crea un incentivo para dejar que los atacantes sigan atacando
Es como decir: “Internet es peligroso, así que págannos para proteger su sitio web de atacantes que usan nuestra capa gratuita”
Aun si no hubiera complicidad activa ni reparto de ganancias, no está claro de qué lado están los servicios de mitigación DDoS
Estoy de acuerdo con la crítica, pero Cloudflare no inventó el DDoS
Aunque Cloudflare desapareciera mágicamente mañana, los rastreadores de IA no se detendrían
¿Cuál es la alternativa? Espero que no sea un mundo en el que para navegar por Internet haya que subir una identificación emitida por el gobierno
Pero si queremos conservar el relativo anonimato y el carácter global de Internet, ¿cómo se logra eso?
La gente podría formar cooperativas para encargarse de la defensa, pero sería difícil operarlas como entidades de escala mundial
La defensa DDoS consiste sobre todo en tener capacidad excedente suficiente y filtrar, así que la inversión necesaria es considerable
Cloudflare, aunque no al 100%, en general no censura contenido presumiblemente legal que pasa por sus sistemas, como en el caso de The Daily Stormer[1], y no elige convertirse por cuenta propia en árbitro de la legalidad
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
Totalmente de acuerdo
Cloudflare protege a estafadores a gran escala y a nadie parece importarle
Ninguna de las tiendas falsas ni páginas de phishing detrás de Cloudflare que reporté a Cloudflare fue dada de baja
Ni una sola
Si una empresa gana miles de millones protegiendo a la gente, debería tomarse esto en serio
Por ejemplo, una demanda de menor cuantía del tipo “me defraudaron 20 dólares y solicito la información de pago del cliente entregada a Cloudflare, el banco emisor y el número de cuenta para identificar a quién reclamar daños” suena bastante razonable
Aún no he oído que alguien lo haya intentado, pero me gustaría ver el resultado si alguien lo hace
Creo que el estado actual es mucho mejor
Siempre pensé que la caída de Ubuntu ocurrió porque querían impedir que los servidores de ubuntu parchearan copy.fail, para que ese grupo de hackers pudiera explotar a tantos objetivos como fuera posible durante ese tiempo
modprobe(8)# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadPuede que haya procesos que usen esta función (
lsof | grep AF_ALG), pero según entiendo no se usa mucho, así que en la mayoría de los sistemas debería poder desactivarse sin problemasTodos los servidores apex deberían estar configurados con alta disponibilidad para mantener el balanceo de carga, así que los usuarios normales no notarían nada durante el parcheo de copy.fail
Nuestros usuarios tampoco notaron absolutamente nada cuando desplegamos el parche
Eso no se parece a una amenaza; se parece más a una extorsión
CF no hizo ninguna de las dos cosas
Con esa lógica, también se podría decir que los fabricantes de teclados son responsables de actos ilegales escritos con sus productos
Seguir prestando servicio a una organización que se usa para facilitar actividad criminal es muy distinto, y dar de baja a un cliente por actividad ilegal ni siquiera es algo polémico
Si recibes una bomba en un paquete de UPS, no es culpa de UPS
Pero si le avisaran a UPS que alguien está usando su servicio para enviar bombas a la gente, y aun así no hiciera nada, e incluso pareciera proteger al remitente de las bombas, ¿no tendría alguna responsabilidad?
En este escenario, el “fabricante de teclados” sería más bien el fabricante de routers del que Cloudflare compra equipos, no Cloudflare
En esta analogía, Cloudflare se parece más a un agregador de periódicos que distribuye tanto cosas repugnantes como comentarios normales
En una situación normal, puedes simplemente no leer el periódico repugnante y dejar que quien quiera leerlo lo decida por sí mismo
Pero en la situación de Cloudflare, todos los principales periódicos normales decidieron publicar su contenido a través de Cloudflare, y cuando junto con eso se publica algo problemático, en lugar de reclamarle al editor original hay que reclamarle a Cloudflare
Y además Cloudflare podría pasarles tu información a personas muy desagradables sin que lo sepas de antemano
¿Dónde se traza la línea?