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:


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

MANIFESTO EM DEFESA DA LIBERDADE E DO PROGRESSO DO CONHECIMENTO NA INTERNET BRASILEIRA

Copiado as-is do Blog do Sérgio Amadeu:

A Internet ampliou de forma inédita a comunicação humana, permitindo um avanço planetário na maneira de produzir, distribuir e consumir conhecimento, seja ele escrito, imagético ou sonoro. Construída colaborativamente, a rede é uma das maiores expressões da diversidade cultural e da criatividade social do século XX. Descentralizada, a Internet baseia-se na interatividade e na possibilidade de todos tornarem-se produtores e não apenas consumidores de informação, como impera ainda na era das mídias de massa. Na Internet, a liberdade de criação de conteúdos alimenta, e é alimentada, pela liberdade de criação de novos formatos midiáticos, de novos programas, de novas tecnologias, de novas redes sociais. A liberdade é a base da criação do conhecimento. E ela está na base do desenvolvimento e da sobrevivência da Internet.
A Internet é uma rede de redes, sempre em construção e coletiva. Ela é o palco de uma nova cultura humanista que coloca, pela primeira vez, a humanidade perante ela mesma ao oferecer oportunidades reais de comunicação entre os povos. E não falamos do futuro. Estamos falando do presente. Uma realidade com desigualdades regionais, mas planetária em seu crescimento. O uso dos computadores e das redes são hoje incontornáveis, oferecendo oportunidades de trabalho, de educação e de lazer a milhares de brasileiros. Vejam o impacto das redes sociais, dos software livres, do e-mail, da Web, dos fóruns de discussão, dos telefones celulares cada vez mais integrados à Internet. O que vemos na rede é, efetivamente, troca, colaboração, sociabilidade, produção de informação, ebulição cultural.

A Internet requalificou as práticas colaborativas, reunificou as artes e as ciências, superando uma divisão erguida no mundo mecânico da era industrial. A Internet representa, ainda que sempre em potência, a mais nova expressão da liberdade humana. E nós brasileiros sabemos muito bem disso. A Internet oferece uma oportunidade ímpar a países periféricos e emergentes na nova sociedade da informação. Mesmo com todas as desigualdades sociais, nós, brasileiros, somos usuários criativos e expressivos na rede. Basta ver os números (IBOPE/NetRatikng): somos mais de 22 milhões de usuários, em crescimento a cada mês; somos os usuários que mais ficam on-line no mundo: mais de 22h em média por mês. E notem que as categorias que mais crescem são, justamente, “Educação e Carreira”, ou seja, acesso a sites educacionais e profissionais. Devemos, assim, estimular o uso e a democratização da Internet no Brasil.

