Boas Práticas para Serviços de Rede Residencial Baseados em Consentimento

1. Finalidade

Serviços de rede residencial (por vezes chamados de proxies residenciais, compartilhamento de banda ou redes de acesso à web) roteiam o tráfego de clientes corporativos por meio de dispositivos de consumidores cujos proprietários concordaram em participar. Quando bem executado, esse modelo se apoia no consentimento informado do consumidor de um lado e na triagem rigorosa de clientes do outro. Quando mal executado, expõe consumidores ao uso oculto de recursos e expõe a internet a tráfego abusivo.

Este documento recomenda padrões básicos que qualquer operador deste setor deveria cumprir, em formato adequado à adoção por legisladores, reguladores e organismos de normalização. Está organizado em torno de quatro pilares:

• Consentimento e divulgação ao consumidor
• Proteção de dados do consumidor
• Salvaguardas técnicas em nível de dispositivo
• Triagem de clientes e prevenção de abusos

Encerra com recomendações sobre como a conformidade deveria ser testada e governada.

2. Consentimento e Divulgação ao Consumidor

Um operador não deveria inscrever um dispositivo sem uma decisão informada, afirmativa e reversível de seu proprietário.

Requisitos recomendados:

• Adesão afirmativa. A inscrição exige ação explícita do usuário. Sem caixas pré-marcadas. Sem incorporar a participação silenciosamente em uma instalação, atualização ou funcionalidade não relacionada.
• Destaque equivalente. Opções de aceitar e recusar apresentadas com igual peso visual. A recusa não deve degradar a funcionalidade essencial do aplicativo hospedeiro além da retenção de eventual incentivo de participação.
• Divulgação no ponto de decisão. Antes de se inscrever, o usuário vê em linguagem simples: o que significa participar, que tráfego de terceiros sairá por sua conexão e quais recursos do dispositivo são utilizados (banda, CPU, eletricidade).
• Termos vinculados. Links diretos para os termos de licença e a política de privacidade do operador na própria tela de consentimento.
• Revogável a qualquer momento. Cancelamento com um clique nas configurações do dispositivo ou do aplicativo, com efeito imediato.
• Novo consentimento em caso de mudança material. Se a natureza da participação mudar materialmente, os usuários existentes devem ser consultados novamente, e não migrados silenciosamente.

Requisitos do aplicativo hospedeiro. Quando a rede é incorporada via SDK em um aplicativo de terceiros, o aplicativo hospedeiro deveria ser obrigado a: divulgar a integração em seus próprios termos de serviço e aviso de privacidade, apresentar o fluxo de consentimento completo sem modificações e identificar o operador da rede pelo nome. O operador deveria permanecer independentemente responsável perante o usuário final, independentemente da relação de incorporação, e deveria analisar cada integração frente a esses requisitos antes do lançamento.

3. Proteção de Dados do Consumidor

Requisitos recomendados:

• Minimização de dados. Coletar apenas o que a operação exige. Apropriado: IP da sessão, identificador anônimo do dispositivo, localização aproximada (em nível de cidade), especificações do dispositivo, estatísticas de banda.
• Coleta proibida. Histórico de navegação, uso de aplicativos, conteúdo de arquivos, comunicações pessoais, localização GPS precisa.
• Limite de retenção. Dados do lado do participante expurgados em um cronograma fixo e curto (60 dias é um parâmetro do setor factível), com registros operacionais retidos apenas conforme exigido pelos controles de segurança e pela lei.
• Sem uso secundário. Dados do participante não vendidos nem usados para finalidades além da operação da rede.

4. Salvaguardas Técnicas em Nível de Dispositivo

Uma sessão de cliente jamais pode ser utilizável para alcançar a própria rede privada do dispositivo participante, sua interface de loopback ou endpoints de metadados de nuvem. Sem isso, o tráfego do cliente poderia sondar a rede doméstica do participante ou roubar credenciais de infraestrutura colocalizada.

Requisitos recomendados:

• Bloqueio de saída para faixas privadas. Bloquear o tráfego do cliente para loopback, faixas privadas RFC 1918, endereços link-local e de metadados de nuvem, espaço de NAT de nível de operadora e equivalentes em IPv6 (link-local, unique-local).
• Aplicação ciente da resolução. Bloquear uma requisição se qualquer endereço resolvido por DNS estiver em uma faixa protegida. Validar literais de IP diretamente. Desencapsular e validar endereços IPv6 mapeados em IPv4. Rejeitar em caso de falha de resolução.
• Aplicação do lado do servidor como piso. Como o software cliente implantado se atualiza lentamente (os ciclos das lojas de aplicativos de TV e de celular podem atrasar meses ou anos), a aplicação do lado do servidor cobrindo todo o tráfego deveria ser obrigatória. O bloqueio do lado do cliente é uma valiosa defesa em profundidade, mas não pode ser o único controle, pois clientes antigos permanecem em campo.
• Restrições de portas. Tráfego do cliente limitado às portas web padrão. Portas de e-mail (SMTP e relacionadas) e portas de administração remota (SSH, RDP, SMB, Telnet) bloqueadas na camada de rede, uma vez que possibilitam spam, ataques a credenciais e movimentação lateral.

