Blogagem Coletiva – Não ao Projeto de Lei de Censura à Internet

Hoje, dia 15/11, o Brasil comemora mais um Dia da República, um dia a se pensar sobre as liberdades que possuimos, conquistadas no passado com suor e sangue.
E uma dessas liberdades está para nos ser vilipendiada, ao menos na Internet, por meio de um substitutivo do Senador Eduardo Azeredo (PSDB/MG) que, por trás de uma intenção legítima (proteger a Internet da Pedofilia), ameaça desenvolver o vigilantismo ao mundo cibernetico, com graves conseqüências à liberdade de expressão e ao livre acesso aos bens culturais, direitos fundamentais da Carta Magna brasileira, e sem acrescentar nada de útil para o combate aos cyber-crimes.
Esse projeto de lei, sob o aval de órgãos cuja a luta não está relacionada aos direitos humanos ou ao combate à pedolifia e parceira dos lobbies internacionais da Propriedade Intelectual, em sua mais ampla tentativa de transformar a cultura em negócio e de se apropriar de todo o conhecimento e o tornar propriedade de alguns poucos, institui mecanismos draconianos de monitoração do tráfego do usuário na Internet e pesadas punições a qualquer um que tente “esquivar-se” das restrições impostas pela legislação, mesmo para usos legítimos (como assistir DVDs que você adquire legalmente em um sistema operacional Linux, uma vez que ele utiliza uma biblioteca chamada DVDCSS, que pode também ser usada para ripar DVDs para pirateá-los via Internet).
Como disse anteriormente nesse blog, considero essa uma lei não apenas desncessárias, uma vez que, pelos meus conhecimentos e pelas opiniões que tive de especialistas, o nosso país já possui mecanismos legais mais do que suficientes para prover as necessidades para obtenção de provas e tipificação de crimes. E como cito no email enviado aos Deputados Fedaris do Estado de São Paulo, o perigo dessa legislação é justamente cortar um canal de comunicação poderoso que nos pode oferecer belas coisas, como bandas como Cansei de Ser Sexy, O Teatro Mágiico e como a Compositora Malu Magalhães, que conseguiram demonstrar suas qualidades musicais sem precisar do “crivo” (leia-se jabá) das grandes gravadoras e dos grandes meios de comunicação, graças a Intrenet e a divulgação de músicas via MP3, o que está para se tornar um crime graças à legislação do Excelentíssimo Senador.
Analisarei aqui essa lei em algumas questões já analisadas, tentando as extrapolar ao máximo de conseqüências possíveis. Em alguns momentos poderei estar beirando a paranóia, mas prefiro nesse caso pensar no pior caso, uma vez que uma lei tão amplamente especificada, de maneira tão frouxa e potencialmente permissiva a múltiplas interpretações que eu prefiro fazer o máximo de interpretações possíveis.

A Ferro e Fogo:

Um dos problemas que ainda não foi tão citado nesse projeto é que ele cria uma discriminação ,pois ela “abole” a discriminação entre conteúdos legais e ilegais dentro da rede baseadas em determinadas mídias, ou seja, ela “anula” o fato de um conteúdo poder ser legitimamente produzido e distribuído via Internet e baseia a legalidade ou não meramente no formato de arquivo utilizado. Por exemplo, os arquivos MP3 estarão condenados, não interessando se são músicas distribuídas ilegalmente (como CDs “vazados”), legalmente (músicas que o próprio artista distribuiu, como o caso da banda mineira Pato Fu que em seu site distribui músicas que não foram incluídas em seus CDs) ou até mesmo MP3 não relacionados a músicas (como podcasts, palestras e ringtones). Desse modo, segundo os moldes dessa nova lei, existe um perigo sério de que qualquer conteúdo distribuído segundo determinados formatos possam vir a ser “criminalizados”, independente da legalidade ou não do “conteúdo” propriamente dito ser legal ou não.
Não existe nenhuma preocupação por parte do Excelentíssimo Senhor Eduardo Azeredo em entender o funcionamento básico da Internet para saber que não existem ainda mecanismos totalmente eficazes para impedir totalmente o tráfego de conteúdos ilegais e nem a caracterização dos mesmos. Correndo o risco de ser tecnicista, para a Internet, tudo se resume a bits e bytes: uma página, uma música clássica gravada por uma orquestra amadora disponibilizada, por exemplo, no Classic Cat, ou o CD mais novo do funk carioca vazado na net.
Essa tratativa do tipo “ferro e fogo” tem conseqüências terríveis para a Internet: jogara os usuários em uma “zona de incerteza” e irá tratar algo em torno de 60% de todos os usuários de Internet como criminosos em potencial (pela legislação atual, piores que corruptos e quase tão criminosos quanto seqüestradores ou traficantes de drogas, se considerarmos a legislação penal e cívil vigente).


Via Peão Digital

Cortesia com o Chapéu Alheio:

