Políticas de uso aceitável

Scraping: o que muda quando uma página exige login?

Suponha que uma empresa colete preços no site de um fornecedor. Alguns preços são visíveis para todos; os preços de atacado aparecem depois que a empresa entra em sua conta de cliente. Para a empresa, esse é um único projeto de monitoramento de preços. Para uma AUP restrita a dados públicos, as duas partes ficam em lados opostos do uso permitido: o login válido do próprio cliente não remove a restrição do provedor.

Uma política que permite acesso autorizado a dados não públicos admite uma avaliação diferente. A pergunta relevante passa a ser se o cliente tem permissão para a própria coleta. Permissão para visualizar uma página de conta, exportar seu conteúdo e redistribuir os dados resultantes são questões separadas. Uma assinatura que permite a um funcionário ler material não autoriza necessariamente um programa a copiá-lo e revendê-lo.

Outras cláusulas tratam de como a coleta é executada. AUPs publicadas exigem expressamente o cumprimento das instruções do robots.txt, dos limites de API e dos limites técnicos de frequência do destino. Sob uma cláusula assim, distribuir solicitações por muitos IPs não torna, por si só, aceitável uma coleta proibida. O cliente concordou com essa condição ao comprar o serviço de proxy; isso não é uma afirmação de que toda instrução de robots.txt seja uma lei.

O conteúdo das páginas também importa. Preços públicos de produtos e dados pessoais de contato visíveis publicamente são dados diferentes. As AUPs podem exigir uma base legal para a coleta de dados pessoais e condições mais rigorosas para informações médicas, dados de crianças ou rastreamento de pessoas identificáveis. As restrições também podem abranger publicação posterior ou treinamento de IA. Baixar uma página com sucesso não resolve nenhuma dessas questões de uso posterior.

A automação é avaliada pelo que faz

“Scraper”, “robô” e “ferramenta de redes sociais” descrevem um software, mas dizem pouco sobre seu comportamento. A mesma automação de navegador pode inspecionar um anúncio ou produzir um clique pago artificial. AUPs publicadas diferenciam as atividades a seguir; oferecer suporte à tarefa da coluna esquerda não implica permitir a ação da direita.

A mesma distinção explica por que uma regra contra spam pode se aplicar mesmo quando as portas de e-mail estão bloqueadas. Mensagens podem ser enviadas por formulários, comentários ou interfaces de mensagens privadas de um site. Fechar uma porta SMTP impede uma forma de envio de e-mail; não interrompe toda forma de mensagem não solicitada.

Formas mais diretas de abuso incluem força bruta, que tenta possíveis senhas, e credential stuffing, que testa pares roubados de login e senha. As políticas também proíbem phishing, verificação de cartões roubados, distribuição de malware, ataques DDoS e conteúdo ilegal, incluindo exploração de crianças e violação de direitos autorais. Essas proibições dizem respeito à própria atividade: um pequeno número de tentativas pode violar a AUP mesmo com consumo quase nulo de tráfego.

Restrições que vão além de ataques e fraude

As AUPs também contêm exclusões comerciais. Listas efetivamente publicadas incluem pesquisas remuneradas, comércio de itens de jogos, domínios relacionados a streaming, negociação de criptomoedas, jogos de azar e conteúdo adulto. Esses são exemplos de regras de serviços diferentes, não uma proibição comum a todo o setor. Um provedor pode excluir uma atividade comercial sem afirmar que toda ocorrência dela é criminosa.

A revenda é outra restrição concreta. Vender a clientes acesso a credenciais de proxy alugadas pode exigir um acordo separado ou ser proibido pelo contrato padrão. O recurso de subusuários de um painel não resolve a questão: credenciais separadas podem ser destinadas à própria equipe de um cliente. Uma agência que usa proxies para preparar relatórios e uma empresa que vende o próprio acesso aos proxies oferecem serviços diferentes.

Algumas condições protegem o próprio pool de proxies. Elas proíbem fornecer informações obtidas sobre seus endereços e nós a bancos de dados que detectam proxies, avaliam a reputação de IPs ou bloqueiam tráfego. Por exemplo, alugar acesso para catalogar os IPs usados pelo provedor para acessar sites e fornecê-los a um banco de dados de detecção de proxies pode violar uma cláusula assim mesmo que nenhum site de destino tenha sido atacado. A restrição protege o valor comercial da rede.

Essas cláusulas explicam por que a AUP não pode ser reduzida a uma lista de crimes. Elas podem decidir se um modelo de negócio legal é compatível com um determinado serviço. Uma mudança de pesquisa interna para revenda, ou de coleta de preços públicos para criação de um conjunto de dados sobre pessoas, pode alterar a avaliação contratual mesmo que o mesmo programa e as mesmas configurações de proxy sejam usados.