5. Controles de Abuso em Tempo de Execução

A triagem acontece uma vez; os controles de abuso funcionam continuamente. Um cliente aprovado ainda pode se comportar mal, ser comprometido ou ter credenciais roubadas. Os operadores deveriam impor limites em tempo de execução que tornem a rede estruturalmente resistente a abusos, independentemente de quem a esteja usando.

Requisitos recomendados:

• Limites de vazão de banda por dispositivo. Delimitar o tráfego que qualquer dispositivo participante transporta, protegendo a conexão do participante e impedindo que qualquer dispositivo isolado seja transformado em arma.
• Limitação de taxa. Limites de taxa de requisições por cliente e por sessão que tornem o abuso volumétrico (participação em DDoS, credential stuffing, rajadas agressivas de scraping) inviável no nível da rede, e não apenas proibido no papel.
• Detecção de anomalias de tráfego. Monitorar padrões compatíveis com abuso: picos súbitos de volume, rajadas com alta taxa de erros contra um único alvo, padrões de requisição distribuídos que correspondam a assinaturas de ataque conhecidas.
• Resposta automatizada. Limitar ou suspender automaticamente a sessão do cliente infrator diante de anomalia, sem prejuízo ao dispositivo participante.
• Interruptor de emergência. O operador deve ser capaz de interromper imediatamente o tráfego por cliente e por dispositivo.

6. Triagem de Clientes e Resposta a Abusos

As proteções do lado do consumidor pouco significam se qualquer pessoa puder comprar acesso anonimamente.

Requisitos recomendados:

• Conheça seu cliente antes do acesso em produção. Integração em etapas, na qual o acesso completo à rede só é concedido após: verificação de identidade individual ou empresarial, análise do caso de uso frente a uma política de uso aceitável publicada, análise de titularidade final para perfis de maior risco, validação de pagamento e triagem de sanções (OFAC, EU, UK, UN).
• Níveis de escrutínio reforçado. Análise adicional para revendedores, setores sensíveis (serviços financeiros, saúde, governo), exposição jurisdicional de alto risco e casos de uso próximos aos limites da política.
• Usos proibidos publicados. No mínimo: negação de serviço, distribuição de malware, CSAM (com comunicação obrigatória ao NCMEC ou à autoridade nacional aplicável), spam, credential stuffing, varredura não autorizada e qualquer atividade ilícita.
• Aplicação gradual e documentada. Resposta escalonada por gravidade, desde advertência até rescisão imediata sem prazo de saneamento, com preservação de provas e encaminhamento às autoridades policiais quando aplicável.
• Responsabilização na cadeia contratual. Clientes contratualmente responsáveis pela conduta de seus próprios usuários subsequentes, de modo que a responsabilização sobreviva à revenda.
• Processo com autoridades policiais. Recebimento documentado com análise de validade, jurisdição e escopo; produção estritamente delimitada; notificação ao participante e ao cliente quando legalmente permitido.

7. Como a Conformidade Deveria Ser Testada e Governada

Para organismos de normalização e esquemas de certificação, a forma como um padrão é testado importa tanto quanto o que ele exige. Princípios recomendados:

• Testes baseados em resultados e neutros quanto à implementação. Julgar a conformidade pelo fato de o resultado proibido poder de fato ocorrer (por exemplo: uma requisição a uma faixa privada bloqueada pode de fato sair de um dispositivo participante), e não pelo mecanismo que o impede. Critérios que impõem um mecanismo específico permitem que a arquitetura de um operador se torne o padrão.
• Testes reproduzíveis, não listas comerciais. Conformidade medida pelo teste documentado e reproduzível do próprio esquema. Nunca pela inclusão em uma lista de bloqueio ou feed de reputação controlado por um participante do mercado.
• Devido processo antes de conclusões desfavoráveis. Aviso prévio à publicação, uma janela para comentários e direito a novo teste. Nenhuma listagem desfavorável com base em resultado contestado antes do esgotamento do recurso.
• Governança neutra das listas. Quaisquer critérios ou listas de bloqueio de propriedade neutra, versionados, com um processo documentado de contestação pelo operador. Nenhum participante isolado ou fornecedor de detecção os cura.
• Divulgação de conflito e impedimento. Qualquer participante que venda serviços concorrentes de detecção ou pontuação, ou que esteja em litígio ativo com outro participante, divulga o conflito e se declara impedido de julgar essa parte.

8. Lista de Verificação Resumida