Outra prerrogativa a ser avaliada por tal legislação é que ela cria o conceito do “provedor xerife”: segundo a legislação em questão, o provedor deverá (1) gravar os registros de todos os usos da internet por parte de todos os seus usuários, com um período de “retenção” de 3 anos, (2) devem alertar à autoridades policiais qualquer suspeita de uso da Internet para distirbuir conteúdo ilegal e (3) que a pessoa, ao se cadastrar, deverá informar todos os dados legais, como Nome, Endereço, Telefone, RG, CPF, etc…
Bem, existem algumas questões aqui.

  1. Quem pagará a conta da infraestrutura de log?
  2. Como essa informação será trabalhada?
  3. Como essa informação será “disposta” (destruída) após o período de 3 anos?
  4. O que caracteriza uma “suspeita de uso da Internet para distirbuir conteúdo ilegal”?
  5. Quais são os mecanismos legais a serem criados para impedir o abuso desses mecanismos com o fim de prejudicar outras pessoas?
  6. Como fica o direito constitucional de uma pessoa “não gerar provas contra si mesma”?

Bem, acho que aqui podemos quebrar um pouco as coisas e responder essas questões uma a uma:

  • Quem pagará a conta da infraestrutura de log?

Pela lei será o provedor de acesso à Internet, sendo que a não existência de tais logs provocará sanções de ordem penal ao provedor.
Bem, isso a lei deixa claro.
Mas pela letra da lei a coisa fica ainda mais complicada: pela lei da oferta e da procura, norma capitalista, obviamente que tal custo (que deveria pertencer ao Estado) será repassado ao consumidor. Só que a coisa fica ainda pior pois não existe nenhuma parte dessa lei que defina qual provedor de acesso é que deve manter essas logs. Portanto, existe a possibilidade por essa lei de que provedores de backbone, como Telefonica e Embratel tenham que elas próprias manterem eses logs, o que gerará custos que serão repassados aos provedores que (obviamente) repassarão por sua vez ao consumidor. Ou seja, o “estado policialesco” criado por essa lei será pago por mim e por você que lê e o ônus da geração da prova crime sairá das mãos do interessado (como grandes bancos e ISPs).

  • Como essa informação será trabalhada?

Bem, esse é um dos caráter que na letra do papel parece extremamente simples, mas que algum conhecimento da informática comprova que é algo sem pé nem cabeça.
A geração de um log é algo extremamente simples: em muitos casos, um banco de dados com uma estrutura simples e de leitura razoavelmente rápida (normalmente apenas um arquivo texto puro) é povoado (termo técnico para preenchido) por registros que caracterizam uma conexão. Normalmente não são informações excessivas (cada registro provavelmente não teria mais que algumas dezenas, talvez centenas, de bytes). A análise desse log envolveria apenas a análise simples dos dados procurando informações específicas que comprovassem qualquer uso ilegal.
Antes que pensem que isso é impossível, na verdade esse tipo de análise de logs é prática comum em empresas para análises de uso voltadas à performance e capacidade de ambiente.
O problema é que toda a coleta será feita para cada acesso IP. Cada conexão IP será registrada, sendo que um mero acesso ao Google pode gerar uma quantidade significativa de acessos por segundo. Existem pessoas que questionam a validade dessa preocupação:
Ainda o PL 84/99 | the brain is a machine

Ainda acho essa choradeira por causa de log de provedor uma coisa infundada. Não é como se provedores e telecentros fossem quebrar da noite para o dia por guardar logs. Por exemplo, arquivo de texto (log) de 1G compacta para 100M usando bzip2. Em um DVD então cabem uns 40 dias de log, coloca que se gasta um DVD por mês para guardar log, 3 anos são 30 dvds… E olha que 1G de texto é coisa pra caramba. Chuta que você vai logar hora, origem, destino e GMT, isso daria uma linha de 30-40 caracteres, então 1G de texto guarda uns 25 milhões de acesso. Não é pouca coisa não. Levando em conta que essas contas eu fiz em cima do log do proxy do meu trabalho, que é um lugar com umas 1500 máquinas acessando a internet 24/7.

Bem, de qualquer modo, mesmo que seja fácil fazer a operação exigida para o registro e manutenção dos logs, como se dará o processamento? Como será processado, por exemplo, esses 30 DVDs de logs compactados com 46G de logs (descomprimidos) cada? Existe aqui um caráter que pouca gente pensa: aqui a questão passa a não ser mais apenas o armazenamento de tal volume de informação, mas também sua utilização. Basta pensar-se no processamento do IRPF: cada arquivo do Imposto de Renda tem algo em torno de 30Kbytes (basta olhar os arquivos de backup de sua Declaração para ter uma idéia). Se pensarmos que 30 Milhões de pessoas mandam algo em torno disso, e que leva-se tanto tempo para receber-se as restituições, perceberemos que existe uma questão de processamento que não foi considerada.

  • Como essa informação será “disposta” (destruída) após o período de 3 anos?

Aqui existe um perigo: o período de retenção mínima por lei é de 3 anos, mas não existe nada na lei em questão que indique como essa informação deverá ser “disposta” após esse prazo mínimo.
Aqui surgem riscos sérios da tentação de provedores se utilizarem dessa informação para obterem informações sobre os “hábitos de navegação” dos usuários, o que seria possível, ainda que complexo, alimentando-se esses dados em ferramentas conhecidas de data mining e afins. Com tais “perfis”, os provedores teriam informações altamente “apetitosas” a empresas de marketing (legítimas e não tão legítimas), seguradoras e outras empresas que possam fazer uso dessa informação. Sei que isso é paranóico, mas como não existem mecanismos legais, não existe como impedir, ao menos em teoria, que tais informações sejam “usadas contra você”.

  • O que caracteriza uma “suspeita de uso da Internet para distirbuir conteúdo ilegal”?