Testar seu próprio site ainda pode exigir aprovação

Uma empresa contrata um prestador para examinar seu site em busca de vulnerabilidades. A empresa pode autorizar o teste, mas não controla a rede de proxies do prestador. Regras publicadas de proxies incluem uma exigência explícita de consentimento por escrito do provedor antes de varreduras de vulnerabilidades ou de testes de estresse e carga. Portanto, a permissão do dono do site nem sempre completa a aprovação necessária para a tarefa.

A rede que transporta o teste também enfrenta o tráfego e as reclamações resultantes. Uma varredura pode alcançar sistemas fora do alvo acordado; um teste de carga pode afetar hospedagem compartilhada ou serviços de proteção. Quando um provedor permite esses testes, o acordo sobre alvos, métodos e período identifica qual tráfego ele concordou em transportar. Uma descrição geral como “pesquisa de segurança” não estabelece esse escopo.

Como a atividade por um proxy se torna uma reclamação por abuso

Um destino vê o IP usado pelo proxy. Se seu operador observa ataques a senhas ou uma varredura de rede, as evidências inicialmente identificam esse endereço. A reclamação pode ir ao provedor de proxies ou à empresa de hospedagem que fornece o endereço e o servidor. No segundo caso, o vendedor de proxies recebe a questão de seu próprio fornecedor.

A documentação publicada de hospedagem mostra o que essas evidências podem conter. Um registro de varredura de rede lista o horário, o IP de origem, o IP de destino e a porta de destino. Conexões repetidas de uma origem à porta 22 em servidores diferentes, por exemplo, podem ser relatadas como uma varredura de serviços SSH. Já um relatório de inundação de tráfego pode conter taxas de pacotes e um resumo do tráfego por destino. Esses registros descrevem incidentes diferentes e exigem explicações diferentes.

O provedor precisa então associar o evento externo à atividade do cliente. Com um endereço dedicado, a atribuição pode ajudar; com IPs de proxy compartilhados ou rotativos, o endereço sozinho pode ser insuficiente. Os clientes podem usar o mesmo IP em horários diferentes ou simultaneamente. O horário exato, seu fuso horário e, quando disponíveis e relevantes, as portas de origem ajudam a distinguir as conexões. Isso depende dos registros efetivamente mantidos pela rede.

O horário em que uma reclamação chega também é diferente do horário da atividade que ela descreve. Uma tarefa ociosa quando o suporte escreve ao cliente pode ter gerado o tráfego relatado antes. É por isso que verificar apenas a lista atual de processos ou se o proxy funciona agora não responde à reclamação.

Esse processo não exige que um provedor de proxies leia cada página HTTPS. Com TLS comum de ponta a ponta por um túnel de proxy, os caminhos das páginas, as senhas enviadas e o conteúdo das respostas são criptografados. Um destino pode fornecer evidências do seu lado, enquanto um provedor ou uma empresa de hospedagem dispõe das informações de rede às quais tem acesso. Um navegador gerenciado ou uma API de scraping que efetivamente processa páginas tem outro papel e outra visibilidade.

Por que um destino pode parar de funcionar enquanto outros continuam carregando

A aplicação das regras nem sempre desativa uma conta. Um procedimento publicado de tratamento de reclamações permite restringir temporariamente apenas o site ou host indicado em uma reclamação. O restante do tráfego pode continuar. Nessa situação, um verificador de proxies pode informar uma conexão funcional mesmo que a principal tarefa do cliente não consiga alcançar seu destino.

Também há regras preventivas. Alguns serviços monitoram a frequência de solicitações a destinos sensíveis, como páginas de login de bancos, e aplicam restrições adicionais quando a atividade se torna excessiva. Assim, uma categoria pode ser acessível no uso normal sem estar disponível para solicitações automatizadas irrestritas. Esses são controles de destino, não necessariamente uma franquia mensal de tráfego.

A AUP e o uso justo podem se sobrepor aqui, mas o motivo da intervenção continua importante. Um coletor de preços pode sobrecarregar um recurso compartilhado enquanto executa uma tarefa permitida. Ataques a senhas podem violar a AUP com um volume muito menor. Comprar mais tráfego resolve o primeiro problema apenas se alterar a capacidade relevante; não autoriza a segunda atividade.

Uma empresa de hospedagem que fornece a infraestrutura pode impor uma restrição mais ampla. As regras de hospedagem descrevem bloqueios de um IP individual, de vários endereços ou de um servidor inteiro após ataques e varreduras. Um vendedor de proxies que usa essa infraestrutura pode precisar resolver o incidente com a empresa de hospedagem antes de o acesso voltar. Substituir um IP de proxy e continuar com a mesma atividade mantém a causa do problema.

