Será que se a postagem alcançar 100 upvotes individuais de contas "credenciadas" ele faz um novo vídeo? Nem que seja "Members First" e depois liberar uma amostra grátis para os não membros.
Sei que é uma faca de dois gumes comentar esse tipo de ataque em público, pois revela certas características da defesa que o TabNews implementa. Em parte ajuda o inimigo que põe à prova o site como prêmio aparecer nos logs, mas também é uma troca de experiência única de uma comunidade tão próxima. Por exemplo, que tipo de requisição é recebida, como o site responde, qual conteúdo é solicitado na requisição etc.. Detalhes que poderiam revelar se é uma requisição feita por humanos ou por um robô.
Na vida real, na caixa de distribuição de energia elétrica, existem disjuntores que, quando uma alta corrente é consumida por determinado circuito (cada disjuntor protege um circuito, setores de tomadas e/ou outras cargas), o mesmo atua interrompendo o fornecimento de energia. A maioria desses dispositivos tem rearme manual, ou seja, o usuário tem que ir lá (na antiga caixa de fusíveis) e atuar fisicamente sobre o botão de rearme. Lembre-se de que corrente elétrica se define como ( i = dC/dt ), ou seja, quantidade de carga por unidade de tempo. Na mesma ideia, será que o Tabnews não consegue criar uma solução de proteção contra excesso de carga (picos) semelhante a um disjuntor? Desta maneira, impediria ultrapassar a quota mensal de requisições ou melhor, a quota diária/horária esperada. Por exemplo, se a média de requisições por minuto é 100, seria anormal atender 1000, banindo temporariamente (digamos que 30 minutos +/- um quantidade aleatória de minutos) todos os IPs incomuns no último minuto. Há alguns problemas com essa ideia no caso de promoções que indiquem o Tabnews, mas na vida real qualquer atividade pública para as massas requer aviso às autoridades para lidar com a demanda fora do normal. Contas identificadas (o usuário fez login) seriam banidas por mais tempo (7 dias) se um comportamento semelhante ocorresse. Na reincidência ocorreria a suspensão por maior tempo com registro do IP e outras características que ajudem a identificar o mesmo dispositivo impedindo-o criar novas contas durante um período. Algo mais complicado seria deixá-lo criar contas, mas todas seriam suspensas se inativas posteriormente. Um sistema de convite poderia criar um maior vínculo entre as contas, criando uma espécie de rede de nós interligados, todos com seus detalhes particulares que enviam para o servidor. Alguns servidores de email gratuitos estão banindo contas inativas por motivos de segurança (e eu acho que também por limpeza).
Não sei se é possível o Tabnews reunir uma lista de características de todos os tipos de clients que o acessou à cada semana. O servidor deve receber algo parecido como indico abaixo (sei que alguns detalhes são facilmente mutáveis), além do IP origem:
GET / HTTP/1.1
Host: localhost:8080
Connection: keep-alive
sec-ch-ua: "Kukoo Brome";v="1XY", "Not=A?Brand";v="Z", "Bromium";v="1XY"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "uLinux"
Upgrade-Insecure-Requests: 1
User-Agent: Godilla/7.0 (X22; uLinux x86_128) AppleWebKit/543.21 (KSHTML, like Turtle) Brome/1XY.0.1.2 Savana/543.21
Accept: text/html,application/xhtml+xml,application/xml;q=0.X,image/avif,image/webp,image/apng,*/*;q=0.Y,application/signed-exchange;v=bX;q=0.Z
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.X