Essa é uma coisa importante: como se define suspeita? Teremos cyber-vigilantes (obviamente, pagos por nossa mensalidade de internet) contratados para nos vigiar? Os provedores se tornarão no Ministério da Verdade de 1984 por força da lei? Nós denunciaremos uns aos outros? Como diferenciar as suspeitas realmente válidas daqueles casos do “menino que gritava lobo” ou dos que são feitos intencionalmente com o objetivo de prejudicar às pessoas?

  • Quais são os mecanismos legais a serem criados para impedir o abuso desses mecanismos com o fim de prejudicar outras pessoas?

Reflexo das duas questões anteriores, quais serão os mecanismos para responsabilização do mal uso ou abuso dos mecanismos da lei em questão para atividades não-previstas na lei? Poderei processar meu provedor por invasão de privacidade se ele, tentado, utilizar os logs para produzir um “dossiê” sobre mim para uma seguradora ou empresa de marketing? E mais: como fazer isso se a legislação já pressupõe de certo modo que sou um criminoso?

  • Como fica o direito constitucional de uma pessoa “não gerar provas contra si mesma”?

Um dos princípios legais mais importantes segundo o Direito atual é que ninguém é obrigado a gerar prova contra si próprio, o famoso “você tem o direito de permanecer em silêncio”. Porém, uma das obrigatoriedades da lei é manter um registro das suas informações de acesso, que por sua vez implica no fato de que você estará aceitando as normas da lei em questão, inclusive o registro do log, o que obviamenbte quererá dizer aceitar “gerar prova contra si mesmo”! Ou seja, esse direito constitucional está sendo enviado para o ralo.

Quis Custodiet ipsos custodes?

Como podemos ver é que uma das grandes perguntas é quem guardará os guardiões? A lei não possui nenhum mecanismo, por mais rudimentar que seja, prevendo penalidades para os abusos do uso dessas. Ou seja, estamos correndo o risco de sermos vítimas de abusos de poder por parte de interesses comerciais (ou não) que possam restringir nosso acesso à cultura.
Bem acho que já me prolonguei, ainda mais se somar-se o que já disse anteriormente nesse blog. Desse modo, termino aqui esse blog, mas não sem antes deixar uma série (enorme) de links contra e a favor dessa lei (pois acredito que cada pessoa deve pensar por si própria) e uma última reflexão que li em um dos outros posts participando da blogagem coletiva:
O TERROR DO NORDESTE: XÔ CENSURA!

Na verdade, segundo o proprio Castells, os governos querem controlar o que fazemos, o que pensamos, querem controlar nossos cerebros. A midia de massa paulatinamente vem perdendo este papel, ela já não consegue regurgitar as verdades que habitarão nossas mentes, estamos ficando mais críticos, estamos ouvindo uma diversidade de opiniões e tirando nossas proprias conclusões, mas isto sim de fato é um grande perigo para qualquer regime totalitário.
Por estas e por outras que você deve mostrar que tem opinião propria, e mesmo que não seja igual a nossa, mas deve publicar no dia 15 de novembro um post contra o vigilantismo, contra o totalitarismo e a favor da liberdade e privacidade, a favor da neutralidade da internet e da união dos povos.

Por fim, lembro que existe uma petição Online com mais de 120 mil assinaturas repudiando esse Projeto de Lei, e que você pode mandar mensagem direta aos deputados do seu estado pedindo repúdio a essa PL (e se tiver sem idéias do que escrever, pode copiar o meu, apenas mudando para seu nome e informações).

Links:


Anúncios

Meio-Bit e a polêmica das traduções em SL

Eu tenho que admitir que até gosto de ler o Meio-Bit: o Cardoso parece de certa forma o similar brasileiro do John C. Dvorak (colunista norte-americano que publica colunas na Info brasileira), com um certo teor de trollagem no qual pode estar uma preocupação verdadeira. Isso é algo de se admirar nele.
Mas acho que às vezes até mesmo isso passa dos limites.
Recentemente ele postou no Meio-Bit um artigo com um nome no mínimo provocativo: Quer ajudar o Software Livre? Esqueça o Babelfish. O artigo até tem uma opinião bastante relevante, ainda que não possamos concordar: é o problema relacionado com a diferença entre tradução e localização. Mas o problema é que o tom do artigo, mais o próprio retrospecto do autor, mais uma série de outras questões compromete o que ele diz:

Quer ajudar o Software Livre? Esqueça o Babelfish | Meio Bit

No caso das traduções, temos um agravante: São de péssima qualidade. Um desenvolvedor de um projeto Open Source pequeno não tem mão-de-obra para certificar uma tradução. Se for um idioma pouco-familiar então, está na mão de quem “colaborou” com a versão.

