Alguém pode explicar se a Cloudflare chantageou a Canonical?
(flyingpenguin.com)- Os serviços web públicos da Canonical ficaram fora do ar por cerca de 20 horas a partir de 30 de abril de 2026 às 16:33 UTC, e os endpoints do repositório Ubuntu entraram em falha mais tarde
- Um grupo alinhado ao Irã que reivindicou a responsabilidade pelo ataque disse ter usado o serviço pago de DDoS Beamed, que anuncia bypass de Cloudflare e rotação de IPs residenciais
- O domínio do Beamed e a infraestrutura associada de registro e roteamento levam a registros de Cloudflare AS13335, Immaterialism, AS39287 e Materialism s.r.l.
- A reatribuição do AS39287 e a renovação dos certificados apex de archive.ubuntu.com e security.ubuntu.com da Canonical ocorreram dentro das mesmas 24 horas em 27 de fevereiro de 2026
- Durante o ataque, a Canonical moveu para a Cloudflare apenas security.ubuntu.com e archive.ubuntu.com, o que, pelos registros públicos, resultou numa migração de assinatura paga em vez de resgate
Falha da Canonical e migração para a Cloudflare
- Em 30 de abril de 2026 às 16:33:37 UTC, o sistema de monitoramento da Canonical marcou blog.ubuntu.com como Service Down, e dentro de cerca de 10 minutos outros serviços web públicos, como ubuntu.com, a API de alertas de segurança, o portal de desenvolvedores, o site corporativo e a plataforma educacional, também saíram do ar
- A interrupção durou cerca de 20 horas e foi registrada como Service Restored em 1º de maio de 2026 às 12:44 UTC
- O grupo que reivindicou a autoria do ataque se apresentou como Islamic Cyber Resistance in Iraq ou 313 Team, um grupo alinhado ao Irã, e afirmou ter usado um serviço pago
- O Beamed, apontado como ferramenta do ataque, é um produto comercial de negação de serviço vendido em vários TLDs; o beamed.su é usado como site de marketing e blog, e o beamed.st como portal de login de clientes
- Uma postagem do blog do Beamed em abril de 2026 anunciava “bypass de Cloudflare” e apresentava três técnicas, incluindo rotação de IPs residenciais e “endpoint hunting” manual para encontrar o servidor de origem
- Mesmo uma semana após o ataque, beamed.su e beamed.st continuavam online, e ambos resolviam para endereços Cloudflare AS13335
- Os dois endpoints de repositório da Canonical, security.ubuntu.com e archive.ubuntu.com, também passaram a usar endereços Cloudflare AS13335 depois disso
Beamed e a infraestrutura de registro e roteamento
- Os domínios voltados ao consumidor do Beamed foram registrados por meio da registradora Immaterialism Limited, que vende registro de domínios com taxa fixa e API JSON
- O Immateriali.sm é proxyado por meio dos nameservers da Cloudflare tani.ns.cloudflare.com e trey.ns.cloudflare.com
- A Immaterialism Limited foi registrada na Companies House do Reino Unido com o número da empresa 15738452 e foi constituída em 24 de maio de 2024
- No momento da constituição, a diretora era Nicole Priscila Fernandez Chaves, da Costa Rica, e foi usado um endereço de caixa postal em massa na Great Portland Street, em Londres
- Em 11 de abril de 2025, Fernandez Chaves deixou o cargo de diretora, mas manteve mais de 75% de interesse econômico, e Naomi Susan Colvin, residente no Reino Unido, foi nomeada diretora sucessora no mesmo endereço
A reatribuição do AS39287 em 27 de fevereiro de 2026
- Em 26 de fevereiro de 2026, a Immaterialism Limited apresentou duas alterações à Companies House no mesmo dia
- Mudou o escritório registrado de 85 Great Portland Street para 167-169 Great Portland Street
- Alterou os detalhes de person with significant control de Fernandez Chaves
- No dia seguinte, 27 de fevereiro de 2026, a infraestrutura de roteamento que anunciava o espaço de IP dos serviços ligados ao Beamed mudou de jurisdição
- O sistema autônomo que anuncia o espaço de endereços da Materialism é o AS39287, e o RIPE atribuiu esse número de AS em 24 de janeiro de 2006
- A identidade de roteamento do AS39287 foi mantida, mas os registros de operador e país mudaram duas vezes
-
Período de Privactually Ltd e FLATTR-AS
- Aproximadamente de 2017 até 2020, o AS39287 foi mantido pela empresa cipriota Privactually Ltd e operado sob o nome FLATTR-AS
- O Flattr está ligado ao projeto de micropagamentos de Peter Sunde Kolmosoppi, um dos cofundadores do The Pirate Bay
- Sob esse registro, o contato de abuse dos prefixos era abuse@shelter.st
-
Período da ab stract ltd
- De 2020 a 2026, o mesmo número de AS foi reatribuído para a empresa finlandesa ab stract ltd, localizada em Urho Kekkosen katu 4-6E, Helsinque
- O objeto maintainer nos registros do RIPE era BKP-MNT, e a pessoa listada nos registros era Peter Kolmisoppi, outro fundador do The Pirate Bay
- Os nameservers autoritativos do domínio do operador abstract.fi eram os três nameservers Njalla njalla.fo, njalla.no e njalla.in
- A Njalla é um proxy de domínios privacy-as-a-service criado por Peter Sunde e operado por meio da 1337 Services LLC em São Cristóvão e Nevis
-
Reatribuição para Materialism s.r.l.
- Em 27 de fevereiro de 2026 às 12:11:48 UTC, o RIPE registrou a terceira reatribuição, e o AS39287 passou a pertencer à Materialism s.r.l., localizada na Bulevardul Metalurgiei, em Bucareste, Romênia
- A reatribuição incluiu 45.158.116.0/22, 2001:67c:2354::/48 e 2a02:6f8::/32; o último prefixo IPv6 havia sido atribuído pela primeira vez em agosto de 2008 sob o regime anterior
- Durante todos os três períodos de transição, a configuração de peering foi mantida, e o AS39287 continuou com o mesmo import/export para AS42708 (Telia), AS37560 (GTT), AS12552 (GlobalConnect), AS34244 (Voxility) e AS54990
- As mesmas rotas continuaram saindo pelas mesmas redes upstream, e o que mudou nos registros públicos foi apenas o nome visível do operador
- A lista de registradores de domínio credenciados da IANA inclui na base de clientes do Immateriali.sm a 1337 Services LLC, entidade comercial por trás da Njalla
A rotação de certificados da Canonical no mesmo dia
- Os registros de transparência de certificados dos endpoints de repositório da Canonical mostram várias entradas dentro da mesma janela de 24 horas em que ocorreu a reatribuição de roteamento
- Em 27 de fevereiro de 2026 às 06:14:03 UTC, a Let’s Encrypt emitiu um novo certificado apex para archive.ubuntu.com
- No mesmo dia, às 19:13:35 UTC, a Let’s Encrypt emitiu um novo certificado apex para security.ubuntu.com
- Nos registros de transparência de certificados de 2026 de security.ubuntu.com, antes dessa entrada havia apenas certificados de mirrors regionais, e nenhum certificado apex anterior aparece nos logs visíveis
- No mesmo dia, às 22:14:03 UTC, foi emitido um novo certificado para clouds.archive.ubuntu.com
- Nos 9 dias seguintes, o mesmo padrão se repetiu em azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com e wildcard-ec2.archive.ubuntu.com
- Cada novo certificado foi emitido para o hostname apex, não para um mirror regional
- Um certificado de origem válido para um hostname apex é tratado como pré-requisito para colocar esse hostname atrás de uma rede de distribuição de conteúdo
- A simultaneidade entre a reatribuição de roteamento de 27 de fevereiro de 2026 e a rotação de certificados da Canonical não é explicada apenas pelos registros públicos
Linha do tempo do ataque
- A linha do tempo se baseia no log de incidentes minuto a minuto que estava na página status.canonical.com da Canonical, preservado em um snapshot por volta de 22:52 UTC de 30 de abril na thread Ubuntu Discourse 81470
-
Primeiros 10 minutos: falha generalizada da web pública
- 16:33:37: blog.ubuntu.com é marcado pela primeira vez como Down e 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
- O feed de alertas de segurança caiu dentro de 3 minutos do início, e o apex de marketing caiu dentro de 10 minutos
- Nesse momento, os hosts ainda não atacados eram security.ubuntu.com e archive.ubuntu.com, os dois endpoints de repositório que podem fazer
apt updatefalhar em todas as instalações Ubuntu
-
Três horas depois, ataque aos endpoints do repositório
- 19:34:38: security.ubuntu.com é marcado pela primeira vez como Down
- 19:40:01: archive.ubuntu.com Down
- Os endpoints de repositório entraram em falha cerca de 3 horas após o início do ataque
- De 19:40 UTC pelos 70 minutos seguintes, os dois endpoints alternaram entre Down e Operational no painel de status
- O log de status registra nesse período 5 transições de Down/Operational para security.ubuntu.com e 4 transições para archive.ubuntu.com
- Esse padrão combina com tentativas de mitigação na origem, como rate limiting, filtro regional ou scrubbing de tráfego, que teriam falhado sob a carga sustentada anunciada de 3,5 Tbps
-
Estabilização após 20:50 UTC
- 20:50:29: archive.ubuntu.com Operational
- 20:51:13: security.ubuntu.com Operational
- Após esse intervalo de 44 segundos, os dois hosts não voltam a aparecer como Down no snapshot capturado até 22:52 UTC
- O flapping parou, e os dois endpoints se estabilizaram juntos com menos de 1 minuto de diferença 4 horas e 17 minutos após o início do ataque
- No momento da redação, security.ubuntu.com e archive.ubuntu.com resolvem para 104.20.28.246 e 172.66.152.176, endereços operados pela Cloudflare no AS13335
- Outros hosts afetados, como ubuntu.com, canonical.com, launchpad.net, snapcraft.io e login.ubuntu.com, ainda resolvem para os espaços AS41231 da Canonical em 185.125.189.x e 185.125.190.x
- Os nameservers autoritativos de ubuntu.com continuam sendo ns1.canonical.com, ns2.canonical.com e ns3.canonical.com
Migração seletiva para a Cloudflare
- A Canonical entregou à Cloudflare apenas os dois registros A, security.ubuntu.com e archive.ubuntu.com, que os atacantes haviam visado para interromper os repositórios
- Os demais serviços permaneceram na infraestrutura própria da Canonical e resistiram ao ataque sob as mitig ações existentes
- Os hosts que não eram de repositório continuaram em flapping até o fim do snapshot, e depois se recuperaram por uma combinação de filtragem upstream, mitigação do ataque ou interrupção do ataque
- O primeiro reconhecimento público da Canonical foi publicado em 1º de maio às 07:13 UTC, 10 horas após os endpoints do repositório terem se estabilizado atrás da Cloudflare
- A recuperação total de todos os componentes foi confirmada em 1º de maio às 12:44 UTC, cerca de 20 horas após o início do ataque
A estrutura por trás da questão da “chantagem”
- Na rota verificável publicamente, não houve movimentação de pagamento de resgate
- Nenhum fluxo de criptomoeda nessa escala aparece nos registros públicos
- Nenhuma carta de exigência foi divulgada, e, se houve negociação, é provável que tenha ocorrido em privado
- O que se moveu nos registros públicos foi uma assinatura paga
- Os dois endpoints mais valiosos da Canonical, os endpoints de repositório que poderiam provocar falha global nas atualizações automáticas de segurança, passaram a uma relação de serviço com a Cloudflare
- Ao mesmo tempo, entre outros clientes atuais da Cloudflare estava o operador de booter que atacava a Canonical
- Como o Beamed continuou disponível para contratação e o tempo de indisponibilidade da infraestrutura da Canonical funcionou como um prazo, a estrutura pode ser interpretada como uma transação concluída sem uma exigência pública separada
- O protetor lucra dos dois lados, ao mesmo tempo em que, em cada momento, permanece neutro em relação ao conteúdo e dentro da letra dos termos de serviço
Comparação com o monopólio das redes telegráficas de corridas de cavalos
- Nos anos 1930, o General News Bureau de Moses Annenberg vendia rapidamente resultados de hipódromos a bookmakers em todos os Estados Unidos
- A comparação feita é que os bookmakers que assinavam sobreviviam, enquanto os que não assinavam perdiam a capacidade de definir odds por causa dos concorrentes assinantes
- O lucro de Annenberg dependia de um monopólio sobre a verificação dos resultados das corridas, e esse monopólio fazia os bookmakers informais dependerem do seu wire para operar
- O governo federal quebrou esse monopólio em 1939 com uma acusação tributária, e os serviços de wire subsequentes foram reprimidos ao longo dos anos 1940
- Uma reportagem de 1942 relacionada ao prefeito LaGuardia diz que 9 pessoas foram presas em uma operação contra um “wire service de 1 milhão de dólares por ano” para operadores de apostas em corridas e poolroom bookmakers de Nova York, Nova Jersey, Westchester e Nassau County
- A crítica é que o mercado atual de proteção contra DDoS ocupa posição semelhante em sua relação com o mercado de booter
- O lucro da Cloudflare depende de sua posição para verificar se um serviço está acessível na internet pública, e quando a mesma empresa também é provedora de hospedagem de um booter, os papéis de ameaça e proteção se unem em um único fluxo de receita
Os rastros que ficaram nos registros públicos
- Os rastros desse incidente permanecem espalhados por vários registros e divulgações corporativas
- A Companies House contém os documentos corporativos, o banco de dados do RIPE mostra a reatribuição de roteamento, os logs de transparência de certificados mostram a data da rotação dos certificados apex e a página de status da Canonical registra quando os registros mudaram
- Em 27 de fevereiro de 2026, três preparações foram concluídas dentro da mesma janela de calendário
- A Materialism s.r.l. assumiu a posse do AS39287 e do antigo prefixo IPv6 associado
- A Immaterialism Limited apresentou documentos à Companies House
- Do lado da Canonical, os dois hostnames apex que depois seriam movidos para trás de uma rede de distribuição de conteúdo renovaram seus certificados de origem
- O intervalo de 4 horas entre o início do ataque e o momento em que endereços Cloudflare apareceram nos hostnames de repositório da Canonical pode ser interpretado como o período em que a decisão de compra se deslocou
- Em 30 de abril de 2026 às 20:50:29 UTC, a nova relação comercial tornou-se visível publicamente
1 comentários
Opiniões no Hacker News
Pelo que entendo, a expressão "alugar capacidade de ataque da Cloudflare" é imprecisa
É verdade que esse grupo hospedou o site atrás da Cloudflare, mas nunca vi alguém afirmar que a infraestrutura da Cloudflare foi usada no ataque
O texto todo parece misturar hospedar o site informativo operado pelos atacantes com hospedar o ataque em si
Tudo virava alvo, fosse site ou infraestrutura de controle
A defesa contra DDoS era oferecida por empresas como a Akamai, o preço era sob consulta, só grandes corporações conseguiam contratar e cadastro anônimo era totalmente impossível
A Cloudflare mudou o setor ao oferecer proteção contra DDoS grátis para qualquer um, inclusive serviços de DDoS-for-hire, e quando eles já não podiam mais se tirar do ar uns aos outros, a indústria do DDoS pôde realmente crescer
Também não parece ser tráfego proxied, já que pelo menos não há cabeçalho
CF-Connecting-IpNão sei se foi usado neste ataque, mas é usado em alguns ataques
Ainda assim, a Cloudflare continua sendo bem menos incômoda do que quase todos os outros provedores de infraestrutura
Nem sei se a lógica se sustenta muito bem
Também há muitos servidores de comando e controle hospedados na AWS e muitas vítimas da AWS, mas ainda assim é difícil dizer que a AWS seria responsável ou estaria chantageando alguém, e eu diria que em geral a resposta é não
Qualquer pessoa consegue escolher alguns sites que acha que a Cloudflare não deveria hospedar
O problema é que a lista é diferente para cada um
A Cloudflare deve hospedar qualquer coisa até receber uma ordem legal
Se começar a julgar se o conteúdo de um site é “adequado” com base em algum critério vago, as pessoas terão toda razão em ficar muito bravas
A alegação de "alugar capacidade de ataque da Cloudflare" precisa ter base, e pelo que sei os atacantes não estão usando a infraestrutura da Cloudflare no ataque em si
Fico bem desconcertado com a diferença enorme entre o tom geral deste texto e o tom de textos sobre o Google
Não sei se a Cloudflare é um agente malicioso, mas acho que todos deveriam agir como se fosse
Se o serviço anunciado ataca explicitamente a Cloudflare, isso obviamente pareceria violar qualquer termo razoável
E os próprios termos da Cloudflare dizem isso
https://www.cloudflare.com/en-ca/website-terms/
Em “7. PROHIBITED USES”, diz que você não pode usar o site ou os serviços online de forma que possa danificar, desabilitar, sobrecarregar, interromper ou prejudicar servidores, APIs ou redes conectadas da Cloudflare, nem transmitir itens destrutivos como vírus, worms ou cavalos de Troia, nem tentar acesso não autorizado por meio de hacking ou mineração de criptomoedas
Também diz que a Cloudflare se reserva o direito de bloquear no Distributed Web Gateway conteúdos que, a seu exclusivo critério, sejam ilegais, nocivos ou violem os termos, inclusive distribuição de malware, facilitação de phishing e outros abusos técnicos
Mesmo que tirasse do ar o site informativo dos atacantes, eles poderiam migrar para GitHub Pages ou um dos muitos hostings gratuitos de site estático
Para mim, não há absolutamente nenhuma evidência de que a Cloudflare tenha viabilizado o ataque em si
Ela não decidiu ficar totalmente de fora
A alegação de não intervenção deve ser lida como aprovação implícita
Porque sabemos que ela realmente expulsa usuários de quem não gosta o bastante
Esses textos parecem partir da crença estranha de que a Cloudflare não responde a denúncias de segurança ou ordens legais
Pela minha experiência, a Cloudflare responde de forma apropriada e relativamente rápida em comparação com o restante do setor
Ela poderia agir de forma mais proativa ou colocar mais atrito no processo de cadastro, mas faz sentido não querer bancar a polícia da internet
Não acho que para hospedar conteúdo na internet alguém deva ser obrigado a apresentar cartão de crédito, número de telefone e até cópia de documento
Caso contrário, as outras ilhas cortavam a conexão com ela
A aplicação da lei era o último recurso, porque os tribunais não se movem na velocidade da internet e, como a internet é transnacional, ninguém queria regulação governamental vinda de cima
A Cloudflare usou capital de risco para oferecer de graça coisas que eram caras e comprou participação de mercado
Quando você faz todos os supermercados se mudarem para a sua ilha, pode operar um antro de atividade criminosa sem se preocupar em ser excluído pelos outros
Pergunte a quem combate botnets, malware e fraudes online
Quando você chega a um beco sem saída da Cloudflare, só resta desistir
Nenhuma autoridade policial vai assumir um caso com apenas 7.000 computadores infectados, e a Cloudflare também não investiga nem toma providências por conta própria
Eu, de fato, não faço isso
Mas eu forneci evidência suficiente para iniciar uma investigação interna ou entrar em contato com o cliente abusivo, e mesmo assim não fizeram isso
Num stresser, o único elemento visível externamente provavelmente seria o painel de login
Esses sites também não anunciam publicamente o que fazem
A Cloudflare se posiciona como infraestrutura
Ou seja, entende que não é responsável pelo conteúdo que transporta
Em circunstâncias normais, para proteger meu sistema dos sistemas ruins da internet, eu posso bloquear na camada de IP
Mas a Cloudflare faz proxy na camada de IP tanto de sistemas bons quanto de ruins e de tudo no meio
Normalmente, dá para bloquear em nível de IP sites operados por grupos criminosos ou contatar o
abuse@da organização que hospeda o conteúdo para pedir bloqueio ou denúnciaA Cloudflare impede ambas as coisas
E ao enviar uma denúncia de abuso para a Cloudflare, nem há garantia de que ela não repassará minhas informações de contato exatamente para a parte que denunciei
Ela mudou a postura ao longo dos anos para parecer mais responsável, mas o núcleo da questão continua o mesmo
Mesmo que eu quisesse enviar uma denúncia
abuse@para os sistemas escondidos atrás da Cloudflare, não dá para ter certeza de que ela simplesmente não encaminhará isso sem que eu saiba para quem foi enviadoTexto relacionado da semana passada:
“Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
https://news.ycombinator.com/item?id=48025001
Eu não gosto do papel da CF na internet moderna, mas este texto parece um amontoado de especulações tentando ligar pontos sem base, além do fato de a renovação do certificado da Canonical e a mudança de empresa terem ocorrido no mesmo dia
Ainda assim, há um fio secundário que vale observar
Aparentemente a Njalla fez recentemente uma reorganização silenciosa ou mudança de propriedade[1], e Njalla e immateriali.sm parecem ser entidades corporativas relacionadas[2]
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
Como o texto diz de forma bem sucinta, a Cloudflare protege gratuitamente os atacantes na borda e cobra das vítimas pelo custo da mitigação
Serviços de mitigação de DDoS podem ser vistos como uma forma de extorsão de proteção digital, criando incentivo para deixar que os atacantes continuem atacando
É como dizer: “A internet é perigosa, então pague para protegermos seu site dos atacantes que usam nossa camada gratuita”
Mesmo que não haja conluio ativo nem divisão de receitas, não está claro de que lado os serviços de mitigação de DDoS estão
Concordo com a crítica, mas a Cloudflare não inventou o DDoS
Mesmo que a Cloudflare desaparecesse magicamente amanhã, os crawlers de IA não parariam
Qual seria a alternativa? Imagino que não seja um mundo em que você tenha que enviar um documento oficial para poder navegar na internet, certo?
Mas como fazer isso preservando o anonimato relativo e a natureza global da internet?
As pessoas até poderiam formar cooperativas para cuidar da defesa, mas seria difícil operá-las como uma entidade de escala mundial
A mitigação de DDoS depende principalmente de ter capacidade excedente suficiente e filtrar o tráfego, então o investimento necessário é considerável
A Cloudflare, embora não em 100% dos casos, como no episódio do The Daily Stormer[1], em geral opta por não censurar conteúdo presumivelmente legal que passa por seus sistemas e não escolhe para si o papel de árbitro da legalidade
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
Concordo totalmente
A Cloudflare protege golpistas em escala gigantesca e ninguém liga
As lojas falsas que denunciei à Cloudflare, as páginas de phishing atrás da Cloudflare, nenhuma delas foi derrubada
Nenhuma mesmo
Se é uma empresa que ganha bilhões protegendo pessoas, deveria tratar isso com seriedade
Por exemplo, uma ação de pequenas causas dizendo algo como “sofri um prejuízo de 20 dólares e solicito as informações de pagamento do cliente fornecidas à Cloudflare, banco emissor e número da conta, para identificar a parte contra a qual pedirei indenização” parece uma ideia bastante razoável
Ainda não ouvi falar de ninguém que tenha tentado isso, mas gostaria de ver o resultado se alguém fizer
Acho que o estado atual é muito melhor
Sempre achei que a queda do Ubuntu aconteceu porque o grupo de hackers queria impedir que os servidores do ubuntu aplicassem o patch de copy.fail, para explorar o máximo possível de alvos nesse intervalo
modprobe(8)# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadPode haver processos usando esse recurso (
lsof | grep AF_ALG), mas pelo que entendo ele não é amplamente usado, então na grande maioria dos sistemas desativá-lo não deve causar problemaTodos os servidores apex devem estar configurados com alta disponibilidade para manter o balanceamento de carga, então usuários normais não perceberiam nada durante a aplicação do patch de copy.fail
Nossos usuários também não perceberam absolutamente nada quando distribuímos o patch
Isso não se parece com chantagem, e sim mais com extorsão
A CF não fez nenhuma das duas coisas
Por essa lógica, também daria para dizer que fabricantes de teclado são responsáveis por atos ilegais escritos com seus produtos
Continuar prestando serviço a uma organização usada para apoiar atividade criminosa é algo bem diferente, e cancelar um cliente por atividade ilegal não deveria nem ser controverso
Se você recebe uma bomba por encomenda da UPS, a culpa não é da UPS
Mas se alguém avisou à UPS que uma pessoa está usando a empresa para mandar bombas a outras e, mesmo assim, ela não faz nada e ainda parece proteger o remetente das bombas, aí ela não passa a ter alguma responsabilidade?
Nesse cenário, o “fabricante de teclado” seria mais comparável ao fabricante do roteador de quem a Cloudflare compra equipamento, e não à própria Cloudflare
Nessa analogia, a Cloudflare está mais para um agregador de jornais que distribui ao mesmo tempo coisas imundas e comentários normais
Numa situação comum, você pode simplesmente não ler os jornais imundos e deixar que quem quiser ler decida por conta própria
Mas no caso da Cloudflare, os principais jornais normais decidiram todos publicar seu conteúdo via Cloudflare, e quando conteúdo problemático é publicado junto, em vez de cobrar o editor original você acaba tendo de cobrar a Cloudflare
Só que a Cloudflare pode repassar suas informações a pessoas muito desagradáveis sem que você saiba de antemão
Onde exatamente traçar a linha?