Necessitamos fazer crescer a rede, e não travá-la. Precisamos dar acesso a todos os brasileiros e estimulá-los a produzir conhecimento, cultura, e com isso poder melhorar suas condições de existência. Um projeto de Lei do Senado brasileiro quer bloquear as práticas criativas e atacar a Internet, enrijecendo todas as convenções do direito autoral.
O Substitutivo do Senador Eduardo Azeredo quer bloquear o uso de redes P2P, quer liquidar com o avanço das redes de conexão abertas (Wi-Fi) e quer exigir que todos os provedores de acesso à Internet se tornem delatores de seus usuários, colocando cada um como provável criminoso. É o reino da suspeita, do medo e da quebra da neutralidade da rede. Caso o projeto Substitutivo do Senador Azeredo seja aprovado, milhares de internautas serão transformados, de um dia para outro, em criminosos. Dezenas de atividades criativas serão consideradas criminosas pelo artigo 285-B do projeto em questão. Esse projeto é uma séria ameaça à diversidade da rede, às possibilidades recombinantes, além de instaurar o medo e a vigilância. Se, como diz o projeto de lei, é crime “obter ou transferir dado ou informação disponível em rede de computadores, dispositivo de comunicação ou sistema informatizado, sem autorização ou em desconformidade à autorização, do legítimo titular, quando exigida”, não podemos mais fazer nada na rede. O simples ato de acessar um site já seria um crime por “cópia sem pedir autorização” na memória “viva” (RAM) temporária do computador. Deveríamos considerar todos os browsers ilegais por criarem caches de páginas sem pedir autorização, e sem mesmo avisar aos mais comuns dos usuários que eles estão copiando. Citar um trecho de uma matéria de um jornal ou outra publicação on-line em um blog, também seria crime.
O projeto, se aprovado, colocaria a prática do “blogging” na ilegalidade, bem como as máquinas de busca, já que elas copiam trechos de sites e blogs sem pedir autorização de ninguém! Se formos aplicar uma lei como essa as universidades, teríamos que considerar a ciência como uma atividade criminosa já que ela progride ao “transferir dado ou informação disponível em rede de computadores, dispositivo de comunicação ou sistema informatizado”, “sem pedir a autorização dos autores” (citamos, mas não pedimos autorização aos autores para citá-los). Se levarmos o projeto de lei a sério, devemos nos perguntar como poderíamos pensar, criar e difundir conhecimento sem sermos criminosos.
O conhecimento só se dá de forma coletiva e compartilhada. Todo conhecimento se produz coletivamente: estimulado pelos livros que lemos, pelas palestras que assistimos, pelas idéias que nos foram dadas por nossos professores e amigos… Como podemos criar algo que não tenha, de uma forma ou de outra, surgido ou sido transferido por algum “dispositivo de comunicação ou sistema informatizado, sem autorização ou em desconformidade à autorização, do legítimo titular”? Defendemos a liberdade, a inteligência e a troca livre e responsável. Não defendemos o plágio, a cópia indevida ou o roubo de obras. Defendemos a necessidade de garantir a liberdade de troca, o crescimento da criatividade e a expansão do conhecimento no Brasil. Experiências com Software Livres e Creative Commons já demonstraram que isso é possível. Devemos estimular a colaboração e enriquecimento cultural, não o plágio, o roubo e a cópia improdutiva e estagnante. E a Internet é um importante instrumento nesse sentido. Mas esse projeto coloca tudo no mesmo saco. Uso criativo, com respeito ao outro, passa, na Internet, a ser considerado crime.
Projetos como esses prestam um desserviço à sociedade e à cultura brasileiras, travam o desenvolvimento humano e colocam o país definitivamente para debaixo do tapete da história da sociedade da informação no século XXI. Por estas razões nós, abaixo assinados, pesquisadores e professores universitários apelamos aos congressistas brasileiros que rejeitem o projeto Substitutivo do Senador Eduardo Azeredo ao projeto de Lei da Câmara 89/2003, e Projetos de Lei do Senado n. 137/2000, e n. 76/2000, pois atenta contra a liberdade, a criatividade, a privacidade e a disseminação de conhecimento na Internet brasileira.

André Lemos, Prof. Associado da Faculdade de Comunicação da UFBA, Pesquisador 1 do CNPq.

Sérgio Amadeu da Silveira, Professor Titular Faculdade Cásper Líbero, ativista do software livre.

Henrique Antoun, Prof. Associado da Escola de Comunicação da UFRJ, Pesquisador do CNPq.

Fernanda Bruno, Coordenadora da Linha Tecnologias da Comunicação e Estéticas do PPGCOM/UFRJ.

João Carlos Rebello Caribé, Publicitário e Consultor de negócios em Midias sociais.

Mônica Schieck, Doutoranda PPGCOM / ECO – UFRJ

José Maurício Alves da Silva, Jornalista e Programador Visual

Rogério da Costa, Filósofo, Prof do programa de pós-graduação em Comunicação e Semiótica da PUCSP.

Suely Fragoso, Professora Titular da Unisinos, Pesquisadora CNPq Nível II

Fátima Cristina Regis Martins de Oliveira, Coordenadora Adjunta do Programa de Pós-Graduação em Comunicação da UERJ.

Laan Mendes de Barros, Professor titular da Faculdade Cásper Líbero.