Acho que o agravante aqui não é a péssima qualidade, o tamanho do projeto ou qualquer catzo que o seja, e sim na real é o fato de que as pessoas ainda não entenderam (provavelmente como o Cardoso) que a programação não é a única forma de colaborar com Software Livre. Ou seja, ou programo ou não colaboro.
Embora seja programador formado, vou admitir que não sou um super-programador, um über-hacker de códigos. Mas acho que conheço bem inglês e português. Quando tomei conhecimento do projeto Babelzilla (um projeto que fornece um site e ferramentas para tradução de extensões dos software do Mozilla), decidi começar a participar. Já tinha feito a tradução de uma extensão simples (a Add Bookmarks Here), então decidi procurar alguma na qual pudesse ajudar. Acabei pegando uma das mais importantes extensões atualmente, a Scribefire (ferramenta de edição de posts para blogs do Firefox). Antes que pensem que é fácil, mesmo ela sendo localizada e tudo o mais, são mais de 300 strings para traduzir com cuidado com termos e consistência. Não é um processo fácil e a cada novo release, novas strings relacionadas a novas funcionalidades surgem e precisam ser traduzidas.
A questão aqui é que existem formas razoavelmente simples de participar-se desse tipo de projeto e apoiar traduções, sobre as quais falarei adiante.
Vejamos o que o Cardoso diz a seguir:
Quer ajudar o Software Livre? Esqueça o Babelfish | Meio Bit

Tradução, aliás, que não é só rodar uma série de strings no Babelfish, colar de volta, enviar e dizer “eu sou desenvolvedor Open Source”. Parte do esforço deveria incluir localização, mas aí entra mexer em código, e os 99% lá de cima não têm competência pra isso.

Aqui é importante também que os desenvolvedores colaborem para tornar o software localizável. No caso do Firefox e das suas extensões, existem ferramentas de código que tornam o software localizável. Diferentemente do que se prega, localizar um software não é uma questão também de criar-se códigos com compilação condicional para os vários idiomas. Um software localizável tem que ter um mecanismo de:

  1. Identificar o “idioma preferido” do ambiente em questão;
  2. Carregar arquivos de localização específicos para o idioma em questão e;
  3. Substituir determinadas strings pelas informações contidas em um arquivo de localização;
  4. Modificar e corrigir determinadas características idiomáticas para o “idioma preferido” (por exemplo, no caso do japonês, chinês e hebraico, entre outros, onde a leitura dos conteúdos é feita da direita para a esquerda, o texto e a posição dos elementos de tela devem ser invertidos);

OK… Aqui temos uma questão interessante sobre como tornar o software localizável. Consultando a Internet, achei esse artigo no Guia do Mochileiro. Esse artigo comenta um pouco do processo de transformar o software em localizável. É um processo que depende de todos os lados e que é feito para ser “independente”, ou seja, o tradutor não precisa ser parte da equipe de tradução e vice-versa.
Agora, qual a dificuldade?
Na verdade, a dificuldade é justamente coisas como a que o Cardoso coloca e que o Vladimir Melo comenta:
Conheço alguém que prejudica o software livre « Vladimir Melo

(…) Ele faz críticas duras à tradução de software livre e encerra afirmando absurdamente: “Afinal pro usuário não importa se a janelinha está em inglês ou português, essencial é que ela faça alguma coisa.”

(…)Ele ou qualquer outra pessoa deveria pesquisar na internet durante meia hora para conhecer os projetos de tradução e saber (inclusive pelos usuários) o quanto eles têm melhorado tecnicamente. (…)

Por exemplo, as pessoas que vão a um hipermercado e compram um computador popular não têm obrigação de saber inglês (e muitas vezes não sabem). O fato de um aplicativo estar traduzido ou não faz toda a diferença para que elas o usem. Mas certamente este blogueiro não tem consciência de que sua atitude afasta colaboradores e dificulta o nosso trabalho de recrutamento e divulgação.

A questão é que, pela exposição do Cardoso, uma pessoa deveria se preocupar apenas em programar SL. A verdade é que, embora isso seja importante (1) não é fácil de ser feito e (2) tira foco.
O programador de SL tem que ser visto como programador, e o tradutor como tradutor. Se você não possui habilidade como programador, não há problema: o mundo do SL possui espaço para todo tipo de envolvimento, seja desenvolvimento, documentação, tradução, artes ou evangelização. Escolha uma área onde você sinta ter proficiência e vá em frente. Bug report, relato de problemas com a tradução e por aí afora também é importante. Não se sinta acanhado: existe MUITO ESPAÇO para atuar-se (aproveito e me coloco à disposição de qualquer usuário do Scribefire para comentários sobre a tradução para o português brasileiro).
Agora, tenho que concordar com a citação do Vladimir acima: o que o Cardoso diz no final do seu artigo é, no mínimo, irresponsável:
Quer ajudar o Software Livre? Esqueça o Babelfish | Meio Bit

Você vai colaborar muito mais com o Open Source (e com seu futuro profissional) se ao invés de sair chutando traduções automáticas agora, se preparar por uns 2 ou 3 anos e entrar produzindo de verdade. Afinal pro usuário não importa se a janelinha está em inglês ou português, essencial é que ela faça alguma coisa. (grifos meus)

