Wikipédia:Esplanada/propostas/Impor limite de edições a todos usuários (7fev2017)

Impor limite de edições a todos usuários (7fev2017)

Caros. Tivemos recentemente um pequeno incidente em que um usuário utilizou um script JavaScript para fazer uma série de modificações em massa. As edições não foram lesivas, mas chamaram a minha atenção sobre uma pequena brecha no sistema que eu sempre soube. E é sobre isso que quero falar agora.

Apesar dos limites que nossas regras impõem sobre o volume de edições que um usuário pode fazer por meio de ferramentas (3 edições por minuto para usuários; 6 edições por minuto para robôs), todas as ferramentas que temos disponíveis (Huggle, AWB, etc.) não há NADA que impeça que alguém desenvolva um programa que simplesmente ignore esses limites. O único limitador são as regras. Se um usuário violar, estará sujeito às nossas sanções. Mas sempre será possível que ele viole os limites.

Para deixar claro, vou descrever algumas situações em que simplesmente sancionar o usuário NÃO seria suficiente para reparar o dano:

Caso provável 1: Usuário descontrolado

Como pode ser visto na ocorrência, por meio de um script um usuário conseguiu realizar, quase que instantaneamente, exatas 216 edições. E esse não é o máximo de edições que se pode fazer com um script: a questão é que foram editadas apenas 216 páginas. Mas poderiam ser milhares de páginas, todas editadas de uma só vez. Poderia, inclusive, serem feitas por diversas contas diferentes, o que tornaria o processo de reversão ainda mais complexo. Imagine ter de reverter as edições de um script rodando a 30 minutos? Com uma taxa de 5000/edições por minuto, teríamos 150 mil páginas para reverter, uma-a-uma.

Caso provável 2: Robô descontrolado

Pior do que um usuário descontrolado, pode ocorrer de um robô se descontrolar. O impacto das edições dele seria o mesmo que um usuário qualquer, a diferença é que seria mais difícil de rastrear as edições, dado que as edições feitas por robôs não aparecem nas 'Mudanças Recentes'. Esse robô somente seria identificado quando ele editasse uma página vigiada por outro usuário e esse usuário, por sua vez, se manifestasse. Mas se o robô editar apenas as Páginas não vigiadas, ele passaria completamente despercebido e poderia operar por horas (para não dizer dias) editando sem ser percebido.

Caso hipotético: Armageddon!

Um burocrata mal intencionado poderia criar um programa que registra contas através de máquinas diferentes e com nomes aleatórios e os torna burocratas/administradores em massa. Em questão de segundos teríamos milhares de administradores e burocratas bloqueando todos os administradores e burocratas da Wikipédia e fazendo edições aleatórias, de todo o tipo, em massa. Embora fosse possível reverter todas as edições e bloquear todos os usuários, os Stewards não teriam condições de remover os privilégios de tantos usuários de forma tão rápida e a única solução para esse problema seria uma intervenção direta do time de engenharia da Wikimedia Foundation. A solução provavelmente seria parar o servidor da Wikipédia e restaurar o último backup.

Claro que não queremos pensar na possibilidade de qualquer uma dessas coisas acontecerem. Mas o motivo disso não ter acontecido é simples: por sorte, escrever um script é uma tarefas que poucos usuários detém conhecimento e, felizmente, esses poucos usuários tem mais coisas para fazer do que ficar bagunçando a casa dos outros.

Imagino que seja do interesse da comunidade impedir que isso aconteça. Fiquei esses dias pensando como isso poderia ser evitado/minimizado, sem causar impacto nas colaborações. Cheguei na conclusão que devemos impor um limitador nas edições de TODOS os usuários. Minha proposta é que limitemos o número de edições de todos usuários para 60 edições a cada 10 minutos.

Esse é um limite bastante alto, visto que seria o número de edições de um Bot, segundo nossas regras vigentes (=6 edições por minuto). Com isso, ainda será possível que um usuário viole as regras (isto é, edite acima de 3 edições por minuto), mas o intuito não é limitar as colaborações: é impedir que a brecha de segurança que descrevo aqui seja explorada. Lembro que já existe um limitador global, que impede que usuários IP e não confirmados editem mais que 8 páginas em 1 minuto (em qualquer wiki).

Aspectos técnicos da proposta
Essa configuração é possível, através da inclusão do código abaixo no InitialiseSettings.php (arquivo de inicialização da Wikipédia), ou seja, seria preciso abrir um ticket no Phabricator: # wgRateLimits @{ 'wgRateLimits' => [ // ... '+ptwiki' => [ 'edit' => [ 'user' => [ 60, 600 ], ], ], // ... ], # @} end of wgRateLimits

O que acham da proposta? Chamo atenção para alguns membros com conhecimentos técnicos no software da Wiki: @Alchimista, Danilo.mac, He7d3r, !Silent e Chicocvenancio:. --Diego Queiroz (discussão) 15h00min de 7 de fevereiro de 2017 (UTC)

Concordo acho importante e necessário minimizar as vulnerabilidades existentes (para mim isso é uma vulnerabilidade).

Fiquei com uma questão na cabeça, porém, qual o limite usado por outros projetos? Chico Venancio (discussão) 15h07min de 7 de fevereiro de 2017 (UTC)

Comentário Como usuário assíduo do Huggle, existe uma chance (ainda que relativamente baixa) de eu ter que reverter, durante 10 minutos, mais de 30 vandalismos (considerando que o Huggle reverte e avisa o usuário ao mesmo tempo, logo 30 edições + 30 avisos atingiria a cota proposta), então a principio isso poderia ser limitador para mim. Acho a questão pertinente, contudo penso que esse limite deveria ser superior. --Hume42 ✉ 15h15min de 7 de fevereiro de 2017 (UTC)