Marcos Palacios, Professor Titular, Faculdade de Comunicação, Universidade Federal da Bahia.

Marta Vieira Caputo – PPGCOM – UNESP – Bauru – SP.

Prof. Dr. Evandro Vieira Ouriques, Coordenador do Núcleo de Estudos Transdisciplinares de Comunicação e Consciência-NETCCON.ECO.UFRJ e membro do Global Panel do Millennium Project da World Federation of United Nations Associations-WFUNA.

Paulo Carneiro da Cunha Filho, Coordenador do Programa de Pós-graduação em Comunicação da
Universidade Federal de Pernambuco.

Eduardo Freire, Coordenador do Curso de Jornalismo da Unifor.

Simone Pereira de Sá. Prof Adjunta – Dep de Mídia – UFF.

Profa. Regina Gomes, Universidade Católica do Salvador.

Raquel Recuero, Programa de Pós-Graduação em Letras UCPel.

Suzana Oliveira Barbosa, Doutora em Comunicação e Cultura Contemporâneas pela UFBa e integrante do Grupo de Pesquisa em Jornalismo Online, GJOL/UFBA.

Gerson Luiz Martins, Grupo de Pesquisa em Ciberjornalismo (CIBERJOR/UFMS), Universidade Federal de Mato Grosso do Sul – UFMS.

Tattiana Teixeira – Jornalista. Pesquisadora e Professora de Jornalismo na Universidade Federal de Santa Catarina (UFSC).

Adriana Amaral – Professora Adjunta e Pesquisadora do Mestrado em Comunicação e Linguagens da UTP.

José Carlos Ribeiro – Prof. Associado ao Programa de Pós-graduação em Comunicação e Cultura Contemporâneas da Universidade Federal da Bahia (UFBA).

André Olivieri Setaro, Faculdade de Comunicação, Universidade Federal da Bahia.

Sebastião Carlos de Morais Squirra, Universidade Metodista.

Eduardo Meditsch – Universidade Federal de Santa Catarina

Suzy dos Santos, professora da Escola e do Programa de Pós-Graduação em Comunicação da UFRJ.

Lia da Fonseca Seixas, Doutoranda em gêneros jornalisticos, Universidade Federal da Bahia.

Mirna Tonus, Universidade de Uberaba (UNIUBE)

Thiago de Morais Lins, estudante de Comunicação Social/ Jornalismo UFRJ

Paola Barreto Leblanc – Cineasta e Mestranda do PPG COM / ECO – UFRJ

Helen Amorim, publicitária e economiária

Cristiane de Magalhães Porto, Doutoranda do Programa Multidisciplinar de Cultura Contemporânea da Faculdade de Comunicação – UFBA.

Cláudio Renato Zapalá Rabelo, professor da Unidade de Conhecimento Comunicação Social da Faesa-ES, Novas tecnologias.

Yuri Almeida – Jornalista e pós-graduando na FJA/Ba.

Carlos Alberto Ferreira Lima, Professor da Universidade de Brasília.

Adalci Righi Viggiano, Mestre em Educação Tecnológica – CEFET-MG, Profa. Virtual da UFScar, Profa. do Cefet-MG e Profa. da Newton Paiva Virtual.

Jacques Jules Sonneville – UNEB Universidade do Estado da Bahia.

Marcia Benetti – professora do PPGCOM da UFRGS e diretora científica da SBPJor (Associação Brasileira de Pesquisadores em Jornalismo)

Francisco José Paoliello Pimenta, Professor Associado II Faculdade de Comunicação da UFJF
Campus de Martelos, Juiz de Fora – MG.

Jan Alyne Barbosa e Silva – UFBA.

Mauro Betti, Universidade Estadual Paulista- Campus de Bauru, Faculdade de Ciências
Departamento de Educaçao Física.

Fabiano Mazzini Bonisem, Prof. das Faculdades Integradas São Pedro – FAESA.

Solimar Garcia. Jornalista e Professora Universitária dos cursos de Gestão da UNIP – São Paulo.