Dizer isso é irresponsável pois no Brasil muitas pessoas mal sabe ler, escrever e compreender o português direito, quanto mais o Inglês, que é um idioma que, por mais que os anglófonos queiram dizer, é cheio de nuances e detalhes específicos. Colocar um software em inglês, à exceção de software altamente especializado (como programação, CAD e afins) ou em jogos (onde o inglês se resume praticamente a “Press Start”, à exceção de jogos no estilo RPG) é algo que eu diria no mínimo temerário. Mesmo a MS percebeu isso e com o passar do tempo passou a localizar todos os seus softwares para outros idiomas além do inglês. Não adianta o software fazer algo se o usuário não sabe o que ele faz, e simplesmente adestrar o usuário em “Clique aqui, clique aqui, clique aqui…” não resolve o problema básico, que é o fato de ele não saber o que cargas-d’água ele está fazendo.
Não tiro alguns méritos do artigo do Cardoso, e ressalto aos usuários de SL: se perceberem coisas estranhas em traduções, COMENTEM JUNTO ÀS COMUNIDADES OU DESENVOLVEDORES!!! A maior parte dos software mais importantes possuem comunidades específicas para a tradução (Ubuntu LoCo Teams, os projetos de localização do Debian como o Debian Brasil, Babelzilla, BrOffice.org, etc…) e elas são receptivas com os interessados (sei disso pela recepção que tive dos desenvolvedores do Scribefire), oferecendo todos os recursos para aqueles que desejarem aprender, assim como listas onde pode-se discutir termos adotados até que um consenso seja obtido. Se você souber um pouco mais de programação, prepare software para ser localizado (o artigo da Wikipedia citado anteriormente serve de bom ponto de partida). Acima de tudo participe!
Mas também tenho que afirmar que o artigo do Cardoso, apesar de tudo isso, foi de um mau-gosto atroz, e de um nível de temerariedade incrível. Vou me abster de comentar mais sobre o artigo per se, pois creio que o fundamento dele já foi desfeito aqui.
De qualquer modo, fica a sugestão aos novatos: participem. Aos veteranos: ajudem os novatos, por favor!

Lei de Crimes na Internet: Inútil e Perigosa

Sempre que eu leio sobre leis como o projeto de Lei do Senador Eduardo Azeredo para a “tipificação de crimes na Internet”, me pergunto se essas pessoas que são nossos representantes no governo são apenas despreparadas, inocentes ou simplesmente são mal-intencionados. Prefiro como cidadão brasileiro imaginar que seja a primeira ou a segunda resposta, mas cada vez mais me vejo pensando que é o terceiro: que “nossos representantes” estão apenas representando os interesses de uma pequena parcela de megacorporações que possuem interesses diversos (e muitas vezes antagônicos) aos da sociedade.
Por que digo isso?
Essa legislação, que visa em sua teoria lutar contra a pedofilia, é talvez um dos maiores exemplos de como uma lei pode ser mal redigida por pessoas cujo conhecimento do funcionamento da Internet é zero ou beira isso.
Vou tentar me manter no nível técnico, expondo as mazelas dessa legislação no âmbito técnico e seu impacto real na sociedade, tal como fiz em outras ocasiões, como no caso do Cicagate. Vou falar das características que me lembro e apontar links para materiais relevantes na Net. Se esquecer algo válido, peço desculpas: são muitos assuntos para pouco tempo.
Vejamos então:

Log de acesso por três anos

Para começar, vamos direto a uma das partes mais bizarras da legislação, que é a obrigatoriedade do log de acesso de todos os usuários de um provedor por três anos. Pois bem:
Qualquer um que tenha trabalhado com o gerenciamento, análise e manutenção de logs de qualquer tipo sabe que, dependendo de como o log é construído, existe uma explosão na quantidade de dados registrados que pode até mesmo comprometer o sistema. Segundo o substitutivo, a lei em questão exige registro (ou mais exatamente “retenção”) de todos os acessos de todos os usuários por no mínimo três anos. Normalmente, os logs de sistemas operacionais e aplicações são bem menores, de três/quatro dias. E não sem razão.
Imaginemos um exemplo fictício: temos um sistema de log genérico (chamemos de genlog para facilitar) que é capaz de registrar as informações solicitadas pela legislação. Esse genlog registra cada chamada IP do usuário em um formato como o abaixo:

nome_usuário:data:hora:IP_origem:IP_NAT:IP_destino:URL_destino:Protocolo_destino:Informações_Adicionais

Onde:

  • nome_usuário identifica o usuário de maneira única (normalmente seu login);
  • data e hora são auto-explicativos;
  • IP_origem é o IP pelo qual o usuário se conectou ao servidor;
  • IP_NAT é o IP pelo qual o usuário foi enxergado por outros servidores da internet, por meio de Tradução de Endereços de Rede (Network Address Table), técnica muito usada atualmente;
  • IP_destino é o IP de destino do servidor;
  • URL_destino é a URL do destino do servidor completa, incluindo pastas, subpastas e nomes de arquivo;
  • Protocolo_destino indica o tipo de protocolo utilizado na comunicação e, muitas vezes, o tipo de serviço de Internet utilizado (HTTP, BitTorrent, FTP, SSH, etc…);
  • Informações_adicionais são exatamente isso: informações adicionais para cada tipo de protocolo. Essas informações podem variar conforme o protocolo e portanto não são tão relevantes assim;