Hume42 a regra já afirma que isso vai contra as regras. Há algum caso recente em que isso realmente se aplicou? Chico Venancio (discussão) 15h18min de 7 de fevereiro de 2017 (UTC)

@Chicocvenancio: Realmente não sei dizer, apenas estou considerando uma situação hipotética, pois 3 reversões por minuto (dando 6 edições com os avisos) me parece razoável de acontecer, ainda que uma constante de edições nesse ritmo por 10 minutos nem tanto. Sobre ser contra as regras, nunca fui repreendido e por isso não sabia, mas suponho que não atrapalho ninguém com minhas reversões. --Hume42 ✉ 15h28min de 7 de fevereiro de 2017 (UTC)

Assim como o Hume42 falou, às vezes é necessário realizar muitas reversões em um minuto, mesmo sem o Huggle, que não uso. Um exemplo seria num ataque de sock puppets, como os do Vhaslhv. Mr. Fulano! ^{🔔Fale Comigo📩} 15h31min de 7 de fevereiro de 2017 (UTC)

Isto fez-me lembrar en:Don't delete the main page. Como é que essa restrição iria jogar com ferramentas como Especial:Nuke (mw:Extension:Nuke)? GoEThe (discussão) 15h52min de 7 de fevereiro de 2017 (UTC) Estou a ficar velho, porque não consigo encontrar onde nas regras fala dos limites de número de edições por minuto para usuários comuns. GoEThe (discussão) 16h03min de 7 de fevereiro de 2017 (UTC)

@Chicocvenancio: Por incrível que pareça, essa vulnerabilidade é global. As únicas limitações nesse sentido (aplicadas em todas as wikis) é o número de edições por um mesmo IP ou por um usuário não-confirmado. De resto, não há restrição... Também não sei dizer se há outras discussões sobre o assunto em outras wikis. --Diego Queiroz (discussão) 16h26min de 7 de fevereiro de 2017 (UTC)

@GoEThe: O Nuke faz deleção de páginas. Alem disso, na configuração da wiki existe uma permissão especial para o uso do nuke (permissão 'nuke' e 'delete' são distintas). A limitação que proponho é para a edição de páginas somente, pois penso que é o caso mais provável e danoso. Portanto creio que essa alteração não vai afetar o funcionamento do Nuke. Acredito, inclusive, que podemos propor um limite para a eliminação de páginas e que isso também não vai afetar o nuke. (mas esse último caso é preciso confirmar) --Diego Queiroz (discussão) 16h26min de 7 de fevereiro de 2017 (UTC)

Comentário As razões para justificar o pedido parecem ser remotas demais (quiça improvável) de acontecer. Pelo que vi, o único problema nas edições foi porque o Luan configurou mal os scripts do robô. Mas não acho que temos editores com conhecimento técnico (deu até pra mencionar todos ali) e ferramentas o suficiente para fazer edições massivas em tão pouco tempo para se justificar o limite. Talvez uma abordagem menos rígida Diego Queiroz seja uma alternativa, mas a meu ver, isso é conservador demais. Eta Carinae (discussão) 16h59min de 7 de fevereiro de 2017 (UTC)

Conservador? Eu ri. --Diego Queiroz (discussão) 18h08min de 7 de fevereiro de 2017 (UTC)

Acho que não tem um termo mais adequado para descrever isso do que o utilizado pelo Chico: Vulnerabilidade. Por acaso, eu trabalho com tecnologia e presencio isso o tempo todo. Falhas de segurança são combatidas, jamais ignoradas ou logo você vê o resultado. O simples fato de eu estar expondo elas aqui (pois já sei dessa possibilidade faz tempo), já torna elas mais prováveis de ocorrerem. A Wikipédia é um dos sites mais visitados do mundo. Já viu quantos sites menos importantes já foram invadidos por aí só porque é divertido? Já ouviu falar em Defacement? Existem grupos especializados em fazer isso. E, particularmente falando, explorar essa falha na Wikipédia é bastante trivial. jQuery/Javascript você aprende em algumas horas seguindo tutorial na internet... --Diego Queiroz (discussão) 18h16min de 7 de fevereiro de 2017 (UTC)

Discordo Por vários motivos:

1. O limite proposto é assustadoramente baixo. 60 edições em 10 minutos são 6 edições por minuto. Isso é facilmente atingível, por exemplo, quando depois de se editar um artigo é necessário criar/alterar/corrigir categorias, afluentes ou criar ligações internas.
2. O limite iria impedir o uso de ferramentas de combate o vandalismo e às ações de socks, como o mass rollback.
3. Se a vulnerabilidade realmente existe e é plausível, então esta discussão deveria estar a acontecer a nível dos desenvolvedores do software media wiki ou de todas as wikipédias, e não apenas a nível local. Quintal ✁ 19h25min de 7 de fevereiro de 2017 (UTC)

Respostas:

1. Reversão é uma coisa, edição é outra. Não confunda.
2. Mesmo que 6 edições no minimo fosse "plausível" (na verdade, não é), pense em 60 edições em 10 minutos. Você teria que manter um ritmo frenético de edições por 10 minutos para atingir isso e, mesmo assim, estaria editando mais rápido que qualquer bot atualmente configurado. Acha mesmo que faz frequentemente esse tipo de façanha? Mesmo que isso insista que é um limite baixo, ok, podemos discutir um limite maior. O ruim é não ter limite algum.
3. A nível de desenvolvedores já existe essa preocupação, tanto que eu coloquei o link: mw:Manual:Edit throttling. Lá já se discute os efeitos desejáveis e indesejáveis dessa limitação. O recurso já foi implantado no software e já está configurado a nível global, e algumas wikis tem suas personalizações, como esta que eu proponho aqui.
4. Se discorda, então, no mínimo, dê uma alternativa para evitar 216 edições em um minuto. Eu adoraria ouvir uma alternativa.

--Diego Queiroz (discussão) 19h49min de 7 de fevereiro de 2017 (UTC)

Mais um ponto que eu esqueci: usuários que se sintam afetados podem solicitar a permissão 'noratelimit'. Podemos, inclusive, associar essa permissão com a de algum tipo de usuário. (Ex.: 'sysop' recebe automaticamente 'noratelimit', por exemplo). --Diego Queiroz (discussão) 19h54min de 7 de fevereiro de 2017 (UTC)

@Diego Queiroz: Que tal ao invés de bloquear, ao ultrapassar esse limite, seja exigido que o usuário passe por um CAPTCHA? Com isso, seria impossível manter edições automatizadas acima do limite. Mr. Fulano! ^{🔔Fale Comigo📩} 21h33min de 7 de fevereiro de 2017 (UTC)

Não acredite em Captchas, eles são fáceis de contornar para aqueles que desejam. Chico Venancio (discussão) 22h13min de 7 de fevereiro de 2017 (UTC)

• Citação: Reversão é uma coisa, edição é outra. Não confunda. Não percebi. Uma reversão não é uma edição?
• Citação: Mesmo que 6 edições no minimo fosse "plausível" (na verdade, não é), pense em 60 edições em 10 minutos. Você teria que manter um ritmo frenético de edições por 10 minutos para atingir isso e, mesmo assim, estaria editando mais rápido que qualquer bot atualmente configurado. Acha mesmo que faz frequentemente esse tipo de façanha? 6 edições por minuto é um "ritmo frenético" e "não é plausível"? Pergunte a qualquer pessoa que edite categorias ou que crie afluentes. Pergunte a qualquer pessoa que use o mass rollback para reverter edições de socks.
• Citação: O recurso já foi implantado no software e já está configurado a nível global, e algumas wikis tem suas personalizações, como esta que eu proponho aqui. Então o limite já existe a nível global e isto é apenas uma personalização local? Isso não está nada claro na proposta. Qual é o limite global? Quintal ✁ 21h49min de 7 de fevereiro de 2017 (UTC)

As formas que essa vulnerabilidade podem ser explorada não se limitam aos cenários que o Diego desenhou. Eu pensaria em um cenário com usuários inocentes sendo alvos de programação maliciosa. Há pouco tempo alguém acessou a conta de um administrador na Wikien e fez alguns estragos. É por isso que ganhamos o recurso de autenticação em dois fatores. Agora imagina alguém que queria atuar de maneira a causar um estrago mas não consegue descobrir a senha de algum admin/burocrata/supressor/steward , basta desenhar um script que efetue ações em massa e enviar como extensões maliciosas para os usuários que possuem esses estatutos. Scripts desses, hoje podem editar milhares de páginas em instantes. O usuário só iria perceber quando o estrago estivesse feito. Chico Venancio (discussão) 22h13min de 7 de fevereiro de 2017 (UTC) ps: após o primeiro admin infectado é possível colocar o script para todos os usuários da Wikipédia ao mesmo tempo. Quanto mais analiso essa vulnerabilidade mais eu penso que impossível explicar o potencial de um ataque de negação de serviço através dela. Chico Venancio (discussão) 22h14min de 7 de fevereiro de 2017 (UTC)

Continuo sem perceber porque é que isso está a ser discutido aqui, a nível local na pt.wiki. Se há essa vulnerabilidade, ela deve ser exposta e discutida com os desenvolvedores e tomadas medidas a nível global. Quintal ✁ 22h37min de 7 de fevereiro de 2017 (UTC)

Comentário Também não percebi se o limite se aplica ou não a reversões, ou somente a edições.-- Darwin ^Ahoy! 22h51min de 7 de fevereiro de 2017 (UTC)

Discordo. Os motivos são exatamente os descritos pelo usuário Antero de Quintal, acima. Chamo a atenção para a utilização mass rollback, que facilmente pode ultrapassar este limite proposto quando empregado no combate a vandalismos em massa de sockpuppets. No mais, essa vulnerabilidade deve ser discutida globalmente, e não em uma wiki local, não cabendo, portanto, a discussão aqui. RadiX∞ 00h30min de 8 de fevereiro de 2017 (UTC)

Caros @Antero de Quintal, Darwinius e RadiX:. Vamos lá, vou explicar uma coisa. Para reverter edições, não é necessário ser reversor? E qual é a mágica aí? Porque é uma ação diferente, logo, precisa de uma permissão diferente. Uma ação 'edit' ocorre quando você clica em editar uma página e salva. Na prática, você envia um fluxo de dados com o conteúdo da nova página e ele substitui o antigo. Já a ação 'rollback' é um simples comando, o software wiki que faz a coisa toda. Não sei se é suficiente para vocês entenderem, mas em resumo são comandos distintos a nível de software: 'edit' e 'rollback'. --Diego Queiroz (discussão) 09h04min de 8 de fevereiro de 2017 (UTC)

@Antero de Quintal: Sobre os limites globais atualmente definidos, eles são os seguintes:

Limites atuais

Todas as wikis IP Mover: N/A Editar: 8 páginas por minuto Errar o captcha: 15 vezes por minuto Enviar a senha por e-mail: 5 e-mails por hora Enviar e-mail para outros usuários: 5 e-mails por dia Atualizar página (purge): 30 atualizações por minuto Atualizar listagens (link purge): 30 atualizações por minuto Renderizar arquivos (ex. gerar miniaturas): 700 renderizações a cada 30 segundos Renderizar arquivos não padrão: 70 renderizações a cada 30 segundos API cxsave: 10 salvamentos a cada 30 segundos Novos usuários (não confirmados) Mover: 2 páginas a cada 2 minutos Editar: 8 páginas por minuto Errar o captcha: 15 vezes por minuto Enviar a senha por e-mail: N/A Enviar e-mail para outros usuários: 5 e-mails por dia Reverter: 5 reversões a cada 2 minutos Atualizar página (purge): N/A Atualizar listagens (link purge): N/A Renderizar arquivo (ex. gerar miniaturas): N/A Renderizar arquivos não padrão: N/A API cxsave: N/A Todos usuários Mover: 8 páginas por minuto Editar: Não há limite Errar o captcha: 30 vezes por minuto Enviar a senha por e-mail: N/A Enviar e-mail para outros usuários: 20 e-mails por dia Reverter: 10 reversões por minuto Atualizar página (purge): 30 atualizações por minuto Atualizar listagens (link purge): 30 atualizações por minuto Renderizar arquivo (ex. gerar miniaturas): 700 renderizações a cada 30 segundos Renderizar arquivos não padrão: 70 renderizações a cada 30 segundos API cxsave: 10 salvamentos a cada 30 segundos Reversor Reverter: 100 reversões por minuto enwiki Movedor de páginas (na enwiki existe um tipo de usuário chamado "Page mover") Mover: 16 páginas por minuto dewiki Editores (na dewiki existe um tipo de usuário chamado "Editor") Reverter: 100 reversões por minutos Commons Todos os usuários Enviar arquivo: 380 arquivos a cada 72 minutos Revisor de imagens Enviar arquivo: 999 arquivos por minuto Patrulhador Enviar arquivo: 999 arquivos por minuto Autopatrulhado Enviar arquivo: 999 arquivos por minuto

--Diego Queiroz (discussão) 09h04min de 8 de fevereiro de 2017 (UTC)

@Mr. Fulano: Sobre a ideia do Captcha, ela até seria uma boa ideia, mas é uma ideia que não faz sentido para o problema em questão. Scripts editam páginas por meio da API. O script não visita a página como usuários fazem para poder visualizar um captcha. --Diego Queiroz (discussão) 09h15min de 8 de fevereiro de 2017 (UTC)

@Diego Queiroz: É essa a ideia, isso daria um limite nas edições semiautomáticas, pois se o editor quiser continuar a editar, teria que fazer as edições manualmente. Mr. Fulano! ^{🔔Fale Comigo📩} 13h25min de 8 de fevereiro de 2017 (UTC)

Bom, para quem pediu alternativas à proposta de "60 edições a cada 10 minutos". Basta manter a proporção de 6 edições por minuto (o que é relativamente fácil de ser conseguido, mas nem tanto de ser sustentado por vários minutos sucessivos). Então, a proposta pode ser "90 edições a cada 15 minutos" ou "120 edições a cada 20 minutos". Deixo ainda uma sugestão de período de testes para a restrição para que a comunidade se adapte e confirme (em x tempo) que essa restrição deve perdurar, caso haja consenso aqui. E me parece válido o questionamento sobre isso dever ser uma restrição de segurança (a ser discutida) em todos os projetos da Wikimedia. Luan (discussão) 13h46min de 8 de fevereiro de 2017 (UTC)

Estou satisfeito com a explicação de que isso não limitaria a criação e eliminação de páginas, nem reversões, nem afectaria grupos de usuários com excepção a essa limitação (admins e eliminadores neste momento) mas concordo que provavelmente isso poderia/deveria ser discutido a nível global. Até porque pode até já ter sido discutido e descartado. GoEThe (discussão) 14h33min de 8 de fevereiro de 2017 (UTC)

Comentário O termo "reversão" pode ter dois sentidos: 1) o sentido restrito à ferramenta rollback, acessível apenas a reversores; 2) um sentido amplo, que indica qualquer edição que consista em desfazer uma ou várias edições. Quando se mencionou "reversão" mais em cima, deve-se entender no sentido amplo, e não apenas as reversões do rollback. Assim, o limite proposto pode até nem afectar a ferramenta rollback, mas afetaria as reversões manuais, inclusive as que são feitas com scripts como o "Reversão e avisos" e "Mass Rollback". Quintal ✁ 15h25min de 8 de fevereiro de 2017 (UTC)

Mesmo que afete, podemos dar limites maiores (ou não limitar) usuários que possuem acesso a essas ferramentas. Isso não é um inviabilizador. --Diego Queiroz (discussão) 16h35min de 8 de fevereiro de 2017 (UTC)

Concordo com o proposto. Os usuários que estão contestando a quantidade (60 em dez minutos) alegando ser muito restritivo, poderiam dar exemplos de casos em que vocês ultrapassaram esse limite? Falou-se das reversões aos vandalismos e as categorizações, porém eu queria ver o link direto nas contribuições de vocês comprovando isso, somente pra ter mais ou menos uma dimensão da coisa e um consequente aumento desse valor, se for o caso. !Silent (discussão) 20h48min de 12 de fevereiro de 2017 (UTC)