Denise Maria Cogo, Professora do PPG em Comunicação da Unisinos, RS.

Ronaldo Henn – Professor pesquisador do PPG em Comunicação da Unisinos, RS.

Douglas Dantas Cardoso Gardiman – Sindijornalistas/ES

Leôncio Caetano de Farias, Graduando em Ciências Sociais – UFMG, Bolsista PIBIC – CNPq.

Paulo Munhoz, integrante do Gjol grupo de pesquisa em jornalismo on-line da UFBA.

Marcos Alves, Estudante de Jornalismo da Universidade Federal do Espírito Santo.

Macello Santos de Medeiros. Doutorando em Comunicação (FACOM/UFBA) e Professor do Centro Universitário Jorge Amado.

Roberto Abdala Junior, Centro Universitário do Leste de Minas – UnilesteMG, Cel. Fabriciano, Vale do Aço.

Alessandra Carvalho, prof. das Faculdades Integradas S. Pedro, Vitória-ES.

Beatriz Martins, Doutoranda ECA – USP, Pesquisadora do Colabor – USP.

Simone do Vale, Doutoranda ECO/UFRJ.

Erly Vieira Jr – Mestre em Comunicação, Imagem e informação pela UFF, Doutorando em Comunicação e Cultura pela UFRJ, escritor e cineasta.

Brunella de Lima França – Estudante de Jornalismo da Universidade Federal do Espírito Santo

Carla Andrea Schwingel – Doutoranda em Jornalismo Digital e Mestre em Cibercultura pelo Ciberpesquisa – PósCom-UFBA.

Marcelo De Franceschi, Com. Social – Jornalismo Universidade Federal de Santa Maria – RS
Diretório Acadêmico Mario Quintana (DACOM).

Júlio Vitorino Figueroa, mestrando em Comunicação e Cultura Contemporânea pela Universidade Federal da Bahia.

Josemari Poerschke de Quevedo, Mestradando no PPGCOM UFRGS em Comunicação e Informação.

Rogério Christofoletti, Professor e pesquisador do Mestrado em Educação da Univali (SC).

Maria Lucilia Borges, Mestre e Doutoranda em Comunicação e Semiótica – PUCSP.

Karina Gularte Peres – Graduanda em Jornalismo/UCPel.

Marcos Aurélio Júnior, técnico especializado da webradio Uni-BH, mestrando em Comunicação Social pela UFMG.

Luciana Scuarcialupi, Ação Cultura Digital do Programa Cultura Viva do Ministério da Cultura.

Uirá Porã, Ativista do conhecimento livre.

Graciela Selaimen, Coordenadora executiva do Nupef/Rits – Núcleo de Pesquisa, Estudos e Formação da Rede de Informações para o Terceiro Setor.

José Carlos Ribeiro – Prof. Associado ao Programa de Pós-graduação em Comunicação e Cultura Contemporâneas da Universidade Federal da Bahia (UFBA)

Silvana Louzada – UFF

Carlos Henrique Falci, Professor Adjunto III – PUC Minas; Membro do grupo de pesquisa Comunicação e redes hipermidiáticas do CNPq.

Marcelo Träsel, mestre em Comunicação e Informação, professor-assistente do Faculdade dos Meios de Comunicação Social da PUCRS, consultor em mídias sociais.

Iara Regina Damiani/NEPEF/UFSC

Herberto Peil Mereb Coordenador Organizacional da ONG AMIZ – Unidade de Formação e Capacitação HUmana e Profissional.

Ana Márcia Silva – Universidade Federal de Goiás.

Carlos Frederico de Brito d’Andréa, Universidade Federal de Viçosa.

Prof. Dr. Francisco Laerte Juvêncio Magalhães, Universidade Federal do Piauí

Erik Oliveira.

Paulo Francisco Slomp. Professor da Faculdade de Educação da Universidade Federal do Rio Grande do Sul.

Marcos Cavalcanti, Coordenador do Crie – Centro de Referência em Inteligência Empresarial

Fábio Malini – Jornalista e Professor na Universidade Federal do Espírito Santo