A formatação dos registros foi escolhida de um modo que gere logs que são facilmente parseados (analisados) por ferramentas razoavelmente simples de extrações de dados, encontradas em quaisquer instalações de servidores, além de permitir campos de tamanho variável, o que permite o registro adequado e sem limitações das informações trafegadas.
Parece simples, OK? Agora vem a pegadinha:
Imaginemos um provedor razoavelmente pequeno (com uns 100 usuários simultâneos). Por sua vez, imaginemos que cada registro de conexão IP tenha algo em torno de 2KBytes (2048 Bytes) e que cada usuário faça em torno de 100 chamadas IPs por segundo (parece muito, mas pode significar 100 emails baixados, ou 10 páginas acessadas com 9 fotos em cada uma). OK:

  • um único usuário gera 200K de logs por segundo.
  • Multiplicando isso por 60 segundos, temos 12000K por minuto (12MB aproximadamente).
  • Multipliquemos novamente por 60 para gerar o total por hora e teremos 720MB por hora (ou seja, mais de um CD).
  • Multiplicamos agora por 24 para o dia, alcançamos 17280 MB (17GB aproximadamente – ou 4 DVDs);
  • Multiplicando agora por 365 para um ano: 6205 GB (ou algo em torno de 6 Terabytes – trilhões de bytes);
  • E agora multipliquemos por 3 (o número de anos de retenção): chegamos a 18.1 Terabytes de dados!!!. Mesmo que você comprima isso com compressões de alto nível que garantam 50% de compressão (mais que isso pode acontecer, mas é muito difícil), chegamos a um total de 9 Terabytes de dados a serem conservados (o que inclui backups, etc).
  • E isso para apenas um usuário: multiplicando esses valores finais pelo número de usuários, chegamos a um total de 1800 Terabytes (quase 2 Petabytes – quatrilhões de bytes!!!!!!) ou 900 Terabytes (próximo a 1 Petabyte)

Embora possa-se alegar que a gravação de logs em meio óptico e outros meios de backup seja padrão (e realmente o é), temos ainda alguns problemas:

  1. como manipular essa massa gigantesca de informação? Mesmo sabendo o período no qual o crime ocorreu, como identificar as transações ilícitas (o que é o objetivo de manter-se tais logs) em tempo hábil? O processamento de uma massa de dados tão grande demanda muito tempo (pense no Imposto de Renda que, embora tenha 20K, é entregue por vários milhões de pessoas, e o quanto demora para que o mesmo seja processado e as restituições liberadas e você terá uma compreensão do tamanho do buraco);
  2. Como armazenar essa massa de dados? Mesmo o uso de meios ópticos de grande volume (Bluray, por exemplo), ou de sistemas de SAN (Storage Area Network) seriam complexos e custosos de serem mantidos apenas para esse fim. Além disso, uma boa parte do tempo que seria gasto na análise viria da reconstrução desses dados (que são, por motivos de confiabilidade, “espalhados” no meio físico) para seu formato “original”;
  3. Os custos serão repassados? O usuário terá que pagar para ser espionado? O governo dará subsídios? Quem pagará a conta?
  4. Os logs são confiáveis? Existem milhares de formas simples para “evadir-se” do sistema, por meio de proxies e sistemas similares (no caso do Cicagate eu falei um pouco sobre essas possibilidades). Como rastrear “evasões”? Além disso, como garantir que a pessoa não foi vítima de má-fé de outrem? Ou ele próprio teve sua senha roubada?

Mas isso ainda não é o pior:

O provedor dedo-duro

A legislação em questão, segundo o que o Sérgio Amadeu da Silveira expõe em seu blog,cria a idéia do “provedor dedo-duro”, ou seja, o provedor deverá informar imediatamente à justiça a suspeita de que tenha havido qualquer uso ilegal de sua rede. Conforme a lei diz, e cita o blog em questão:

Blog do Sergio Amadeu: SENADOR CRIA A FIGURA DO PROVEDOR DELATOR

“Art. 22. O responsável pelo provimento de acesso a rede de computadores é obrigado a:

III – informar, maneira sigilosa, à autoridade competente, denúncia da qual tenha tomado conhecimento e que contenha indícios da prática de crime sujeito a acionamento penal público incondicionado, cuja perpetração haja ocorrido no âmbito da rede de computadores sob sua responsabilidade.

§ 2º O responsável citado no caput deste artigo, independentemente do ressarcimento por perdas e danos ao lesado, estará sujeito ao pagamento de multa variável de R$ 2.000,00 (dois mil reais) a R$ 100.000,00 (cem mil reais) a cada requisição, aplicada em dobro em caso de reincidência, que será imposta pela autoridade judicial desatendida, considerando-se a natureza, a gravidade e o prejuízo resultante da infração, assegurada a oportunidade de ampla defesa e contraditório.”
A dúvida aqui é que existe a questão do sigilo na informação da polícia, sem que a pessoa tenha conhecimento de que sua privacidade está sendo violada e que sua navegação está sendo vigiada. Ou seja: mesmo que eu não faça nada ilegal, pelo fato de eu usar algo que possa ser usado para fins ilegais (como, no exemplo mais clássico o uso de redes P2P, como o BitTorrent), eu serei denunciado? Qual será minha chance de defesa? Por não fazer a menor idéia da época em que isso ocorreu, como preparar minha defesa? Ou seja, vemos aí uma séria ofensa a princípios como o da presunção de inocência e o da ampla defesa.
Além disso, existe um custo sério ao provedor que é: como ele irá se comportar?
O provimento de acesso à Internet pressupõe o acesso a todos os serviços que a mesma dispõe, incluindo o de acessar ferramentas como IRC e BitTorrent que, embora tenham usos ilegais, também tem muitos usos legais (muito conteúdo rico, como distribuições de Linux e filmes divulgados em Creative Commons como The Big Buck Bunny, são distribuidos por esses meios). Ou seja: ele irá impedir o uso desses protocolos (violando o contrato com o consumidor)? Irá entregar os usuários desses protocolos (que podem estar fazendo coisas legítimas e serem pegos em um linchamento moral, o que pode acarretar depois um processo contra o provedor)? Irá monitorar o tráfego dos usuários (como mostrado anteriormente, e ainda contando com um potencial ônus moral)?
E outra: como dizer que esses logs não se voltarão contra as pessoas em situações imprevistas (por exemplo, quando o seguro resolver negar o pagamento de um sinistro porque viu que o usuário acessava sites sobre doenças crônicas)? Ou seja: mesmo a navegação segura poderá se tornar perigosa.
Mas acha que acabou? Não! Essa lei ainda tem muito o que piorar!

