Passado o frenesi do
Cicablock, ou
Cicagate, ou qualquer outro nome pelo qual você, leitor, tenha ouvido falar dessa aberração jurídica que foi o bloqueio do site
YouTube por causa do vídeo onde Daniela Cicarelli e seu namorado aparecem transando em uma praia espanhola, decidi que era uma boa idéia escrever uma pequena (ou não tão pequena assim) análise técnica do evento e tentar com isso oferecer subsídios àqueles que tentem entender o episódio.
De forma rápida, uma vez que o vídeo de Daniela Cicarelli foi considerado “ilegal”, o juiz pediu um parecer técnico sobre a possibilidade ou não desse bloqueio. Na realidade, aqui pretende-se justamente fazer isso, mas indo para um outro patamar, que é o de dissecar as possibilidades de um bloqueio a conteúdo na Internet e potenciais problemas que possam tornar esse bloqueio impraticável. Percebam que aqui não uso o termo
impossível, até mesmo porque não “existe impossível” no cyber-espaço, mas sim
impraticável, seja por custos operacionais ou por reações adversas.
Vamos começar então analisando as possibilidades de um bloqueio a conteúdo. Perceba que aqui não faço nenhuma distinção a textos, imagens, sons, vídeos ou qualquer multimídia. Faço isso de forma a deixar claro que a Internet é, de certa forma, feita de bits que compõem, em sua esfera mais abstrata e
human-friendly conteúdo, mas que continuam sendo bits em sua esfera mais “concreta” e
machine-friendly.
Sem delongas, vamos ver três tipos de bloqueio que poderiam ser implementados: isolamento de redes, bloqueio de conteúdo por
keycontent, bloqueio de conteúdo por checagem de validação (
checksum). Vou explicar a seguir o que cada um desses bloqueios, sua implementação e seus problemas.
1-) Bloqueio pelo isolamento de redes:
Esse primeiro bloqueio foi implementado no caso do Cicagate pela Brasil Telecom e pela Telefônica. Dele derivaremos duas novas “interpretações” para as tecnologias da Internet, mas antes partiremos para a teoria básica.
Podemos definir que uma rede de computadores na verdade apenas replica uma rede de troca de informações humana, que por sua vez é estabelecida quando nos comunicamos uns com os outros (por exemplo, no bate-papo sobre futebol). Ora, para montarmos uma comunicação, precisamos de um emissor (alguém que envia a informação, ou mensagem), um receptor (alguém que recebe a informação), um meio por onde a informação irá trafegar, e um protocolo que permita que o emissor envie a informação de maneira que o receptor a receba. Esse protocolo pode, por sua vez, também incluir traduções entre o protocolo utilizado pelos pares se estes forem diretamente incompatíveis (definindo “incompatível” aqui como “suficientemente diferente para comprometer ou invalidar a comunicação“).
Desse modo, podemos definir que o alvo para invalidar uma comunicação são quatro: o emissor, o receptor, o meio e pelo menos um dos protocolos adotados. Uma vez que você iniba um deles, a comunicação deixa de existir.
Transportando essa teoria ao mundo cibernético da Internet, podemos dizer que o emissor é o site do qual o usuário solicita o conteúdo (ou seja, a mensagem), o receptor é o usuário, o meio são as várias vias de transmissão de bits, seja por cabo, fibra, ou sinais magnéticos e os protocolos são os protocolos da pilha TCP/IP. Agora que já transportamos a teoria para a parte técnica, podemos falar um pouco sobre os protocolos.
Todo protocolo de rede (e o TCP/IP não é exceção) precisa saber qual é o destinatário e o remetente da informação, da mesma forma que um carteiro precisa saber o endereço de quem vai receber a carta e, caso essa pessoa não esteja lá, o endereço para onde mandar a carta de volta, indicando que a mesma não se encontra. No caso do TCP/IP, essa parte é feita pelo endereço IP, uma seqüência de 32 bits representada em 4 números decimais chamados “octetos”, que representam “pedaços” de 8 bits do endereço IP. Como exemplo, poderíamos afirmar que uma máquina qualquer pode ser representada pelo endereço IP hipotético 123.456.789.012.
Agora que sabemos que todo servidor na Internet é representado pelo endereço IP, temos que entender também sobre os backbones (espinhas dorsais) e roteadores. De maneira simples, um roteador é um equipamento que é capaz de direcionar os dados enviados para ele por uma ou mais rotas até que os dados alcancem seu destino. Podemos comparar mal-e-mal um roteador a uma agência de correio, onde as cartas são separadas para seus vários destinos. Da mesma forma que uma agência do correio, o roteador IP não precisa conhecer todos os destinos possíveis para enviar (ou, como chamamos tecnicamente, rotear) os dados: em caso de não saber para onde enviar os dados, todo roteador é programado a seguir uma “rota padrão“, ou seja, um caminho para o qual ele envia os pacotes que ele não sabe para onde mandar. Podemos comparar essa situação, por exemplo, a uma agência que manda uma carta para a central dos Correios no estado por não saber para onde a mandar. A partir daí, a central dos Correios é que se torna responsável por enviar a carta adiante. No caso, chamamos a nossa “central dos Correios” de backbone.
Como todo mundo sabe, o endereço de uma carta deve ser correto (ou ao menos válido) para que a carta chegue ao seu destino. Se ele estiver incorreto, normalmente a carta retorna a seu rementente com um alerta de que a carta está endereçada errada. O mesmo vale para o IP: se um backbone não consegue entregar um pacote por algum motivo, o sistema devolve ao usuário (na verdade, ao sistema do usuário) um alerta indicando que o endereço desejado não existe, tecnicamente um “pacote ICMP Destination Unreachable” (pacote é o nome que dá-se tecnicamente a uma parcela de informação que é enviada pelo meio de rede, podendo compor de uma quantidade arbitrária de bits; ICMP significa Internet Control Message Protocol, ou Protocolo de Mensagens de Controle da Internet, que de maneira rápida pode ser entendido como um protocolo que permite que um determinado endereço IP, ou host, possa saber se suas solicitações a outro host foram atendidas e se não foram, porquê; e Destination Unreachable quer dizer que o host de destino não foi encontrado por algum motivo).
Desse modo, podemos entender que o sistema é então alertado de que o host em questão não existe. A maioria dos roteadores, para contribuir com a performance da Internet, ao receber um desses pacotes param de tentar enviar dados ao host em questão por algum tempo, normalmente uns 5 minutos. Isso também impede que um host que tenha saído do ar por alguns instantes (por manutenção, por exemplo) nunca mais seja alcançado.
Portanto, chegamos ao ponto: como bloquear um host válido. A resposta seria tornar o host inválido de alguma forma. E como fazer isso? Com o uso de um firewall.
Firewalls são programas ou equipamentos que analisam os dados de um pacote de dados IP para verificar se o mesmo contêm algum tipo de problema ou informação inválida ou perigosa através de certas informações chave. São programas muito úteis na proteção contra ataques de pessoas más-intencionadas na Internet, uma vez que vários tipos de pacotes IP inválidos e habil e maliciosamente montados podem ser usados para fazer um host sair do ar ou permitir sua invasão (não entraremos nesse detalhe pois não nos é relevante).
Além disso, muitos firewalls atuais permitem que seus administradores bloqueiem determinados IPs, sejam por estarem sendo ponto de partida de invasões (como analogia, seria o equivalente cibernético a uma ponte levadiça medieval) ou então por representar hosts de serviços que são perigosos ou inapropriados de alguma forma.
O importante aqui é que um firewall barra qualquer comunicação daquele ponto em diante para qualquer ponto “atrás dele” (ou seja, que tenha que passar por ele para chegar em seu destino). Isso é muito útil pois desonera, por exemplo, uma empresa, que pode implementar um único firewall na sua “saída” para o backbone de Internet ao qual ela se conecte (podemos pensar nesse caso no firewall como uma aduana).
Se você leu com cautela até aqui esse documento, já deve ter reparado no que aconteceu: provavelmente um firewall foi ativado no backbone da Telefônica e da Brasil Telecom, de modo que eles começaram a considerar o IP do site YouTube como “perigoso ou inapropriado”. Aparentemente uma solução simples e rápida.
Mas quais são os incovenientes? Basicamente são cinco:
- Você está onerando todas as comunicações, mesmo aquelas válidas, uma vez que os dados têm de ser analisados quando da saída do pacote para a rede “desprotegida” e da volta dos dados (quando esse ocorre). Mesmo que o pacote seja considerado válido (por exemplo, por não estar indo ao YouTube) ainda assim ele deve ser validado, o que exige processamento, fazendo com que o pacote demore a ser enviado e atrase os demais (imagine uma aduana super-lotada por causa de fiscalizações da Receita Federal: essa seria a imagem de um firewall nessa situação);
- Se por um acaso (o que não ocorreu no caso YouTube), um mesmo host contiver mais de um site (isso é possível, mas não entraremos nos detalhes técnicos, uma vez que é um assunto razoavelmente complexo e fora do escopo desse documento), todos os sites estarão bloqueados. O bloqueio de IP é “burro”, não conseguindo analisar todo o conteúdo dentro dele, e sim certas informações chave. Existem filtros mais “refinados”, sobre os quais falaremos adiante. De certa forma, foi o que ocorreu no caso Cicagate;
- Derivado do problema (1), você onera todas as redes para trás, reduzindo a performance dos hosts “atrás” do firewall. O firewall tem que gastar algum tempo para analisar cada pacote de dados para definir se o mesmo é válido ou não. Embora os roteadores e firewalls sejam rápidos nisso (coisa de milisegundos ou até micro-segundos dependendo do sistema), temos que considerar que milhares, até milhões de pacotes são enviados a cada segundo pela Internet. Ou seja, o “poder de fogo” necessário é muito grande, principalmente se procurar-se não onerar o tráfego lícito;
- Como comentamos ao analisar o problema (2), o bloqueio de IP é “burro”, não analisando realmente o conteúdo. Isso, ao mesmo tempo que passa por censura (lembre-se, todo o site está fora do ar. É como se arrancássemos o cabo que chega a um tronco de telefones dentro de uma empresa, ou derrubássemos uma torre de telefonia celular), ele não impede a divulgação do conteúdo por meio de sites similares;
- Também derivado do problema (2), o bloqueio de IP pode se tornar inefetivo se, fora da rede “protegida” um outro host IP fizer o redirecionamento do pacote IP para o IP bloqueado. Técnicas de redirecionamento por meio de proxies (softwares que fazem esse papel de intermediário) são conhecidas e muito baratas, além de ajudarem na própria performance da Internet. O detalhe aqui é que, para o firewall, o conteúdo não vem do IP bloqueado, mas sim do IP do proxy. Como não há uma análise do que vêm, mas sim de onde vêm, o conteúdo proibido “vaza”;
Esclarecido o problema, vamos analisar duas táticas de bloqueio mais “refinadas”, mas que ainda assim não são tão efetivas, que são a checagem por keycontent e a checagem por validação (checksum).
2-) Bloqueio por checagem de keycontent:
Como já vimos anteriormente, tentar bloquear conteúdo na Internet apenas por meio de bloqueio de IP não é uma coisa muito efetiva e pode acarretar, na verdade, “fogo amigo” (ou seja, eliminar conteúdo importante). Então vamos ter que “subir um nível”, ou seja, passar a lidar com o conteúdo um pouco acima, apesar de ainda falarmos de bits.
O TCP/IP na verdade não é um protocolo de dados, e sim uma pilha de protocolos (protocol stack). Em um sistema assim, os protocolos “superiores” (que lidam diretamente com o usuário) vão repassando os dados aos protocolos “inferiores”, que por sua vez “envelopam” esses dados com as informações de controle específicas de sua camada, até a última, a camada física, que realmente manda os dados. Ao chegarem em seu destino, os dados vão sendo “desenvelopados” pelas camadas “inferioras” que remetem os dados às camadas “superioras”, até a camada onde os dados serão tratados.
Imaginemos o seguinte exemplo: você solicita uma página Web para um servidor qualquer. Você abre seu navegador e digita o endereço da página desejada. Uma vez o endereço digitado, o navegador formata esse endereço em uma solicitação HTTP, que é o protocolo da Web. Uma vez formatada a requisição, os dados são mandados para a camada seguinte, onde o protocolo TCP (Transfer Control Protocol) “envelopa” os dados da camada HTTP com seus dados de controle. Para o TCP, não interessa a formatação da requisição HTTP. Ele apenas sabe que tem que enviar esses dados para uma porta de dados específica no servidor (porta de dados é uma porta lógica para onde os dados devem ser enviados. O uso dessas portas permite que um mesmo servidor possa administrar vários serviços conforme a conveniência), a porta 80, então ele “envelopa” essa informação junto com os dados do HTTP, no qual ele não mexe. Em seguida, o TCP manda as informações para a camada “inferior”, a do protocolo IP, que novamente “envelopa” os dados: ele não precisa saber a qual porta o TCP precisa enviar os dados, só precisa saber que precisa mandar os dados para um IP qualquer. Ele então “envelopa” essa informação de controle com as informações anteriores e manda para a camada física, onde a placa de rede (ou wireless) sabe qual é o servidor para o qual os dados serão enviados. Perceba que não estamos falando de como o sistema descobre essas informações, uma vez que é informação excessivamente técnica e irrelevante na nossa análise. Basta que saibamos que os protocolos conseguem obter certas informações que permitam a ele descobrir como enviar corretamente os dados desejados.
Uma vez que os dados chegam na camada física do servidor de destino, o processo é invertido: o protocolo da camada física (seja qual for, Ethernet, WiFi, WiMax, etc…) “desenvelopa” os dados que vieram e manda-os para a camada de rede. Não é problema da camada física tratar os dados recebidos, então ele faz o que seria dito no popular de “toma que o filho é teu” com os dados recém-chegados para o protocolo de nível superior. O protocolo de rede identifica os dados como sendo direcionados para ele, então “desenvelopa” os dados recebidos e envia-os para a camada TCP. Nesse proceso de “desenvelopar” ele apenas “retira” os dados relacionados à sua camada, não mexendo em mais nada, uma vez que ele não sabe que dados estão “envelopados” e também pouco lhe interessa. Uma vez que os dados “sobem”, o TCP identifica a porta desejada e envia os dados a um servidor que está “escutando” a (ou seja, será responsável pelos dados que chegarem à) porta desejada (no caso, 80). Por fim, o servidor trata essa requisição e o processo se repete, mas no sentido inverso.
Na realidade, o sistema de envio de dados em rede é um pouco mais complicado que isso, pois existem questões como checagens de se os dados enviados estão corretos e confirmações de chegada dos dados, além dos diversos mecanismos usados para que os protocolos saibam como enviar corretamente os dados, mas em sua base isso deve ser o suficiente para compreender o que estamos falando.
Perceba que uma camada está pouco interessada para como as camadas superioras e inferioras tratam os dados ao receber/enviar. Ele apenas sabe como receber e enviar dados para cada uma dessas camadas, e ainda asism para as camadas diretamente superioras e inferioras. Isso permite um rápido desenvolvimento de novos protocolos e permite que problemas em uma camada não afetem (ao menos totalmente) as demais. Além disso, evita o risco de que uma alteração em um protocolo afete os demais. Como comparação rápida, imagine um monte de blocos Lego: você pode remover pequenas partes de um objeto feito com Lego e substituí-las por outras sem maiores problemas na maioria dos casos.
Essa topologia de pilha permite que facilmente seja adicionada “camadas” extras à pilha. Uma dessas “camadas” extras já vimos anteriormente, que é o Firewall. De maneira similar, podemos imaginar uma camada que afete, por exemplo, os dados ao irem/virem para/da camada TCP. Esse firewall é conhecido como filtro de conteúdo.
A técnica de filtragem de conteúdo na Internet já é bastante popular, principalmente em empresas, para restringir o acesso a certos tipos de serviços ou conteúdos. Existem várias técnicas para isso, sendo as principais: a técnica de restrição por porta, que, de maneira bastante simples, pode ser entendida como um firewall que aproveita-se do fato de os serviços na Internet, como Email, Web e Mensagens Instantâneas utilizarem-se de portas específicas para funcionarem e bloqueiam tais portas; e aqueles que buscam conteúdos específicos (que chamaremos de conteúdos chaves – keycontents) que identificam o protocolo ou conteúdo acessado e bloqueiam o acesso a partir desse conteúdo.
Os bloqueios por keycontent baseiam-se no fato de que o protocolo sempre exige ou envia uma determinada informação para que o programa que o usuário está usando reconheça essa comunicação. Por exemplo, uma string qualquer é enviada antes do conteúdo propriamente dito ser enviado, ou então o endereço do site é enviado. Em todos os caso, para resumir, o filtro analisa o conteúdo enviado/recebido atrás de padrões que identifiquem o conteúdo (como, por exemplo, a palavra “sexo” em sites eróticos), barrando o conteúdo a partir do momento em que o conteúdo em questão se encaixa em certos critérios definidos no bloqueio. Não irei aprofundar na explicação, mas o importante é saber que, como o que trafega na Internet são bits, qualquer padrão desses bits pode ser detectado pelo filtro em questão, desde que devidamente preparado a trabalhar com o protocolo em questão.
Esse bloqueio pode aparentemente parecer muito efetivo, principalmente contra conteúdos textuais, mas ele tem alguns inconvenientes:
- Demanda muito mais processamento, uma vez que na realidade ele processará muito mais informação do que alguns poucos bits, podendo processar informações da ordem de milhares ou até de milhões de bits em uma única solicitação até decidir se libera ou não a comunicação. Além disso, a oneração do sistema aumenta proporcionalmente;
- A maioria dos filtros de conteúdo são muito específicos para um determinado tipo de informação (por exemplo, informações textuais oriundas da Web). Se o meio ou a mensagem for alterada (por exemplo, enviar uma imagem ou mandar o texto por email), ele irá “vazar” pelo filtro de conteúdo;
- Muitos filtros de conteúdo são “burros”, ou seja, não são capazes de identificar o contexto do conteúdo. Por exemplo, um filtro especificado para bloquear conteúdos com a palavra “sexo” irá barrar sites de pornografia, mas poderá bloquear sites de educação sexual e até mesmo cadastros em sites. Basta que a palavra “sexo” apareça para que o conteúdo seja bloqueado. A isso é chamado em informática de “falso positivo”, o que demanda uma contínua supervisão para a melhoria do filtro;
- Os filtros também podem estar sujeitos a dois problemas: poisoning e falso negativo. O segundo problema é mais “passivo”, onde o conteúdo é levemente alterado de forma a “vazar” pelo filtro. Por exemplo, um site colocar “siexo” ao invés de “sexo”, o que já causaria no filtro o entendimento que aquele não é um site de “sexo”. O poisoning (envenenamento) é uma espécie de “tática vingativa” dos que se sentem prejudicados com o filtro de conteúdo, onde o filtro é “envenenado”, principalmente se são usadas técnicas de Inteligência Artificial para que o mesmo passe a negar conteúdos. A idéia é que junto com os materiais considerados “positivos” para o bloqueio, outros tantos “negativos” sejam inseridos, de maneira que, ao analisar-se para atualizar-se com novos padrões, a IA do filtro pegue padrões falsos que batam com conteúdo bom e acabe provocado um aumento no número de “falsos positivos”;
- Técnicas de criptografia, como o uso de redes como Tor ou FreeNet ou mesmo o uso de HTTPS ou SSH, podem permitir que o filtro seja ignorado, uma vez que o embaralhamento provocado pelos protocolos em questão faria o conteúdo não conseguir mais ser detectado pelo filtro. Nesse caso, a solução seria impedir o acesso por esses protocolos;
Como vimos, a aplicação dessa técnica não é nada viável em uma estrutura de backbone, uma vez que oneraria demais a comunicação (ele teria que abrir os pacotes, analisar e tudo o mais, o que faria com que demorasse muito a liberação dos pacotes), embora para empresas a técnica seja útil e barata (uma vez que o menor número de dados permite que o processamento não seja tão oneroso).
Mas uma coisa que muitos podem questionar é que os filtros baseados em keycontent não são bons para informação não textual. E nisso eu concordo. Existe um sistema que podemos analisar que pdoeria ser útil, tanto que existem investimentos em o torná-lo prático.
3-) Bloqueio baseado em soma de verificação (checksum):
Para um computador, não importa o conteúdo transmitido: tudo resumem-se a bits, 0s e 1s, informação matemática. E como toda informação matemática, os bits podem sofrer cálculos.
A idéia por trás do sistema de soma de verificação é essa: por meio de algoritmos, os bits em um determinado conteúdo transmitido (não importa se é um filme ou algumas poucas letras) é calculado e dele é obtido um número qualquer. Esse número, chamado de checksum, é enviado ou obtido pela outra ponta da comunicação que pega o mesmo algoritmo e o conteúdo obtido e refaz o cálculo. Uma vez que para obter-se o mesmo valor é necessário que todos os bits sejam exatamente os mesmos que foram mandados originalmente e na mesma seqüência, o fato do checksum obtido não ser o mesmo do conhecido irá determinar que o conteúdo não é o mesmo que o original, e deverá ser descartado.
O uso de checksum é muito comum quando você precisa transmitir grandes quantidades de informações pela rede. Na realidade, quase todos os protocolos conhecidos, ao menos nos níveis mais baixos, possuem soma de verificação como metodologia para correção de erros. Além disso, muitos protocolos de checksum, como SHA, GPG e MD5 são conhecidos e testados pelo tempo, além de facilmente implementáveis e com códigos conhecidos. Isso, ao menos na teoria, permitiria que um protocolo que fizesse um checksum contra conteúdo conhecido como “inapropriado” o fizesse contra qualquer conteúdo copiado via rede e o analisasse contra uma lista de checksums conhecidos como de conteúdos “inapropriados”, inutilizado a cópia caso o mesmo “casasse” com um dos checksum em questão.
Ainda assim, essa forma em teoria perfeita de checar conteúdo possui falhas estruturais graves:
- Demanda ainda mais poder computacional, pois o tipo de cálculo realizado costuma ser de alto poder computacional (como exemplo, se você baixar um arquivo ISO de uma distribuição Linux, em uma máquina mais ou menos atual levará pelo menos 5 minutos até que o checksum do mesmo seja calculado) e onera excessivamente a comunicação;
- Assim como no caso da análise de keycontent, temos o problema da criptografia: quando um processo criptográfico é aplicado a um conteúdo, o mesmo se torna diferente do original, o que invalidaria o checksum, gerando um “falso negativo”;
- Da mesma forma, conteúdos válidos poderiam sofrer ainda com “falso positivo”. Embora os protocolos de checksum procurem evitar o caso de “falso positivo”, tentando fazer com que apenas um conteúdo gere um determinado checksum, é razoável supor que, embora muito remota, a chance de um haver “falsos positivos” entre conteúdos em um checksum é algo possível;
- Provocar um “falso negativo” em um conteúdo desse é fácil: basta que aja uma alteração, por menor que seja, no conteúdo. Por exemplo: basta que um bit de dados seja adicionado/removido e o checksum irá “falhar”, retornando o “falso negativo”. Dependendo do tipo de mensagem, esse bit não irá comprometer a mensagem, podendo facilmente ser eliminado;
- Como uma forma de tentar reduzir-se as chances de (1) e (4), poderia-se analisar o conteúdo por “frações” do mesmo, gerando-se checksum de cada um deles em um tamanho razoável e, a partir de um deles dando “positivo” o conteúdo inteiro fosse invalidado. Porém, essa tática aumentaria por sua vez a chance de (3), principalmente porque pode ocorrer, conforme o tamanho da amostra que sofrerá a soma de verificação, que conteúdos similares possuam seqüências similares. Ou seja, quanto menor a amostra, mais rápido será a determinação do checksum e menor a chance de que um “falso negativo” seja gerado por remoção (afinal, se o cara remover um frame de um pedaço, os demais continuarão do mesmo jeito), mas maior será a chance de provocar-se um “falso positivo”, pois será estatisticamente mais provavel que dois pedaços de dois conteúdos se pareçam;
- Esse sistema está extremamente suscetível a mudanças nos protocolos e formatos de informação. Por exemplo: uma música em MP3 é diferente de uma em WMA ou em Ogg Vorbis. Mesmo sendo a mesma música ao ouvirmos-a, o conteúdo é considerado diferente pelo checksum. Existem técnicas que utilizam watermarking, que seria algo similar ao que foi discutido em (5), mas ainda assim o sistema seria suscetível;
4-) Conclusão:
O caso Cicarelli apenas demonstrou o quão inconseqüente uma tomada de atitude judicial mal feita pode se provar e o quanto ela pode prejudicar as pessoas: milhões de vídeos educativos e de entretenimento no YouTube ficaram indisponíveis por 48 horas. Por sua vez, a filtragem mostrou-se inefetiva, pois outros sites receberam o conteúdo e ao mesmo tempo esse conteúdo era levemente alterado sempre, escapando de possíveis filtros como os teorizados aqui. Ainda leverá muito, muito tempo até que computadores sejam capazes de filtrar conteúdo da mesma forma que seres humanos o fazem. E isso caracterizaria censura.
Espero que esse documento comprove o quão difícil seria produzir filtros como os propostos, de modo que as pessoas entendam que esse tipo de filtragem (ao menos com a tecnologia atual) é impraticável para o porte que a Justiça Brasileira deseja, embora para pequeno porte possa ser viável.
Leia, reflita e tire suas conclusões…
Certas coisas, quando você lê, não te surpreende. Não interessa o que, mas certas coisas, ao lê, não te surpreende. No meu caso foi ler que, via Groklaw, que 
De quando em quando aparece alguém perguntando qual 
Comentários