Alex Primo – professor do Departamento de Comunicação da UFRGS

Rodrigo José Firmino, Professor em Gestão Urbana, Arquitetura e Urbanismo do Programa de Pós-graduação em Gestão Urbana, Pontifícia Universidade Católica do Paraná – PUCPR.

Bruno Fuser, Coordenador do NP Comunicação para a Cidadania – Intercom.

Sergio Bicudo, Multimeios PUC-SP.

Lilian Starobinas, Doutoranda – FE-USP

Ana Laura Gomes – Senac/SP

Itania Maria Mota Gomes, Doutora, professora do Programa de Pós-Graduação em Comunicação e Cultura Contemporâneas/UFBA.

Verônica L. O. Maia, Antropóloga, consultora de projetos culturais e pesquisas.

Adilson Vaz Cabral Filho, Professor adjunto – Universidade Federal Fluminense.

Lylian Coltrinari, Professor Associado/FFLCH-USP.

Aníbal Francisco Alves Bragança, Professor e pesquisador (UFF – CNPq).

Gilberto Pavoni Junior, jornalista.

Marcelo Bolshaw Gomes, jornalista, doutor em ciencias sociais e professor de comunicação da UFRN.

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.

OOXML = ISO 29500 – Microsoft Ganha, todos perdemos

Pois é Aconteceu o que temíamos: o OOXML agora é o ISO 29500 (com link apenas para que não achem que isso é um “1° de Abril” atrasado). Com uma série de defeitos técnicos e irregulariedades, e contando com o voto de “importantes países” como Azerbaijão, Costa do Marfim, Casaquistão, e Trinidad e Tobago, a Microsoft conseguiu seu intento e agora OOXML é um “padrão internacional”.
Ou seja: ela ganha, nós perdemos.
Por favor, não me venham dizer aquele positivismo polianista de que tudo está OK e que veremos implementações livres do OOXML logo. Sinceramente, um padrão de 6000 páginas, cheia de problemas técnicos e incertezas jurídicas, sobre os quais eu cansei de falar nesse blog, e que foi comentado por muita, muita gente, apenas fez com que a Microsoft conseguisse uma ferramenta para legitimar seu monopólio e ao mesmo tempo minou completamente a legitimidade da ISO, vítima de suas próprias decisões e da má-fé de Redmond. Mesmo que não houvessem os riscos de “patente submarina” (prefiro o termo “campo minado de Propriedade Intelectual”), a complexidade dos padrões e as questões dos artefatos de implementação complicam e muito o desenvolvimento de uma solução à parte da Microsoft de implementação do OOXML. Essa é a preocupação justamente do pessoal da ODF Alliance:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The process itself brought to the fore OOXML’s deficiencies that will prevent its use by public administrations, chief among them that OOXML remains a “community of one”—undocumented features, IPR restrictions, and features and functionality linked to other Microsoft products that will prevent OOXML’s use in other software products. (…) Nothing about the process will provide governments with any more confidence in OOXML’s openness and interoperability than they had before the vote.

Traduzindo:

O próprio processo [de padronização] trouxe à luz todas as deficiências que irão impedir o uso do OOXML na administração pública, a começar pelo fato de que o OOXML continua sendo uma “comunidade de uma pessoa só” – recursos não documentados, restrições relacionadas a Propriedade Intelectual, e recursos e funcionalidades ligadas a outros produtos Microsoft que o impedirão de ser usado com outros produtos (…) Não houve nada nesse processo que ofereceu aos governos qualquer confiança adicional na abertura e interoperabilidade do OOXML. (Grifos Meus)