A Net afetando o que está fora dela

Atualmente, qualquer pessoa pode (como sempre pode) gravar uma fita cassete com aquele CD seu e botar no toca fitas do carro para não perder sua inestimável coleção de Elton John (ou de Calypso, ou de Kraftwerk, ou das músicas do Balão Mágico) e ainda assim poder aproveitar muito o CD que adquiriu com seu dinheiro (em geral suado). O aluno pode xerocar pedaços de livros para fazer suas anotações para seu trabalho de TCC ou mesmo copiá-los à mão.
Mas essa lei trata de uma forma diferente o meio cibernético e suas inovações. Citando o Pedro Dória:
Senado aprova projeto nocivo à Internet Agora é a vez da Câmara

Ele transforma em crime o acesso a qualquer apetrecho ou mídia digital que tenha sido protegido. Celular bloqueado pela operadora? Não pode desbloquear sem expressa permissão. CD mesmo comprado que não permite cópia para o computador ou iPod? Mesmo que o indivíduo tenha comprado o disco, será crime.

Ou seja: posso escolher qualquer marca de carro, e qualquer gasolina para o mesmo, mas não posso comprar um celular em uma operadora e o chip em outra. Posso gravar uma fita do meu disco do Kraftwerk, mas nada de Home Computer no meu Computador Pessoal. Posso gravar um VHS do filme que passou na Sessão da Tarde, mas Star Wars no meu MP4 Player? Esqueça!
Ou seja, direitos que nos são dados como válidos acabaram sumindo!

Essa lei é necessária?

Me lembro de, há muitos anos atrás ter ido em uma finada COMDEX. Nessa ida, assisti uma palestra de um delegado da 4ª DIG (Delegacia de Investigações) do DEIC de São Paulo, especializada em crimes cibernéticos. Em uma época onde os conhecimentos e informações sobre a informática forense (ou seja, especializada no estudo de crimes cibernéticos) era pouco e disperso, ele falou algo que me deixou pensativo: “o anonimato na Internet não existe! Você consegue rastrear qualquer pessoa em qualquer lugar, basta saber o caminho das pedras.
Hoje, com o conhecimento que existe de Informática Forense, com suas várias técnicas de rastreamento de informações, cruzamento de informações de logs, fingerprint, reconstrução de dados apagados e por aí afora, é possível ao menos (diria eu) em 90% dos casos pegar-se as pessoas que cometem crimes na Internet, bastando boa intenção por parte da polícia e dos órgãos do Judiciário, sem a menor necessidade de novas legislações, com o uso do que já existe, sem a necessidade de provedores vigilantes e coisas do gênero. Basta apenas a correta eficiência e o uso do que a lei já oferece.
Essa legislação é perigosa para a privacidade do cidadão brasileiro. Ela é perigosa para o próprio princípio de liberdade de expressão. Pode provocar um pré-julgamento de pessoas apenas por terem falado coisas que vão contra os interesses de grandes poderes. Não respeita os direitos do cidadão. Está transformando o Brasil no Big Brother (o do 1984).
Pretendo ainda falar mais sobre isso, mas até lá, vou deixar alguns links. Leiam e reflitam:
http://observatorio.ultimosegundo.ig.com.br/blogs.asp?id={A6B7472E-99F8-4A56-87AD-620A557AA6C7}&id_blog=2
http://pedrodoria.com.br/2008/07/10/senado-aprova-projeto-nocivo-a-internet-agora-e-a-vez-da-camara/
http://samadeu.blogspot.com/search/label/contra%20PLC%20do%20Azeredo
http://www1.folha.uol.com.br/folha/informatica/ult124u420911.shtml
http://br-linux.org/2008/ja-era-senado-aprova-projeto-de-lei-da-internet-todos-os-acessos-deverao-ser-arquivados-no-provedor-por-3-anos/
http://www.cic.unb.br/docentes/pedro/trabs/nervosismo.html
http://www.softwarelivre.org/news/11765
http://info.abril.com.br/aberto/infonews/072008/10072008-12.shl
http://renata.org/post/comunicado-importante/
http://www.navegantes.org/index/2008/07/10/projeto-de-crimes-na-internet-passou-no-
http://www.softwarelivre.org/news/11746
http://www.fsfla.org/svnwiki/blogs/lxo/2008-07-04-novos-crimes-absurdos
http://www.fsfla.org/svnwiki/blogs/lxo/2008-07-01-do-celular-direto-pra-cela
http://www.softwarelivre.org/news/11759
http://vitorpamplona.com/wiki/Lei%20PLC%2089/03
http://www.nardol.org/2008/7/5/o-desafio-da-intangibilidade
http://fsfla.org/svnwiki/blogs/lxo/2008-07-02-navegando-pro-xadrez.pt
http://googlediscovery.com/2008/07/07/carta-aberta-em-defesa-da-liberdade-e-do-progresso-do-conhecimento-na-internet-brasileira/
http://www.navegantes.org/index/2008/07/08/o-projeto-de-lei-de-crimes-na-internet-e
http://a2kbrasil.org.br/Projetos-de-lei-transformam-em
http://www1.folha.uol.com.br/folha/informatica/ult124u420911.shtml