Também não há uma sequência universal de avisos. Algumas políticas descrevem tentativas de resolver um problema com o cliente e, ao mesmo tempo, reservam a possibilidade de suspensão após uma primeira infração. Os sistemas de conta publicados também diferenciam uma reclamação por abuso, uma violação detectada da AUP e um problema de fraude de pagamento. O cliente precisa conhecer o motivo declarado e o escopo da restrição; a palavra “suspenso”, sozinha, não fornece essa informação.

Se um prestador ou outro usuário enviou o tráfego

As credenciais de proxy podem estar instaladas em várias aplicações ou ser entregues a uma agência. As condições do provedor podem tornar o titular da conta responsável pela atividade realizada por esse acesso. A relação do provedor é com o cliente que comprou o serviço; portanto, explicar que um prestador executou o programa não resolve, por si só, o incidente.

A tarefa prática é identificar qual aplicação ou pessoa usou as credenciais no horário relatado e interromper a atividade relevante. Se o acesso vazou, as credenciais expostas precisam ser revogadas ou alteradas. Credenciais separadas e registros das tarefas, quando o serviço permite, podem facilitar esse trabalho. Eles não criam uma exceção à AUP.

As restrições da conta também podem abranger tentativas de contornar as regras do próprio provedor: abrir contas substitutas após um banimento, solicitar testes repetidos contra as condições declaradas ou evitar a verificação de identidade. Uma conta nova ou um IP recém-atribuído não transforma a mesma operação proibida em uma operação aprovada.

O que acontece com o pacote pago e seu saldo

Há várias consequências financeiras possíveis, e elas devem ser mantidas distintas. Uma é uma taxa pelo trabalho envolvido no tratamento de uma reclamação. Outra é a perda do direito ao serviço não utilizado quando um contrato é encerrado por uma violação. Uma terceira é a obrigação de cobrir determinadas reivindicações de terceiros ou despesas causadas pela conduta do cliente. O valor pago pelo pacote de proxies não limita necessariamente todas essas obrigações.

Essas são diferenças contratuais reais. Condições publicadas incluem a perda de créditos não utilizados após o encerramento por violação, mas preveem tratamento diferente quando o provedor encerra o serviço por sua própria conveniência. Algumas também afirmam que uma suspensão por conformidade não estende automaticamente a assinatura nem a validade dos créditos. Portanto, uma conta ociosa não significa necessariamente que seu prazo pago esteja pausado.

Uma taxa de tratamento de reclamações não tem um valor padrão para todo o setor. Pagá-la cobre a cobrança estabelecida no acordo; não compra permissão para continuar uma atividade proibida nem garante o restabelecimento. Por outro lado, a chegada de uma reclamação, sozinha, não estabelece todas as consequências financeiras. Os fundamentos relevantes para restrição ou encerramento e as disposições de pagamento aplicáveis determinam o resultado contratual, respeitados os direitos legais obrigatórios.

O que enviar quando o suporte entrar em contato

O suporte precisa de uma resposta sobre a atividade descrita na reclamação. “O proxy funciona”, “o pacote está pago” e “só fazemos scraping” não identificam o que gerou as conexões relatadas. Uma resposta útil relaciona o evento à tarefa real do cliente e explica o que foi feito.

1. Pause a tarefa afetada e preserve suas configurações e os logs disponíveis. Use o horário da atividade relatada, incluindo seu fuso horário, em vez do horário em que você recebeu a mensagem.
2. Identifique a aplicação, a tarefa agendada, o funcionário ou o prestador que usa o acesso. Compare o destino e o IP do proxy com seus registros. Solicite os detalhes que faltam pelo canal de suporte do provedor.
3. Descreva a causa e a mudança feita: por exemplo, a tarefa foi interrompida, um destino não pretendido foi removido ou um acesso exposto foi revogado. Para um teste previamente acordado, inclua a permissão por escrito e seu escopo.
4. Confirme qual restrição permanece e o que o provedor exige antes que o trabalho permitido possa ser retomado. Evite reiniciar a mesma operação em outro IP enquanto a causa continuar sem solução.

O provedor pode usar um chamado, um formulário no painel ou um processo específico de resposta. Alguns serviços disponibilizam o texto da reclamação e seu status por uma API. Essas são formas de tratar o incidente; nenhuma estabelece um prazo universal de restabelecimento. Um prazo para analisar a resposta do cliente também é diferente de uma promessa de reativar o serviço.