Ou seja, qual a confiança que um governo, que possui necessidades críticas em vários sentidos quanto a documentação, possui de adotar o OOXML? Quais as garantias de compatibilidade, interoperabilidade, abertura e transparência do mesmo? Quais são as garantias que, uma vez que um governo crie uma estrutura baseada no OOXML, independente de utilizar produtos Microsoft ou não, ele poderá o fazer sem riscos e sem a possibilidade de processos por patentes ou qualquer outro tipo de infração de propriedade intelectual?
Governos necessitam armazenar documentos por 10, 20, 30, até mesmo 50 anos dependendo o documento, apenas pelo caráter legal. Confiar em um formato onde, a qualquer momento, uma pessoa, não importa qual, pode simplesmente dizer que vai levar a bola para casa e pior, que todo mundo que jogou com ele vai ter que pagar por ter usado a bola, é algo para dizer o mínimo temerário.
Isso é uma coisa que não poderia passar, como não passou e a ODF Alliance comenta:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The vote shined a spotlight on OOXML that will not dim. Only in response to growing public pressure has Microsoft promised to make changes to OOXML, and, to be sure, similar promises have been made on numerous occasions. To avoid any questions concerning the legitimacy of the vote, which included many documented irregularities, Microsoft needs to ensure that these promises made to national standards bodies are actually delivered.

Tradução:

A votação [de padronização da ISO] acendeu um sinal de alerta no OOXML que não irá apagar-se. Foi apenas graças à pressão pública que a Microsoft prometeu fazer mudanças no OOXML, o que, para ser sincero, já aconteceu antes em várias ocasiões. Para evitar questões relacionadas à legitimidade da votação, que inclui muitas irregularidades documentadas, a Microsoft tem que garantir que essas promessas feitas aos órgãos nacionais [de padronização] sejam realmente cumpridas. (Grifos meus)

Agora, será que isso acontecerá? De uma maneira otimista, eu gostaria que sim: gostaria de ver maior interoperabilidade entre os vários produtos. Porém, conhecedor do retrospecto (me sinto tentado a usar o termo karma) da Microsoft, não vejo como ter tais esperanças.
A ISO também sai perdendo nesse processo. Ao deixar que uma série de irregularidades ocorre-se (e perceba que a participação da Microsoft em vários NBs ou de seus Partners não é em si tal coisa), ela comprometeu todos os fundamentos que a tornavam digna de crédito: ao abaixar a cabeça para não ver o que aconteceu em vários países, ela acabou recebendo e aceitando sua parcela de culpa por um processo que, a meu ver, foi feito de maneira completamente errada. E se você acha que isso é blá-blá-blá meu, veja no mapa abaixo o tanto de caveiras que existem no mapa (cada caveira indica um país onde foram constatadas irregulariedades sérias no processo):

Clique para ampliar

Desse modo, o que aconteceu é que a ISO, ao “fechar-se em copas” em relação a essas falhas sérias do OOXML acabou perdendo muita coisa:

R.I.P. International Standards Organization « Adventures in a Perambulator

A failure, on the part of ISO, in so re-evaluating this situation during the next 2 months will result in my calling into question anything considered a standard by ISO. Any government, organization, agency or other that uses ISO as the authority for anything being a standard will be asked to prove that it actually is a standard: ISO authority will not be an acceptable response. It is my opinion that by this action of approving MSOOXML as a standard, ISO has demonstrated that it lacks the qualifications to adequately evaluate technical material and has further shown that its ethical behavior is subject to the highest bidder.

Traduzindo:

Uma falha por parte da ISO em reavaliar essa situação [de considerar padrão qualquer coisa que lhe seja empurrada goela abaixo] nos próximos dois meses me levará a questionar qualquer coisa que a ISO considere padrão. Qualquer governo, organização, órgão ou afim que use a ISO como autoridade para qualquer coisa que seja considerada um padrão deverá se questionar se realmente isso é um padrão: apenas a autoridade da ISO não será mais uma resposta aceitável. Na minha opinião, ao aprovar o MSOOXML como um padrão, a ISO demonstrou ter perdido as qualificações para adequadamente avaliar materiais técnicos e também demostrou que seu comportamento ético é digno de intenso repúdio. (Grifos meus)