O Caso do Bloqueio do YouTube – Uma análise técnica

Um reblog de um post meu do meu antigo blog (dia 18/01/2007) para trazê-lo ao WordPress.com.


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:

  1. 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);
  2. 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;
  3. 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;
  4. 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;
  5. 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:

  1. 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;
  2. 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;
  3. 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;
  4. 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”;
  5. 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:

  1. 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;
  2. 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”;
  3. 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;
  4. 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;
  5. 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;
  6. 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…

Powered by ScribeFire.

Mais mancadas da Justiça Brasileira na Net: WordPress.com pode ser bloqueado a qualquer momento!!!

Pois é… A “justiça” brasileira se superou de vez: para bloquear um blog que deveria ser proibido por decisão judicial,  a ABRANET (Associação Brasileira de Provedores de Internet) decidiu aconselhar os seus associados a bloquear TODOS os blogs do WordPress.com (inclusive esse).
G1 > Tecnologia – NOTÍCIAS – Acesso a blogs do WordPress no Brasil pode ser bloqueado

“Ordem judicial não se discute, se cumpre. Mas, como não é possível bloquear especificamente o endereço solicitado, o acesso a todos os sites com a extensão wordpress.com será impedido no Brasil”, explicou ao G1 Eduardo Parajo, presidente da associação. (Grifo meu)

Isso não é verdade: o bloqueio de URLs específicas via proxy ou firewall de aplicação (camada 7) é algo não apenas possível, mas algo que é prática comum em empresas e ONGs, além de ser uma prática não apenas possível, mas aconselhável para parental control, ou seja, controle de conteúdos pornográficos e similares pelos pais.
Além disso, o uso desse tipo de mecanismo (seja por meio de IP Blocking ou URL Blocking), independente do motivo ou modo, é suscetível a proxing, seja por meio de cache proxing (como o Google) ou por proxy de roteamento (como a rede TOR). Foi a mesma coisa do Cicagate, onde, no fim das contas, a decisão judicial foi contornada.
O grande dilema é: porque o bloqueio a todos os blogs da WordPress.com? Não estamos falando apenas do blog em questão ou dos blogs brasileiros, mas sim a todos os blogs, SEM EXCEÇÃO. O que os legisladores precisam aprender é que o computador não conhece meio-termo: ou é ou não é. Ao bloquear a URL wordpress.com ou o IP do WordPress, você bloqueia TUDO, desde blogs miguxos até coisas realmente importantes.
Por isso mesmo, eu digo NÃO a essa aberração jurídica, mais uma em uma série de desastres jurídicos que o Brasil vem cometendo na Internet, por desconhecimento ou malícia. Pelos blogueiros honestos, que nada têm a ver com os problemas de um único, eu sou contra o bloqueio.

NÃO AO BLOQUEIO DO WORDPRESS.COM! A FAVOR DA LIBERDADE!

Powered by ScribeFire.

Cuidado ao nomear um Post

É engraçado as coisas que acontecem quando se toma certas decisões ao postar-se em um blog.
Eu escrevi recentemente no meu blog um post sobre algumas iniciativas que não achei interessantes, principalmente por tentarem enganar o usuário usando táticas similares às de Cybersquatting e a de redirecionamento de domínio. Como essas táticas são similares às usadas por sites pornográficos, acabei dando um título que deixava a entender isso: “O que a Microsoft e sites pornô têm em comum?“. Mas o mais engraçado foi quando eu comecei a acompanhar os resultados de acessos ao meu blog e me deparei com isso:


Resultados tirados no dia 07/04/2008

Ou seja, vários dias o site teve como principal post esse, que não era nem exatamente um post com muito conteúdo, mas mais um desabafo do que eu considerava ser um jogo injusto.
A descoberta maior (e mais bizarra) foi quando decidi investigar principalmente a opção do WordPress “Motores de Pesquisa”. Ela permite você ver como é que as pessoas foram parar em seu blog ao usarem motores de pesquisa como o Google, dizendo que termos de busca foram usados para chegar até seu blog. Veja que impressionante:


Resultados tirados no dia 07/04/2008

Ou seja, no final das contas parece que o meu blog tornou-se um blog de sacanagem. 😛

Achei muito engraçado isso, mas a coisa fica ainda mais divertida. O post sobre o qual estou comentando foi feito dia 27 de março (ou seja, a pouco mais de uma semana). Pedi para o WordPress me retornar quais foram os posts mais lidos na última semana e o resultado foi interessante.


Resultados tirados no dia 07/04/2008

Aqui é que reparamos a coisa: nessa semana, esse post recebeu mais de o dobro de acessos de alguns posts mais importantes, apenas por causa da palavra pornô incluído nele. Será que o pessoal não lê os resultados do Google não?
Isso é apenas um desabafo sobre como as coisas podem ser estranhas quando você utiliza os termos errados nos títulos de seus posts.

Powered by ScribeFire.