Talvez dê para fazer uma consulta SQL no toollabs:quarry para encontrar situações em que os usuários ultrapassaram o limite proposto? Helder 10h24min de 13 de fevereiro de 2017 (UTC)

Acredito que daria também, porém, tenho pouca familiaridade com SQL e com o Quarry. !Silent (discussão) 11h28min de 13 de fevereiro de 2017 (UTC)

Parece que o Quarry está offline. Vou dar uma olhada se ainda tenho acesso ao ToolServer/Wikimedia Labs e monto uma consulta (e se ainda lembro como usa, haha). --Diego Queiroz (discussão) 13h54min de 14 de fevereiro de 2017 (UTC)

Consegui montar a consulta (espero que esteja certa). Usei o Antero nessa primeira execução, mas depois eu rodo com outros usuários (rodar na Wiki toda seria um pouco insano). Ela ficou um pouco pesada, então preferi não deixar várias consultas rodando ao mesmo tempo. Assim que tiver um resultado eu posto aqui. --Diego Queiroz (discussão) 17h18min de 14 de fevereiro de 2017 (UTC)

Pergunta: Essa limitação é por uma questão de desempenho (evitar que isso comprometa o funcionamento da Wikipédia) ou por outros motivos? Pergunto isso, pois vejo centenas de edições feitas no Commons em um minuto por alguns scripts (eu e alguns usuários daqui já usamos) e não há qualquer prejuízo nesse sentido. Os servidores do Commons provavelmente são mais "potentes" que os daqui, mas me pergunto se essa limitação realmente existe.—T_ele^s«fale comigo» 20h55min de 14 de fevereiro de 2017 (UTC)

Eu uso corriqueiramente o cat-a-lot na categorização do Commons, que é uma das ferramentas que faz centenas de edições por minuto, e nunca tive qualquer tipo de problema. É muito frequente se fazer essa quantidade de edições por minuto quando se está a adicionar categorias de datação, por exemplo.-- Darwin ^Ahoy! 21h01min de 14 de fevereiro de 2017 (UTC)

Teles a questão não é exatamente de desempenho das máquinas, os servidores da Wikimedia são capazes de lidar com um número de edições muito superior a o que estamos falando aqui, a questão é do desempenho humano que pode ser necessário para desfazer algum problema causado por um erro pequeno de script. Digo, não é difícil pensar em um script que resolva fazer alterações sutis em artigos, se ele faz isso a 6 edições por minuto é um problema contornável, bloqueia-se o(s) usuário(s) e se desfaz as ações. Se isso é feito a 500 ou 5000 edições por minuto vai ser um pouco mais complexo. Imagine o pesadelo que seria se conseguem colocar isso no common.js Chico Venancio (discussão) 21h04min de 14 de fevereiro de 2017 (UTC)

@Teles: Existe uma preocupação com desempenho, mas eu estou colocando como uma questão de segurança. É uma vulnerabilidade e acho que é questão de tempo que algum grupo hacker se interesse a fazer um belo estrago na Wiki, por meio da exploração da nossa capacidade de ação e reversão. Tem noção que seria possível bloquear, em um instante, todos os administradores/burocratas e até mesmo stewards? Se a senha de qualquer sysop vazar, eu consigo até fazer com que A SUA CONTA faça tudo isso sem você saber (editando essa ou essa página). Os exemplos vão da imaginação do atacante. Pretendo fazer um Request for comment no Meta sobre o assunto, mas ando sem tempo (demoro 5 vezes mais tempo para escrever um texto em inglês). E, de fato, o script que deu origem a essa discussão foi um script migrado do Commons (o tal de Cat-a-lot), mas não edito muito lá... --Diego Queiroz (discussão) 21h15min de 14 de fevereiro de 2017 (UTC)

Acho que o argumento sobre desempenho não deveria ser usado. O resto pode ser algo com que tenhamos que nos preocupar.—T_ele^s«fale comigo» 02h14min de 15 de fevereiro de 2017 (UTC)

Na verdade eu acho esta discussão toda um bocado rebuscada. Mas conheço um bicharoco que é realmente capaz de criar o caos nesta enciclopédia, bastando para isso que alguém mal intencionado atinja o nível de eliminador (se isso ainda não foi alterado), o que é bastante fácil. Há editores e bots com milhares de artigos criados, um nuke nesses, mesmo que o restauro fosse feito por script, levaria um bom tempo a consertar. Mesmo que a ferramenta seja limitada a administrador, o risco ainda seria bastante significativo, dado o cortejo de criaturas hoje infames e banidas do projecto que têm passado por esse cargo. E para usar isso não precisa saber scripts, nem rodar bots, nem o escambau, é só mesmo preencher campos e apertar um botão. Eu pessoalmente não vejo grande utilidade nesta ferramenta, pelo menos não vejo qualquer utilidade que justifique o risco. E não imagino, pelo menos nesta realidade em que vivo, que função possa ter uma coisa que dinamita milhares de artigos ao mesmo tempo, coisa absolutamente impossível de se criar em tempo útil sem se ser antes detectado pela vigilância do projecto. Numa discussão sobre o assunto, você opôs-se à remoção ou desactivação dessa ferramenta, Diego Queiroz. Ainda pensa o mesmo?-- Darwin ^Ahoy! 21h28min de 14 de fevereiro de 2017 (UTC)