Deixando-se penetrar por um processo que, embora tenha seguido (ainda mal-e-mal) a letra da norma, foi corrompido por trás dos panos por uma série de questionamentos, irregulariedades, lobbies e afins, a ISO perdeu (ou ao menos manchou) sua credibilidade. Se tal aprovação viesse de um consenso, seja por Fast-Track ou não, a ISO manteria sua credibilidade. Porém, ao aceitar as pressões de Redmond e não questionar como as coisas ocorreram nos países, aceitando passivamente isso, ela deixou essa credibilidade ser maculada (de maneira permanente, potencialmente) e, desse modo, colocou em xeque TODOS os padrões ISO. Alguns, como ODF, PDF e ISO 9000 escaparam ilesos, uma vez que são reconhecidos não apenas por meio da ISO, mas por suas próprias qualidades. Os demais, porém, passarão a ser questionados cada vez mais.
Eu duvido que em algum momento os questionamentos feitos foram realmente levados a sério. Parece choradeira de mau perdedor, mas se você ler os artigos do meu blog sobre o assunto, você verá que em si não sou contra o OOXML. O que eu sou contra é que, como colocado, o OOXML é uma forma de obter-se um crivo internacional a um monopólio que vem a dar poderes ilimitados apenas a uma empresa.
Não vou continuar repetindo meus entendimentos sobre o OOXML: basta ler aqui no meu blog todos os artigos que escrevi sobre o assunto. Porém, o que vou afirmar é que, a não ser que o processo de padronização do OOXML seja revertido, ninguém mais confiará na ISO e ela irá obter a mesma reputação que a Microsoft (que não é lá muito boa).
Gostaria de citar o desabafo do Jomar, alguém que camelou demais e viu seus esforços por um padrão realmente técnico e correto ser atropelado por um rolo compressor vindo de Redmond:


OpenXML: Eles realmente ganharam ? | void life(void)

Se a decisão é de que problemas são “coisinhas”, ela não foi técnica e portanto ganhamos todos um grande exemplo de onde se chega quando se coloca a boa técnica de lado (ou alguém aí consegue, sem consumir substâncias alucinógenas, acreditar que ter CINCO RECOMENDAÇÕES OFICIAIS PARA SE ESCREVER UMA SIMPLES DATA é algo lógico e natural !!! E que isso ainda irá contribuir para o aumento da interoperabilidade ?). Prá falar a verdade, como fã de Rock’n Roll eu até que vi um bom “revival” da lisergia dos anos 70 nisso tudo (pois só com muito LSD na cabeça eu talvez conseguisse explicar e defender publicamente a tese de que uma só norma internacional é na verdade cinco que na verdade possue duas cláusulas de conformidade que a torna dez sendo ao mesmo tempo uma… fiquei até tonto só de pensar nisso para poder escrever…e olha que eu não tomei nada, heim…).

Ou seja, na realidade, a ISO e todo o processo do Fast-track foi apenas uma forma da Microsoft conseguir um Selinho de ISO para o Office 2007. Sabe, como os selinhos ISO-9000 que qualquer empresa deseja para mostrar que seu produto é o máximo, ainda que ele seja uma porcaria… ainda que seja a mesma porcaria o tempo todo? Como um padrão com redundâncias, discrepâncias, contradições e afins passou pela ISO, que deveria zelar pela qualidade técnica?
E para realmente terminar esse post, deixo as mesmas perguntas do Jomar à Microsoft:

OpenXML: Eles realmente ganharam ? | void life(void)

  1. Quando o Microsoft Office vai suportar a IS 29500 (ele agora suporta apenas o ECMA-376, que é uma especificação diferente) ? E quais delas serão suportadas (IS 29500-1, IS 29500-2, IS 29500-3, IS 29500-4, IS 29500-5) com quais classes de conformidade (viu como agora vai ser bem fácil comprar uma suite de escritório que suporte o OpenXML…) ?
  2. Quando sai o próximo Service Pack do OpenXML ?
  3. Vocês já prepararam algum mecanismo de Auto-Update na ISO ? Vai ser via plug-in ou via backdoor mesmo ?

Por isso, apesar de tudo isso, continuo apoiando o ISO 26300 (ODF) como o verdadeiro formato de documentos padrão.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.