Escrito por César Diaz, Líder de Assuntos de Telecomunicações
Como entusiasta da mecânica e do conserto de carros, sou assinante de um site especializado na marca do meu veículo há anos. É um daqueles sites conhecidos como “Faça você mesmo (DIY)”, onde entusiastas e proprietários podem consultar informações técnicas para conhecer melhor nossos carros e realizar alguns reparos por conta própria.
Uma das ferramentas que eu mais usava eram os esquemas e diagramas de mecânica automotiva. Estes me permitiam ver graficamente como são montadas as diferentes partes do motor, a carroceria e outros componentes do veículo, juntamente com seus números de peça, descrições técnicas, etc.
No entanto, um dia aconteceu algo diferente: os diagramas pararam de aparecer.
(Acesso livre, não requer assinatura)
A página continuava funcionando; era possível navegar por ela, consultar as descrições e até mesmo ver os números das peças, mas as imagens com os diagramas já não estavam disponíveis. Minha primeira reação foi pensar que se tratava de um problema do site.
No entanto, fiz um teste simples: conectei-me à Internet usando outro provedor, sem mudar de dispositivo nem de local, e, para minha surpresa, os diagramas voltaram a aparecer.
A situação era estranha. Eu continuava sendo a mesma pessoa, usava o mesmo computador e, fisicamente, estava no mesmo lugar. A única coisa que havia mudado era o meu provedor de Internet e, com isso, o endereço IP público a partir do qual eu acessava o site.
A página continuava funcionando; era possível navegar por ela, consultar as descrições e até mesmo ver os números das peças, mas as imagens com os diagramas já não estavam disponíveis. Minha primeira reação foi pensar que se tratava de um problema do site.
No entanto, fiz um teste simples: conectei-me à Internet usando outro provedor, sem mudar de dispositivo nem de local, e, para minha surpresa, os diagramas voltaram a aparecer.
A situação era estranha. Eu continuava sendo a mesma pessoa, usava o mesmo computador e, fisicamente, estava no mesmo lugar. A única coisa que havia mudado era o meu provedor de Internet e, com isso, o endereço IP público a partir do qual eu acessava o site.
Decidi pesquisar o que poderia estar acontecendo. De acordo com as informações que consegui encontrar, o fabricante da marca do meu veículo tinha enviado uma notificação de "cessação e desistência" ao provedor que hospedava o conteúdo, por motivos relacionados à propriedade intelectual dos diagramas. Como consequência, teria sido implementada uma restrição baseada na geolocalização dos endereços IP, prática conhecida como GeoIP Blocking.
E como funciona?
O site consulta informações de geolocalização associadas ao endereço IP a partir do qual recebe a conexão. A partir dessas informações, estima de qual país o acesso está sendo feito e pode aplicar uma regra relativamente simples:
Mas aqui aparece uma distinção importante: o endereço IP não contém, por si só, a localização geográfica exata do usuário. Essa localização é uma estimativa construída a partir de informações externas.
Isso explica a aparente contradição da minha experiência: eu nunca atravessei uma fronteira. A localização atribuída ao meu endereço IP, aparentemente, sim. Também não usei um VPN.
Este pequeno exemplo me permite introduzir um problema muito mais amplo: A Internet não foi projetada seguindo as fronteiras geográficas dos países. No entanto, determinadas medidas de bloqueio usam os endereços IP e a localização a eles atribuída para tentar impor essas fronteiras na Internet.
Um endereço IP não tem geografia própria
As fronteiras territoriais determinam onde começa e termina a jurisdição de um Estado. A Internet funciona de outra forma.
Os endereços IPv4 e IPv6 permitem identificar interfaces e encaminhar pacotes entre redes, mas não contêm um campo que indique o país, a cidade ou a localização física de uma pessoa.
Para estimar essa localização, são usadas fontes externas e bancos de dados de geolocalização.
Aqui existe uma diferença importante. Os Registros Regionais da Internet, como o LACNIC, mantêm informações sobre as organizações que recebem e administram recursos de numeração. No entanto, o local onde uma organização está registrada pode não coincidir necessariamente com o local onde seus endereços IP estão sendo usados.
Um operador pode usar seus recursos em diferentes cidades ou países, trasladar infraestrutura ou prestar serviços no nível regional. Por isso, as informações administrativas disponíveis mediante o WHOIS ou RDAP não deveriam ser interpretadas automaticamente como a localização dos usuários desses endereços.
As empresas de geolocalização usam diferentes fontes e metodologias para realizar suas estimativas. Como consequência, um mesmo endereço IP pode aparecer associado a locais diferentes, dependendo da base de dados consultada.
Os geofeeds procuram melhorar a qualidade das informações de geolocalização ao permitir que os próprios operadores publiquem onde usam seus prefixos IP. O RFC 8805 define o formato para publicar essas informações, enquanto o RFC 9632, que substituiu o RFC 9092, estabelece mecanismos para localizá-las e usá-las, incluindo um esquema opcional baseado no RPKI para autenticar os dados publicados.
O LACNIC tem promovido o uso de geofeeds na América Latina e o Caribe como uma ferramenta para melhorar a precisão das informações sobre onde os recursos de numeração da Internet são usados. No entanto, mesmo aqui devemos manter uma distinção fundamental: um geofeed pode indicar onde um recurso da Internet é usado; ele não converte um endereço IP em uma coordenada exata nem identifica a pessoa por trás dele.
Quando uma estimativa decide quem pode acessar
A geolocalização por IP pode ter usos perfeitamente válidos e legítimos: selecionar automaticamente um idioma, direcionar o tráfego para uma infraestrutura próxima, detectar anomalias ou gerenciar determinados direitos territoriais sobre conteúdos. O problema surge quando uma estimativa geográfica se transforma em uma decisão de acesso.
Se uma plataforma considerar que um endereço IP pertence a um país determinado, pode permitir ou impedir o acesso com base nessa informação. Se a estimativa estiver errada, a decisão também poderá estar.
Por isso, convém distinguir entre geolocalizar e bloquear. A geolocalização tenta estimar onde se encontra uma conexão. O bloqueio é a decisão tomada com base, entre outros fatores possíveis, nessa informação.
O risco surge quando tratamos a primeira como uma certeza para executar a segunda.
Bloquear um IP pode significar bloquear muito mais.
Existe, além disso, outro cenário diferente: uma autoridade legal pode ordenar a um provedor de Internet que impeça o acesso a um endereço IP associado a determinado site ou serviço.
Aqui, o bloqueio já não acontece porque o site considere que o usuário está dentro ou fora de determinado território. A restrição é aplicada diretamente na rede do provedor. Mas um endereço IP não representa necessariamente um único site.
Nas arquiteturas atuais de nuvem, hospedagem compartilhada, proxies reversos e redes de distribuição de conteúdo (CDN), diversos domínios e serviços podem compartilhar infraestrutura e até mesmo endereços IP.
O que acontece, então, se bloquearmos um endereço IP que também é usado por serviços que nada têm a ver com o conteúdo que originou a medida?
Podemos acabar bloqueando-os também e, consequentemente, seria como fechar um prédio inteiro para impedir o acesso a um único escritório.
Esse fenômeno é conhecido como “sobrebloqueio” e constitui um dos principais riscos de usar endereços IP como mecanismo de restrição. Os RFC 7754 e 9505 analisam as limitações de diferentes mecanismos de bloqueio e seus possíveis efeitos sobre terceiros.
A pergunta, portanto, não deveria ser apenas “conseguimos bloquear o conteúdo?”, mas também “o que mais estamos bloqueando inadvertidamente?”
Bloquear demais e, ainda assim, não bloquear o suficiente.
Aqui surge um dos paradoxos dos bloqueios baseados em endereços IP. De um lado, podem resultar excessivamente abrangentes: afetar outros sites, serviços ou usuários que compartilham infraestrutura ou endereços. Do outro lado, não impedem necessariamente que quem realmente deseja acessar o conteúdo possa fazê-lo por meio de uma mudança de rede, VPN, proxy ou outros mecanismos.
Uma medida pode, então, acabar bloqueando demais aqueles que não eram o seu alvo e, ao mesmo tempo, não bloquear o suficiente aqueles que realmente o eram.
Isso não significa que todo bloqueio seja improcedente. Governos, tribunais, plataformas e titulares de direitos podem perseguir objetivos legítimos relacionados à propriedade intelectual, fraude, cibersegurança ou ao cumprimento de decisões judiciais. No entanto, um objetivo legítimo não transforma automaticamente qualquer mecanismo técnico em uma medida adequada.
Uma decisão que juridicamente “impeça o acesso a este conteúdo” pode acabar sendo implementada tecnicamente como “bloqueie este endereço IP”, e ambas as coisas não são equivalentes.
Antes de implementar uma medida desse tipo, seria bom se perguntar: que outros serviços utilizam essa infraestrutura?, quantos usuários poderiam ser afetados?, quão confiável é a geolocalização usada?, existem alternativas mais precisas?, há mecanismos para detectar e corrigir erros?, por quanto tempo o bloqueio será mantido?
A necessidade, a proporcionalidade, a transparência e a mínima afetação não são apenas princípios jurídicos. Também deveriam orientar a forma como essas decisões são implementadas tecnicamente.
Um sinal, não uma fronteira
Um endereço IP pode fornecer informações úteis sobre a origem de uma conexão, mas não é uma identidade, uma localização exata nem uma fronteira.
O desafio surge quando uma estimativa técnica se transforma em uma decisão de acesso. Um bloqueio pode perseguir um objetivo legítimo e, no entanto, afetar usuários ou serviços que nada têm a ver com aquilo que se pretende restringir.
Minha experiência com aquele site de diagramas é apenas um pequeno exemplo: eu nunca mudei de país nem de localização. Bastou mudar de provedor para que o sistema interpretasse minha conexão de forma diferente.
Por isso, qualquer medida de bloqueio deveria considerar não apenas seu objetivo e eficácia, mas também sua precisão, proporcionalidade e possíveis efeitos sobre terceiros.
A Internet não foi projetada seguindo as fronteiras dos países. Quando tentamos impô-las por meio de medidas de bloqueio, devemos nos perguntar não apenas o que queremos deixar de fora, mas também quem pode ficar inadvertidamente do outro lado.
Kline, E., Duleba, K., Szamonek, Z., Moser, S., e Kumari, W. (2020). A format for self-published IP geolocation feeds (RFC 8805). Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc8805/
Bush, R., Candela, M., Kumari, W., e Housley, R. (2024). Finding and using geofeed data (RFC 9632). Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc9632/
Barnes, R., Cooper, A., Kolkman, O., Thaler, D., e Nordmark, E. (2016). Technical considerations for Internet service blocking and filtering (RFC 7754). Internet Architecture Board. https://www.rfc-editor.org/info/rfc7754/
Hall, J. L., Aaron, M. D., Andersdotter, A., Jones, B., Feamster, N., e Knodel, M. (2023). A survey of worldwide censorship techniques (RFC 9505). Internet Research Task Force. https://www.rfc-editor.org/info/rfc9505/
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