@Darwinius: Na época eu não fui totalmente contra, apenas sugeri que fosse acessível apenas aos Administradores. Mas hoje eu penso que podíamos criar novos estatutos: como "Eliminador em massa", por exemplo (e outros equivalentes). Esse estatuto poderia conferir apenas a permissão de executar o nuke (na época, acho que não sabia dessa possibilidade). Além disso, acho que essa permissão deveria ser temporária, ou seja, seria atribuída quando fosse necessário executar o nuke e, logo em seguida, fosse removida. No entanto, por questão de segurança, não sou contra remover a permissão completamente, fiz uma pesquisa e notei que apenas ptwiki, jawiki, enwikiversity e wikidata permitem nuke: ou seja, quase nenhuma wiki. --Diego Queiroz (discussão) 00h58min de 15 de fevereiro de 2017 (UTC)

@Diego: A propósito, pode se interessar por este recurso: phab:T12493. Helder 10h45min de 15 de fevereiro de 2017 (UTC)

@He7d3r: Realmente muito legal essa proposta. Isso seria muito útil por aqui. --Diego Queiroz (discussão) 12h30min de 16 de fevereiro de 2017 (UTC)

Após tudo o que tem sido escrito aqui, eu tendo a discordar da proposta. O perigo não parece óbvio, e os danos colaterais parecem bastante significativos. No caso do nuke, após ver a discussão da Wiki-en sobre o assunto, em 2008, quando implementaram a ferramenta, e perceber que é a mesma ferramenta que eu uso no Commons, já estou mais descansado também.-- Darwin ^Ahoy! 05h02min de 15 de fevereiro de 2017 (UTC)

Discordo per Quintal. --Usien6 02h49min de 28 de fevereiro de 2017 (UTC)

Resultados

Resultado disponível:

Usuário: Antero de Quintal
- 03/12/2015, às 12:56 -> 97 edições em 10 minutos
- 16/04/2016, às 11:23 -> 165 edições em 10 minutos
- 19/04/2016, às 18:10 -> 70 edições em 10 minutos
- 29/05/2016, às 11:43 -> 91 edições em 10 minutos

Usando o Antero como exemplo de usuário ativo, de fato, desde que ele se registrou na Wikipédia, houve 4 situações em que ele fez mais de 60 edições no minuto. Vi que uma delas foi feita com a ferramenta de Reversão e Avisos, mas não analisei todas. O que acham? --Diego Queiroz (discussão) 19h18min de 14 de fevereiro de 2017 (UTC)

Na minha opinião, editar a essa taxa por meio de JavaScripts é exatamente o que proponho impedir (para os leigos: Reversão e Avisos é um JavaScript). Creio que a ferramenta de Reversão e Avisos pode (e deve!) ser ajustada para não efetuar edições nessa velocidade (assim não limitamos a funcionalidade da ferramenta). --Diego Queiroz (discussão) 19h18min de 14 de fevereiro de 2017 (UTC)

Eu acho que a ideia do CAPTCHA seria uma boa, pois seria praticamente impossível abrir o CAPTCHA num script e tecnicamente impossível de burlar automaticamente. E com isso evitaria o uso excessivo de scripts num curto período de tempo. E outra coisa, seria muito abuso se pedisse para fazer uma análise das minhas contribuições? É só por curiosidade. Mr. Fulano! ^{🔔Fale Comigo📩} 19h25min de 14 de fevereiro de 2017 (UTC)

Também gostaria da minha se possível, já que levantei a questão das reversões efetuadas por mim lá em cima. --Hume42 ✉ 19h32min de 14 de fevereiro de 2017 (UTC)

Acredito que podem colar a consulta no Quarry e trocar o nome do usuário. Helder 19h36min de 14 de fevereiro de 2017 (UTC)

"tecnicamente impossível de burlar"{{carece de fontes}} Isso já não é verdade há anos (exemplo)... Helder 19h36min de 14 de fevereiro de 2017 (UTC)

E em relação aqueles CAPTCHAS (se é que podemos chamar assim) que é necessário dar apenas um clique para verificar que não é um robô? Percebo que esse está sendo o mais usado ultimamente. --Hume42 ✉ 20h11min de 14 de fevereiro de 2017 (UTC)

@Hume42: O serviço é hospedado fora dos servidores da Wikimedia, e o seu uso não estaria de acordo com a política de privacidade, além de criar uma dependência externa indesejável (ver phab:T38585#418770, phab:T129936#2120451). Helder 20h27min de 14 de fevereiro de 2017 (UTC)

Além das fraquezas do CAPTCHA específico, há serviços pagos (e alguns gratuitos) para resolver Captchas. Ele não é uma solução. Chico Venancio (discussão) 20h36min de 14 de fevereiro de 2017 (UTC)

@Chicocvenancio: Sinceramente, não vejo nenhum outro modo de se evitar esses problemas além do limitador de edições, apesar que este também pode ser facilmente burlado… Mr. Fulano! ^{🔔Fale Comigo📩} 20h44min de 14 de fevereiro de 2017 (UTC)

Mr. Fulano como o limitador pode ser burlado? Chico Venancio (discussão) 20h49min de 14 de fevereiro de 2017 (UTC)

┌─────────────────────────┘ Chicocvenancio Primeiro, esse limitador só bloqueia edições, então é possível mover, apagar, suprimir entre tantas outras funções. E como foi sugerido, talvez seja possível criar uma permissão de se poder ultrapassar o limite. Então os usuários com essa permissão poderia ter sua conta invadida e pode ser feita essas operações. Isso são só algumas hipóteses. Não digo outras pois pode dar ideia aos vândalos. Mr. Fulano! ^{🔔Fale Comigo📩} 21h02min de 14 de fevereiro de 2017 (UTC)

Há algumas questões aí, primeiramente, as outras ações são muito mais fáceis de desfazer automaticamente (verificar o log e desfazer tudo de tal a tal hora) do que edições, que teríamos que separar o joio do trigo.

Criar permissões para ultrapassar o limite seria um "buraco" que nós estaríamos criando no limite, podemos não criar e mesmo que criemos é muito mais fácil observar os usuários que estiverem nessas exceções do que todos. Chico Venancio (discussão) 21h07min de 14 de fevereiro de 2017 (UTC)

@He7d3r: pelo menos aqui esse quarry não parece estar a funcionar direito, não consigo abrir nenhuma new query lá.-- Darwin ^Ahoy! 20h05min de 14 de fevereiro de 2017 (UTC)

@Darwinius: Conseguiu fazer o login normalmente? Verifique se o SQL Quarry está listado entre os aplicativos que conectou à sua conta. Helder 20h10min de 14 de fevereiro de 2017 (UTC)

@He7d3r: Não, quando eu tento fazer login dá: "502 Bad Gateway". No botão de login da extrema direita superior também dá erro. :\ -- Darwin ^Ahoy! 20h14min de 14 de fevereiro de 2017 (UTC)

Mesma coisa aqui. --Hume42 ✉ 20h15min de 14 de fevereiro de 2017 (UTC)

O mesmo também. Mr. Fulano! ^{🔔Fale Comigo📩} 20h17min de 14 de fevereiro de 2017 (UTC)

O Quarry está offline. @Hume42:, deixei o servidor do ToolLabs rodando o seu relatório. --Diego Queiroz (discussão) 20h19min de 14 de fevereiro de 2017 (UTC)

Outro ponto é que essa consulta demorou 3 horas para ser processada. O Quarry não ia dar conta de rodar (ele não permite consultas muito demoradas). --Diego Queiroz (discussão) 20h21min de 14 de fevereiro de 2017 (UTC)

Aqui está normal. Helder 20h27min de 14 de fevereiro de 2017 (UTC)

@Diego Queiroz Não creio que o problema esteja necessariamente no Reversão e Avisos. Mas o que você sugeriria que fosse feito com ele? !Silent (discussão) 20h31min de 14 de fevereiro de 2017 (UTC)

@!Silent: Não acho que ele é o problema. O problema é a possibilidade de editar em massa. Quando um usuário executa uma edição em massa por meio de um script automatizador, ele está agindo mais rápido que um robô, sem ser um robô. Esses scripts permitem que usuários excedam todos os limites de edições. Por conta disso, minha ideia seria:

1. incluir um limitador no número de edições (isso automaticamente faria o reversão e avisos bugar, já que ele não limita o número de edições);
2. alterar o reversão e avisos (e similares) para aplicar um throttle nas edições, para editarem sempre abaixo do limite (assim como o Pywikibot e tantos outros já fazem, seria um sleep da vida no meio do código).

Claro que a falta do (1) não impede o (2). ;) --Diego Queiroz (discussão) 20h40min de 14 de fevereiro de 2017 (UTC)

E com isso só seria possível reverter três edições e avisar três vezes por minuto com o RA? Não sei se isso é um boa ideia... !Silent (discussão) 20h44min de 14 de fevereiro de 2017 (UTC)

É mais ou menos isso, mas aí eu diria que é assunto para outra conversa. A política de robôs não permite que robôs editem mais rápido do que 6 epm (até pode 12 epm, se for urgente) e, mesmo assim, precisa de autorização e o funcionamento é acompanhado e homologado por outros usuários. Usuários via AWB editam a 3 epm, e precisam de autorização para usar. Dado isso, porque usuários sem autorização nenhuma podem ter limites superiores? Não faz sentido algum. Podemos até aumentar esses limites, mas independente disso, eu vejo os JavaScripts (e qualquer outro meio de edição automatizada) como um meio de burlar essa política (e não estou falando só dos gadgets, qualquer usuário pode colocar um JavaScript para rodar aqui, seja pelo common.js pessoal ou via um plugin como o GreaseMonkey). Agora se acha que a possibilidade de editar a essa velocidade não deixa a Wikipédia vulnerável, ok, mas eu discordo. --Diego Queiroz (discussão) 20h58min de 14 de fevereiro de 2017 (UTC)

• A restrição ao limite de edições não tornaria, de fato, a Wikipédia menos "vulnerável". Um vândalo poderia facilmente contornar essa limitação utilizando várias contas de ataque, ou articulando um ataque coordenado. Por outro lado, isto acarretaria problemas ao uso de scripts como este (js), que permitem a reversão em massa e a marcação das reversões como edições de robô (para administradores). O script também é muito utilizado por quem não tem o direito rollback para combater vandalismo e também atingir os requisitos necessários para obter a flag de reversor global. Acredito que os supostos ganhos em segurança não compensariam os transtornos ocasionados. Tenho quase certeza de que esta proposta não passaria numa RfC. Portanto, mantenho a mesma posição desde o início da discussão: Discordo. RadiX∞ 00h58min de 15 de fevereiro de 2017 (UTC)

"(...) poderia facilmente contornar (...). Primeiro, acho que você deveria pesar o seu "facilmente", não é nada fácil. E mesmo que concorde que isso é possível, o atacante teria que criar novas contas: novas contas tem limites muito baixos definidos globalmente. Usuários IP, limites menores ainda. Até a criação de contas tem limitações altas: não se pode criar várias contas de um mesmo local. Além disso, o software Mediawiki já possui proteções contra o acesso por meio de proxies abertos e a partir de Tor Exit Nodes (Veja mw:Extension:TorBlock e meta:Steward requests/Global), o que dificultaria muito a vida do atacante. Com a limitação que estou propondo, o ataque ficaria praticamente inviável. --Diego Queiroz (discussão) 01h15min de 15 de fevereiro de 2017 (UTC)

Você incluiu ligações para mw:Extension:TorBlock e meta:Steward requests/Global, a página na qual mais atendo a pedidos no Meta-Wiki (bloqueios de faixas associadas a webhosting services, leaky colo, etc), como se eu não compreendesse do que se trata um HTTP proxy, web proxy, ou serviço de anonimização. Não, não dificultaria a vida do "atacante", nem tornaria o ataque "inviável", justamente pela natureza de atuação desses vândalos. Talvez se você conhecesse o modus operandi dos LTAs, ou mesmo acompanhasse os problemas que temos enfrentado apenas localmente, nesta wiki, certamente iria repensar o termo "praticamente inviável". LTAs engendram os ataques, criam e mantém diversos sleepers, justamente para burlar as editrates impostas pelo MediaWiki a usuários não-confirmados. A partir daí, com as contas criadas, tanto faz se o vândalo utilizar de proxies para editar. E tanto faz se você reduzir o limite de edições de 8 para 2 por minuto, sobretudo quando temos um ataque coordenado, no qual mais de dois ou três LTAs combinam as ações entre si, em tempo real, utilizando as contas dormentes (que não são criadas a partir do mesmo IP, nem no mesmo ínterim). A única coisa que "ficaria praticamente inviável" é o trabalho do vandal fighter. Inviável e desmerecido. RadiX∞ 01h56min de 15 de fevereiro de 2017 (UTC)

RadiX, a questão é que hoje não precisam de proxys para causar danos massivos. Uma conta que possa editar sem limite de edit rate tem um impacto potencial algumas ordens de grandeza acima de contas limitadas. A questão é que hoje quase todas as contas não possuem limite. Cada IP adicional que um vândalo tiver que adicionar, de fato cada aba a mais que ele tenha que abrir, diminui o impacto da vulnerabilidade e criar o limite de edição vai nesse sentido. Chico Venancio (discussão) 02h05min de 15 de fevereiro de 2017 (UTC)

@Chicocvenancio: Diminuiu muito pouco, na verdade. Prefiro não escrever aqui tudo o que eles podem fazer para burlar essas restrições. Mas pode ter certeza de que muitos deles sabem até mais do que eu ou você. ;) RadiX∞ 02h26min de 15 de fevereiro de 2017 (UTC)

Estou Neutro em relação a esta regulamentação. Porque isso vai muito do bom senso do editor. Se ele sabe que o uso não autorizado ou arriscado de uma ferramenta pode ativar a vulnerabilidade do sistema, a pessoa tem que ter o bom senso de procurar usar de maneira minuciosa ou até mesmo não usar. Outra coisa, basta olhar minhas contribuições em Janeiro e verão que eu já fiz de 4 a 5 edições por minuto. Existem reversores como eu e outros usuários que possuem alta velocidade no raciocínio e gostam de reverter vários vandalismos ao mesmo tempo para agilizar o trabalho, como é o meu caso. Além disso, acho esta medida meio intervencionista nas edições dos usuários, afinal, se as edições são benéficas para o projeto e se estamos numa Enciclopédia livre, é meio contraditório uma medida dessas.

Por outro lado, um certo "amigo" nosso sustentava aos seus socks por meio de edições em massa que consistiam em adições de categorias por meio do HotCat, de forma semelhante ao robô, mas para obter direito ao voto e manipular votações. Creio que uma regulamentação dessas edições, apesar de intervencionista, pode ser benéfica para dificultar a ação de redes de sock puppets e manipulação de votos. E eu tive uma experiência com muitos vândalos na Wikia que faziam edições em massa inúteis para ganhar medalhas e mérito, e acabaram banidos por tempo indeterminado.

Enfim, a proposta é boa para reduzir a ação de trolls sistemáticos, spambots e fantocheiros, mas por outro lado, pode atrapalhar as ações de editores de bem, de reversores, ou até mesmo atrapalhar projetos. Por isso minha opinião é neutra em relação a esse assunto.

(saindo um pouco do assunto, confesso que levei um susto na parte do "caso hipotético")

Armagedon2000 ^msg 02h12min de 15 de fevereiro de 2017 (UTC) Fiz esta query que mostra os que tiveram mais edições em um minuto nos últimos 30 dias. ^Danilo.mac_(discussão) 15h02min de 15 de fevereiro de 2017 (UTC)

Apesar da medida ser interessante para evitar uma avalanche de edições desenfreadas que abusam da quantidade de edições por minuto, existem muitos usuários que em algum momento acabam extrapolando esse limite, de forma não intencional, revertendo vandalismos por exemplo ou fazendo edições sistemáticas. Essa limitação poderia ser facilmente contornada por um vândalo, e a restrição não deixaria a wiki menos vulnerável, podendo prejudicar ainda outros editores. ♪ Alberto79 ♪ ^{Msg-Contributions} 16h50min de 16 de fevereiro de 2017 (UTC)

Request for comment

Caso alguém queira participar, eis a discussão iniciada no Meta: meta:Requests for comment/Throttle edits made by all users. --Diego Queiroz (discussão) 02h06min de 15 de fevereiro de 2017 (UTC)