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.

A sujeira continua a aparecer no OOXML

A verdade está aparecendo cada vez mais no OOXML, e de como o processo está se tornando não apenas estranho, mas totalmente fora de ordem. Hoje, o Jomar postou algumas informações sobre o que diabos aconteceu realmente no BRM: na realidade, a famosa “Lei do Silêncio” não foi ‘esclarecida’ (perceba a ironia aqui). A questão não é de que havia algum tipo de “Lei de Silêncio”, mas sim de que os participantes deveriam (não seriam obrigados) a permanencer em silêncio quanto a esses eventos… É engraçado que isso tenha sido colocado agora, quando todos ficaram calados, enquanto outras partes interessadas utilizaram-se desses valores para tentar “passar a perna” no debate. Isso mostra como essas coisas são úteis para aqueles que querem trapacear processos ISO.
Como sempre, o Jomar manda muito bem ao esclarecer as coisas: ele se preservou enquanto não tinha a certeza de poder ou não comentar o processo, o que mostra que ele é um cara ético. Agora, porém, ele resolveu “rasgar o verbo”:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Como informado no meu penúltimo post, entrei en contato com a ISO e o IEC (na verdade com o Gabriel Barta do ITTF), e ele me esclareceu que apenas “recomendou” que os detalhes não fossem revelados e que não pode fazer nada contra isso (nem contra a Microsoft, nem contra este pobre delegado). Além disso me disse que eu posso falar o que quiser, mas mantém a recomendação… Tá bom…obrigado pelo conselho…

E vamos ver o que o Jomar tem a dizer:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Para iniciar a história, na reunião de véspera do BRM, os Chefes de Delegação (HoD) foram avisados que na quarta feira teriamos todos que tomar uma decisão sobre o que fazer com as propostas do ECMA que não pudessem ser discutidas.

Vamos entender o que aconteceu: o BRM, que em teoria deveria resolver todos os problemas do padrão em estudo, ao invés de debater todos os problemas do padrão simplesmente fez uma postura de João-Sem-Braço, ignorando a função básica do BRM de alcançar um consenso normativo (como dito anteriormente) ignoraram sumariamente uma massa completa de inconsistências e erros, conforme citado pelo Cezar Taurion da IBM. Desse modo, além de perder-se fundamentalmente o objetivo principal do BRM, fez-se uma espécie de “padronização a toque de caixa” que demonstra que não houve por parte dos principais interessados nesse caso (ECMA e Microsoft) de u debate completo e técnico quanto ao formato.
Continuando, o Jomar explica como é feito o debate das contradições durante o BRM, e mostra uma coisa MUITO interessante:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

O forma de trabalhar adotada nos dois primeiros dias de reunião (e no papel funciona que é uma beleza), cada um dos países presentes (na verdade os chamados National Bodies ou NBs e se não me engano eram 33) poderiam apresentar para a discussão uma das propostas de seu interesse (ou seja, em ordem alfabética cada um apresentava um problema). O debate então se iniciava e caso fosse muito polêmico, os NBs envolvidos com a discussão eram convidados a discutir “off-line”, colocando o assunto para um backlog. Toda discussão terminava em instruções de alteração para o editor e qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada.
O resultado disso é que até sexta feira, sequer duas rodadas completas foram realizadas (ou seja, houve NB que pode apresentar só uma vez) … explicação: Falta de Tempo (que aliás, explica todas as demais decisões tomadas lá, ok ?). (grifos meus)

Alguns detalhes a ressaltar:

  1. Perceba que cada NB podia apresentar por rodada um único problema. O dilema é: alguns NBs, como o brasileiro, tinham listas enormes de problemas a serem questionados. Mesmo considerando-se a possibilidade de um mesmo problema ser apresentado por vários NBs, como é que todos poderiam ser investigados dessa forma.
  2. O Jomar diz que “qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada“. Ou seja, uma série de fatores que importantes, como a questão do mapeamento de binários entre outros foi simplesmente chutados para escanteio sumariamente. Desse modo, como pode-se alcançar um melhor esclarecimento sobre essas questões? Principalmente em um padrão lotado de artefatos de implementação (wrapLikeWord95 e afins)?

Mas ainda assim as coisas continuam piorando:
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Durante os debates, algumas discussões acabavam se expandindo e abrangendo mais do que uma resposta (ou as vezes as respostas tratavam de temas coligados) e isso explica o elevado grau de itens discutidos (ou como prefiro chamar “tocados”) no BRM (retirado deste documento, o documento final do BRM): 189 respostas ou 18,4 % do total (isso é que é o que se espera de um debate internacional sobre uma norma de tamanha relevância, não é mesmo… Já imaginou se nossa constituição fosse escrita assim, com apenas 18% das leis discutidas e analisadas ?).

Alguém vai falar: “18,4% não é bom?” Não, não é? Isso é um padrão internacional: em um mundo globalizado, a troca de informações (e portanto de documentos) por meios digitais assumirá cada vez mais uma importante função nas empresas de todos os portes e nos governos, e até mesmo nas relações pessoais. Um formato mal-padronizado, com “minas terrestres de patentes”, cheio de furos técnicos, redundante, e simplesmente complexo demais deveria ser aprovado com tão pouco debate em cima do mesmo? Como o Jomar disse: “Isto significa que especialistas do mundo todo foram a Genebra para resolver apenas 18,4 % de um tremendo problema. O resto (81,6%) foi “dado um jeitinho”.
Mas vocês acham que acabou? Não, ainda tem mais!

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Aliás, me reservo o direito de não comentar aqui o que levou a aprovação desta proposta [da transformação da especificação em uma Multi-Part standard, na qual o Brazil apresentou uma objeção], que na verdade transforma o OpenXML (ou a DIS 29500) em singelas cinco normas internacionais que poderão ter vida própria (única diferença de cinco normas “tradicionais” é a sua numeração compartilhada, DIS 29500-1, DIS 29500-2 … DIS 29500-5). Lindo isso, não ?

Ou seja, existiram coisas tão atrapalhadas (ou intencionalmente manipuladas), que o Jomar se absteve de comentar. Em uma situação como essa, o que leva a pessoa a se abster, senão um processo terrivelmente mal-feito (ou intencionalmente manipulado).
Agora, vem uma parte importante desse post do Jomar e uma resposta para muitas coisas: de onde a Microsoft tirou a questão dos 98% de aprovação dos comentários ao OOXML?!
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Quando chegou a quarta feira, nos foram apresentadas quatro opções de “destino” às demais respostas (ou seja, 81,6% do total). Eram apenas quatro opções e uma delas deveria ser escolhida (na hora eu me lembrei do filme “A escolha de Sofia”):
1 – Todas rejeitadas.
2 – Todas aprovadas.
3 – O ITTF decide tudo.
4 – Decisão por voto em lote (com a possibilidade de declaração de voto individual para cada resposta e/ou definição de um voto global, do tipo “aceito tudo”).
Evidentemente que a opção menos ridícula era a opção 4 e por isso ela foi aprovada (no documento final existe uma cópia da cédula de votação). Muito foi debatido sobre a possibilidade de que alguns NBs fizessem votos de bloqueio (como votar tudo sim para forçar a aprovação ou tudo não para desaprovar), mas nada poderia ser feito a este respeito…
Houve um protesto muito interessante de uma delegação que disse que não tinha ido até a Suiça para votar, que poderia fazer isso de casa e a resposta: “Paciência… a vida é assim” .
Outro NB protestou dizendo que só recebeu o documento contendo as respostas para seus próprios questionamentos e não tinha tido a oportunidade sequer de analisar as demais respostas. Por isso foi criada a opção “Não quero registrar uma posição” na cédula. O problema apontado ocorreu com outros NBs e portanto, teve NB que votou em propostas que nunca leu !!! (legal isso, né ?).
(…)
Fiz questão de contar isso apenas para que seja pública a explicação aos 98% de aprovação que certas empresas andam utilizando mundialmente.
Viu como agora os 98% não significam absolutamente nada ? E os 18,4%… estes sim merecem ser debatidos (e explicados por alguém).

Repare aqui a questão: houve uma verdadeira “aprovação em massa” de uma série de questões importantíssimas e que foram simplesmente ignoradas pela ISO. Desse modo, como confiar no OOXML? Como desenvolver para isso? Qual a segurança que temos de que os documentos irão abrir corretamente, mesmo no Microsoft Office 2007? Quais são as garantias que o esforço potencial para desenvolver-se sistemas que abram e manipulem tais formatos não será jogado fora ao perceber-se que os documentos resultantes não abrem ou oferecem informações errôneas em outros sistemas compatíveis com esse formato? Pequenas discrepâncias são aceitas (grave um documento no OOo e abra no Lotus Symphony da IBM e você poderá ter isso), mas quais são as garantias?
A postura brasileira de Dizer NÃO ao OOXML está correta por tudo isso: esse formato é simplesmente horrível e não tem condições de fazer NADA ao que se propõe a fazer. Aprovar o OOXML agora é transformar a ISO em um órgão de “ceder selinhos” para empresas, o que desvritualizaria tudo o que a ISO representa. A ISO não é perfeita (X.25 alguém), mas muitos padrões que ela divulgou foram adotados a partir de um consenso e tornaram-se importantes no mercado (os próprios padrões ISO 9000 são exemplos).
Se o OOXML passar agora, vai ser a submissão da ISO à Microsoft e resultará em um lock-in oficializado, uma vez que até agora, à exceção dos produtos Microsoft, não existe nada que abra os documentos OOXML do MS Office 2007 corretamente. Sendo que atualmente ainda é impossível desassociar o OOXML do MS Office (o que acontece com o ODF em relação ao seu “software de referência”, o OpenOffice.org), temos uma situação como nunca foi vista na ISO: uma única empresa poder oficializar um gigantesco monopólio por meio de um padrão “consolidado de um consenso”.
Quem tem a ganhar nesse caso? O Brasil ou a Microsoft? Sua empresa ou a Microsoft? Você ou a Microsoft?
Pense muito nisso…

Office OpenXML (OOXML) e inapto pela ISO 29500


Powered by ScribeFire.

“Something wicked this way comes…”

Apesar do título, não, esse post não tem nada em absoluto a ver com Harry Potter. Mas como diz a música Double Trouble, “algo sinistro está vindo aí”.
No dia 29 desse mês, haverá a decisão final da ISO sobre a aprovação ou não do formato OOXML como padrão ISO. Como já falei anteriormente, existem coisas que estão extremamente complicadas sobre ele. Já disse também que existe uma série de defeitos técnicos no formato, além de uma série de implicações relacionadas à questão do Open Specification Promise (Promessa de Especificações Abertas) da Microsoft e da Covenant Not to Sue (Acordo Contra Processos) da mesma. Inclusive, recentemente o César Taurion da IBM deixa muito claro isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

Mais, não é só. Também é impossivel alguém dizer que existem 100% de certeza quanto a resolução dos vários problemas de propriedade intelectual que foram encontrados nos documentos Open Specification Promise (OSP) e Covenant Not to Sue da Microsoft. Nestes documentos lêem-se: “claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification”. E “promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification…”.
O que isto signfica na prática? Que a promessa não cobre as especificações que “are not described in detail”, que são muitas; que limita a liberdade de uso à sintaxe da especificação, mas não a “application behavior” que estão espalhados nas suas mais de 6.000 páginas; e não inclui patentes das subsidiárias e afiliadas da Microsoft. E um ponto importantíssimo: a OSP é limitada a atual versão do OpenXML! Fica então a pergunta: o que acontecerá com as próximas e inevitáveis versões da especificação?

Como comentamos anteriormente nesse mesmo blog, e o Taurion ressalta no post dele, é impossível determinar claramente se o OSP e o CNS cobrem software livre. Na realidade, ela já foi considerada insegura pela Software Freedom Law Center para implementações livres do OOXML, e por diversos motivos. Ou seja, como algo que pode ser um verdadeiro “campo minado” de Propriedade Intelectual pode tornar-se um padrão ISO?
Podemos entender isso da seguinte forma. que o Avi Alkalay da IBM apresenta: a Microsoft não está tentando promover interoperabilidade (onde o que importa é o padrão e os produtos disputam entre si para ver qual o melhor), mas sim uma intraoperabilidade (onde o produto é importante e favorecem um produto em detrimento aos demais). Pode parecer uma diferença pequena, mas compare as seguintes imagens que o Avi publicou em seu site:


Esse é um exemplo de Interoperabilidade

Esse é um exemplo de intraoperabilidade

A coisa toda, porém, continua ficando cada vez mais estranha conforme você vai acompanhando os posts. Por exemplo, a Microsoft comemora o fato de que 98% das contradições (problemas) do OOXML tinham sido modificados e aprovados. Até que ponto isso é verdade? E se não foi, por que?

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

(…) Embora alguns digam que a reunião foi um sucesso, com 98% dos comentários sendo resolvidos, indiscutivelmente que a realidade é outra. Cerca de 80% dos comentários não foram sequer analisados e da votação que se seguiu, seis países aceitaram as sugestões do Ecma, quatro foram contra e 18 se abstiveram. Ora 22 países de 26 não votaram a favor da proposta!

E porque? Na minha opinião existem muitos senões que impedem um voto SIM, de forma consciente e profissional. O próprio processo de Fast Track não permitiu que fossem feitas avaliações adequadas da especificação. Para termos uma idéia deste problema, das mais de 6.000 páginas originais (devem ser quase 7.000 agora, depois do BRM…), as entidades de padrões tiveram apenas um curto período de cinco meses para avaliar toda esta massa de documentação. Apesar desta limitação de tempo, foram detetadas 3.522 inconsistências e erros. A Ecma respondeu a estes 3.522 comentários com 1.027 propostas, para serem debatidas nos cinco dias do BRM.
Ora, fazendo uma simples conta, com 6.045 páginas divididas por 1.027, temos um erro a cada 5,8 páginas. Claro que, se houvesse mais tempo, muito mais erros seriam encontrados!

Perceba um fato: essas pessoas que analisaram essa documentação, como o Taurion e o Avi da IBM, o Jomar da ODF Alliance, o Gebara da própria Microsoft, o Deivi Kuhn do SERPRO, nenhum deles é desocupado ou “caiu de paraquedas”. Todos são profissionais competentes, experientes, com dedicação total (ou ampla) para esse estudo. O processo Fast-Track tem sido uma constante dor de cabeça para as pessoas tentarem aprovar esse formato. Você continua ainda assim achando que está tudo OK e que a intraoperabilidade é uma boa idéia? Vejamos o que o Taurion fala sobre isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

A própria proposta da especificação, de produzir um padrão compatível com o Office nos leva a uma situação no mínimo preocupante: uma ferramenta (o Office) definindo um padrão e não o contrário. Imagino como seria se a especificação HTML refletisse as caraterísticas internas do Firefox ou do Explorer…Na minha opinião usar um software específico como modelo de referência obriga a que o padrão seja limitado pelas escolhas técnicas originalmente feitas pelos desenvolvedores do software. O que nem sempre é um bom negócio, principalmente quando o software tem mais de vinte anos de desenho, mantendo dentro de si idéias e algoritmos já ultrapassados pelo tempo…

Ou seja, o que podemos fazer ou deixar de fazer, o que devemos implementar ou não fica restrito por escolhas específicas de uma implementação específica cujo cenário era específico. Por exemplo: como seria uma implementação do OOXML em um ambiente Mainframe? Embarcado? Palms? Nintendo DS? Como seria replicar escolhas específicas feitas em um ambiente Windows para algum desses ambientes? Como proceder para portar recursos?
Mas as coisas continuam piorando:
Segundo o Jomar da ODF Alliance, existe uma espécie de “Lei do Silêncio” cercando os resultados do BRM, o que por si só é estranho, pois ao menos em teoria um processo como esse deveria ser aberto para o público interessado se antenar. Não cabe a mim fazer afirmações de que houve má-fé ou não pois não fui parte em momento nenhum desse processo e estou apenas dando opiniões. Mas percebamos o que o Jomar falou recentemente.

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

Como delegado Brasileiro no BRM do OpenXML, estou me segurando prá não sair por aí contando os detalhes daquela reunião, pois acredito que todos deveriam saber detalhadamente o que aconteceu dentro daquela sala, para poder entender como existem empresas mal intencionadas e sem limite ético nenhum hoje em dia.
Só para citar um exemplo, soube recentemente que foi utilizado em uma apresentação em um NB (ABNT de algum país), um SLIDE que foi inicialmente apresentado na reunião de encerramento do BRM. Apesar de não poder contar os detalhes, como última participação minha no BRM, pedi em nome da delegação brasileira ao responsável pelo ITTF (ISO/IEC) na reunião – Mr Barta – que o texto do slide apresentado fosse corrigido, pois ele distorcia tudo o que havia sido realizado naquela semana. Imediatamente ele determinou ao autor do slide (Mr. Oh, um japonês secretário do SC34) que aquele slide e aqueles números jamais deveriam sair daquela sala, pois eles não representavam o resultado do trabalho do BRM e também não detalhavam o processo utilizado na reunião.
Quando saí da reunião e cheguei no hotel, descobri que um profissional da empresa proponente já havia publicado na web os dados (e logo em seguida retirado… estranho, né). Para quem não sabe do que estou falando, é do absurdo número de 98% dos problemas resolvidos que a Microsoft insiste em utilizar no mundo todo, cometendo um CRIME cada vez que usam ou apresentam este números.

Para entender: perceba que há realmente uma “Lei do Silêncio”, como o Jomar falou anteriormente, mas que uma pessoa quebrou essa norma de sigilo imposta na reunião. Mas isso apenas piora:

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

O fato concreto é que fui informado por um colega do Chile, que na semana passada este slide (com o nome do Sr. Oh nele) foi utilizado em uma reunião do NB deles. O slide fazia parte de uma apresentação feita pela Microsoft para demonstrar como tudo estava resolvido no OpenXML. Isto é um CRIME DE VIOLAÇÃO DE SIGILO OU NÃO ?

Ou seja, até que ponto valem essas normas de sigilo? Isso tudo está criando um precedente muito sério, que pode inviabilizar totalmente a credibilidade da ISO. É como a Red Hat publicou recentemente:

Red Hat Magazine | ISO approval: A good process gone bad

For a standards body to have credibility, the procedures it follows need to be credible. ISO’s JTC-1 directives say that the “objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.” Clearly, there has been no achievement of consensus regarding the adoption of OOXML as a standard, and therefore ISO has turned to a voting process.

We believe that the flaws in the ISO voting process for OOXML are so serious that they must be addressed in order to maintain ISO’s credibility as a standards body. For a standards body to review a proposal adequately and achieve consensus, the participants need to be involved in the entire review process, not merely show up to cast a vote.

Para aqueles não proficientes no idioma inglês, a tradução:

Para um órgão de padronização ter credibilidade, os procedimentos que ele segue devem ser dignos de credibilidade. As diretivas do comitê JTC-1 da ISO definem que “o objetivo do desenvolvimento de Padrões Internacionais deve ser alcançar o consenso entre todos aqueles que estão envolvidos ao invés de meramente basear tudo na contagem de votos”. Mas claramente não houve nenhum consenso quanto à adoção do OOXML como um padrão, e portanto a ISO tornou-o [a padronização do OOXML] em um processo de votação.
Nós [da Red Hat] acreditamos que o processo de votação da ISO para o OOXML foi algo tão sério que deveria ser questionado de modo a manter a credibilidade da ISO como um órgão de padronização. Para que um órgão de padronização veja uma proposta adequadamente, de modo a alcançar consenso, os participantes devem se envolver no processo como um todo, e não apenas ir lá para votar.
(grifos meus)

Isso tudo vem sendo mostrado a tempos: vários países receberam incentivos da Microsoft para irem lá e simplesmente votarem a favor do OOXML, sem um estudo prévio da proposta. A própria idéia do Fast-Track foi mal executada. Apesar de executivos da Microsoft terem criticado aqueles que criticam isso, lembrando de casos como os do MPEG, é importante lembrar que o MPEG já vinha passando por estudos a muito tempo, de modo que o Fast-Track foi mais uma formalização de um consenso já adquirido fora da ISO (tanto que recebeu bem menos contradições que o OOXML). Além do mais, existe toda uma questão estatística que impede a pessoa de ler um documento como esse, de 6000 páginas, para um padrão novo, pouco conhecido e debatido e extremamente amarrado a um produto específico, com uma série de exigências voltadas especificamente a esse produto, de ser analisado em tão pouco tempo.
Existe toda uma série de paradoxos sobre quais são os objetivos do OOXML, como exemplo, cito dois e dou recursos para uma leitura detalhada sobre eles:

  • Interoperabilidade: existe uma questão relacionada com a falta do mapeamento de binários. Já tratei rapidamente desse assunto no meu blog, mas acho melhor que você vá direto à fonte e entenda melhor essa questão.
  • Customização do formato: aqui o assunto se torna mais sério. Em resumo, a Microsoft afirma que o OOXML permite a expansão do formato por meio do conceito de Custom XML, onde em teoria você poderia implementar suas próprias tags. Até aqui sem problemas, exceto que o pessoal do OOXML is defective by Design descobriu que isso simplesmente não funciona, e que pode chegar a criar um pesadelo de segurança de dados, pois “eventually, confidential information from the corporate databases will end up there, and a PR disaster automatically follows“, ou seja, pode-se fazer inadvertivamente que dados importantes de bases corporativas vazem para dentro desses Custom XML, criando falhas de segurança simplemente grotescas. Recomendo a leitura do artigo para um maior esclarecimento sobre os perigos e problemas do Custom XML.
Simplesmente, as coisas foram feitas de uma forma extremamente arbitrárias, “socando goela abaixo” um formato que é enorme, inchado, voltado a um produto específico, sendo que já existe um bom formato para esse mesmo tipo de aplciação, que é o ODF. Alegações de “temos HTML, XML, PDF, etc…” não colam, pois esses formatos possuem outros objetivos (ou alguém acredita que HTML seja a melhor forma de editar-se documentos de texto?)
Existe um risco monstruoso de que o OOXML possa passar, ainda mais com a pressão que a Microsoft vem fazendo no plano político para que os órgãos nacionais de normatização (NBs) votem a favor. Realmente espero que isso não passe, mas o que posso fazer é assistir e esperar.
Vejamos os próximos lances.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

As coisas se complicam para o OOXML

Bem, desculpem o hiato: as minhas novas atividades de serviço exigiram um tempo meu especial, onde precisei me focar mais nele e abandonei um pouco o blog.
Nesse meio tempo, ocorreu o Ballot Resolution Meeting (BRM) para a aprovação ou não do Office Open XML. Basicamente, esse é o momento onde todas as contradições (ou comentários) aplicados ao mesmo quando ele não foi aprovado, em uma tentativa de resolver os problemas e com isso aprovar o formato.
Antes que se pense que isso é mais um empurrão da nossa “amiga de Redmond”, na realidade isso é parte do processo de Fast track da ISO, portanto não há nada de errado nesse processo. Muito pelo contrário, ele é completamente válido na medida em que é parte de um processo já validado dentro de uma organização como a ISO.
Os problemas vão surgindo, porém, quando você entende o que está acontecendo por trás dos panos.
Como já comentei anteriormente nesse mesmo blog, existem uma série de problemas sobre como o formato está sendo publicado na ISO. Esse é inclusive o motivador do Ballot Resolution Meeting (BRM): estudar e chegar a um consenso sobre como serão corrigidos os problemas no mesmo. Mas como chegar a um consenso sendo que o formato possui mais de 6000 páginas de documentação técnica com coisas específicas para emular a formatação do Word 95 (?!) ou do Wordperfect (?!)?
Mas isso ainda não é o pior do que está acontecendo sobe o Ballot Resolution Meeting (BRM). Existem coisas ainda piores ocorrendo.
O Jomar, do Homembit e da ODF Alliance Brasil, é um dos representantes da ABNT no comitê JTC1 da ISO, responsável pelo OOXML (DIS 29000), sendo que os outros foram o Deivi Kuhn do SERPRO e o Fernando Gebara, da Microsoft, dois profissionais respeitados na área. Ele é uma fonte de referência para saber o que se passa nesse processo. Além dele, recomendo a leitura do blog do César Taurion, da IBM, também bastante respeitado, que vêm falando bastante do ODF e do OOXML. Eles foram para Genebra participar do BRM como representantes brasileiros. E as coisas começaram a aparecer, apesar da “lei de silêncio” envolvendo o BRM:
Comecemos pelo post do Jomar onde ele esclarece uma proposta do Brasil para facilitar a aceitação do OOXML, principalmente quanto à questão das famosas questões de retrocompatibilidade (lineWrapLikeWord6), que era a possibilidade de um mapeamento de formatos binários (como o .doc) para o OOXML (.docx).
Bem, vamos deixar que ele fale:

Afinal: O que fomos fazer em Genebra ? | void life(void)

Não posso contar os detalhes da reunião, mas posso contar uma conversa que tivemos (eu e mais um delegado brasileiro) com uma pessoa no início da pausa para o almoço de sexta feira. Vou divulgar esta conversa pois nosso interlocutor se identificou como sendo membro do ECMA, membro de uma delegação nacional presente no BRM mas não disse que estava falando em nome de ninguém (como é o protocolo lá), e por isso entendo que esta foi uma conversa que não está coberta pela escandalosa “Lei do Silêncio” imposta a todos nós.
Esta pessoa nos procurou dizendo que considera que não deveríamos apresentar nossa proposta que pedia o mapeamento, pois não havia tempo hábil na reunião (pouco mais de três horas) para escrevermos o documento. Nós dissemos que nossa proposta partia da premissa de que o ECMA já tinha este documento, pois, se justifica a necessidade do OOXML por causa do suporte ao binário e se afirma ainda que existem coisas que não podem ser traduzidas (deprecated), eles devem ter estudado aprofundadamente esta situação e no mínimo ter feito o mapeamento.
Eu nunca vi uma pessoa tão nervosa e envergonhada na minha vida… Ele disse que a Microsoft deve ter este mapeamento e se nós quisermos, podemos pedir à Microsoft mas não pedir ao ECMA. Disse que o ECMA só foi responsável por criar o novo schema XML e que não têm esta documentação.
Como nossa conversa não ia a lugar nenhum, eu lhe expliquei que o que iriamos propor era o resultado do trabalho de um comitê no Brasil e que infelizmente se ele não pudesse voltar ao tempo e vir ao Brasil contar esta história toda, que teríamos que insistir com nossa proposta.
Fiz questão de contar isso aqui, pois não deixaram o Brasil apresentar a proposta…

OK… Pode parecer correto o que a pessoa disse. Mas vejamos o que diz outro profissional envolvido, o Avi Alkalay, da IBM:

OOXML: Está rolando um barraco na ISO :: Avi Alkalay

Só pra lembrar qual é o propósito do OOXML, extraido (em livre tradução) de sua especificação:

O objetivo deste padrão [OOXML] é […] representar fielmente o corpo de documentos existentes […]

Os tais “documentos existentes” são no caso todos os documentos em formato binário legado do MS Office (.doc, ,ppt, .xls), algo fora do escopo do OOXML.
Se esse mapeamento não fizer parte da especificação OOXML, seu objetivo primordial é inválido. A especificação é inválida. E a delegação brasileira queria levantar essa bola: cadê o mapeamento ?

Sem um mapeamento, é praticamente impossível obter a total fidelidade no corpo de documentos existentes e transpor isso ao OOXML, mesmo recorrendo-se a engenharia reversa. Qualquer um que tenha aberto um arquivo .DOC no BrOffice.org ou exportado um documento do BrOffice.org para .DOC sabe disso. Sem esse mapeamento, o resultado prático é que características estranhas dos documentos, principalmente .DOC, não poderão ser representados adequadamente em um OOXML. E é justamente isso que questiona Rob Weir, que é parte da representação americana no OOXML:

An Antic Disposition: The Carolino Effect

The scope of OOXML, as amended by the BRM is stated as:

This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also specifies requirements for Office Open XML consumers and producers , and on the other hand, to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms.

Faithful representation of Microsoft Office 97-2008. I’ve learned it is rarely polite to ask a man what he means by “faithful”, but let me make an exception here. We have now the binary Office format specifications, not part of the standard, but posted by Microsoft. And we have OOXML specification. In what way does the OOXML “represent faithfully” the “existing corpus” of legacy documents?
Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to “represent faithfully” legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text.
Now, certainly, someone using the binary formats specifications, and using the OOXML specification, could string them together and attempt a translation, but the results will not be consistent or satisfactory. (…). Knowing the two endpoints is not the same as knowing how to correctly map between them. A faithful mapping requires knowledge not only of the two vocabularies, but also the interactions.

Uma tradução livre desse trecho é a seguinte:

O Escopo do OOXML, como foi corrigido no BRM é definido como:


Esse padrão internacional define um conjunto de vocabulários XML para a representação de documentos de processamento de texto, planilhas e apresentações eletrônicas. O objetivo desse padrão é, por um lado, representar fielmente a formatação existente de
documentos de processamento de texto, planilhas e apresentações eletrônicas produzidas por aplicações do Microsoft Office (do Microsoft Office 97 ao Microsoft Office 2008, inclusive). Também especifica requisitos para consumidores e produtores de documentos Office Open XML e, por outro lado, facilita a extensibilidade e a interoperabilidade ao permitir implementações por vários desenvolvedores e em várias plataformas.


Representação fiel de documentos do Microsoft Office 97 ao 2008. Aprendi que raramente é polido perguntar a alguém o que ele quer dizer com “fiel”, mas aqui há uma exceção. Nós temos agora as especificações do formato dos arquivos binários do Office, não incluídos como parte do padrão, mas sim fornecidos pela Microsoft; e temos a especificação do OOXML. Como é que o OOXML “
representar fielmente a formatação existente” dos documentos legados?
O OOXML nos diz como traduzir um documento binário em OOXML? Não. Diz como mapear as
features dos documentos legados para OOXML? Não. Oferece um caminho para o desenvolvedor “representar fielmente”, seja lá o que queira isso dizer, os documentos legados? Não. Portanto é ao mesmo estranho e insatisfatório que o objetivo principal do OOXML seja tão tenazmente definido por esse texto.
Na verdade, alguém que queira tentar uma tradução usando as especificações dos formatos binários e do OOXML poderia amarrá-los e tentar seguir em frente, mas os resultados não serão consistentes ou satisfatórios. (…) Saber os pontos de chegada e partida não significa saber o caminho entre eles. Um mapeamento fiel exige não apenas o conhecimento das duas especificações, mas também das interações entre elas. (Grifo meu)

Perceba aqui o problema: não é possível saber como “representar fielmente” os documentos em questão. O máximo que um desenvolvedor pode fazer é “ir no chute”, mas “os resultados não serão consistentes ou satisfatórios“. Como disse, basta tentar abrir um arquivo do Word em qualquer outro editor e ver que isso é uma verdade. O resultado nunca é o mesmo. Mesmo quando o formato é conhecido, existem leves diferenças na implementação (quem nunca desconfigurou a formatação de um documento ao abrir ele na versão mais atual de um editor?). Problemas entre formatos é obviamente uma realidade.
E isso é apenas a ponta do Iceberg.
No dia que eu escrevo isso, o Avi Alkalay publicou em seu blog um post falando sobre uma das “features” que serão exigidas no OOXML. No caso, cito a fonte do mesmo, novamente o Rob Weir:

An Antic Disposition: A Leap Back

(…) in 1582 Pope Gregory XIII promulgated a new way of calculating leap years, saying that years divisible by 100 would be leap years only if they were also evenly divisible by 400. So, the year 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not leap years. This Gregorian calendar was initial adopted by Catholic nations like Spain, Italy, France, etc. Protestant nations pretty much had adopted it by 1752, and Orthodox countries later, Russia after their 1918 revolution and Greece in 1923.

traduzindo (desculpem, o post vai se tornar longo, mas tenho a prática de citar a fonte “as is” e as traduzir a posteriori quando isso pode ser relevante):

(…) em 1582 o Papa Gregório XIII promulgou uma nova forma de calcular-se anos bissextos, determinando que os anos divisíveis por 100 só seriam bissextos se fossem divisíveis também por 400. Portanto, 1600 e 2000 foram anos bissextos, mas 1700, 1800 e 1900 não. Esse calendário gregoriano foi inicialmente adotado em nações católicas como a Espanha, Itália, França, etc… As nações protestantes o adotaram em 1752, e as nações ortodoxas mais tarde: a Rússia após a revolução de 1918 e a Grécia em 1923.

OK… Um pouco de história? Qual é o problema?
O problema é a seguinte imagem:

O que foi feito aqui?
Quando se formata uma casa do Excel como data, ela conta a partir de 01/01/1900. Ou seja, se quero representar o dia de hoje, eu somo o número de dias que passou entre 01/01/1900 e hoje (um princípio básico da computação que é adotado em diversos formatos, com leves diferenças entre unidades e “ponto zero” adotados). Isso facilita a computação para fórmulas, principalmente envolvendo datas. Pensando assim, e lembrando o que foi dito anteriormento, o Avi definiu que o valor da data como a primeira data do escopo (01/01/1900) + os trinta dias seguintes (ou seja, levaria até 31/01/1900) e somou mais 29 dias em seguida. O resultado seria 29 dias após o dia 31/01/1900. Como não é bissexto (como o Rob explicou anteriormente), o resultado adequado seria 01/03/1900. A imagem comprova que o resultado foi 29/02/1900 (também conhecido como dia de São Nunca).
Agora, você pergunta: “Qual é o problema?”
Lembra a questão de “‘representar fielmente a formatação existente‘ dos documentos legados”? Bem, isso quer dizer representar inclusive os bugs!!! Pode-se alegar que é um bug inconveniente, mas não é, e mesmo que fosse isso não é desculpa. E a questão é a seguinte: se um erro bobo como esse passa (lembrando que esses documentos legados podem estar por aí em 2100, que também não é um ano bissexto), imagina detalhes mais complexos?
E as coisas não acabaram:
As pessoas que estão acompanhando esse processo do OOXML sabem que a Microsoft prometeu liberar totalmente de royalties o OOXML, atraves do que ela chama de “Microsoft Open Specification Promise” (OSP). Basicamente, ela afirma por meio disso que está não irá processar ninguém por usar ou desenvolver em cima dessas patentes. Porém, o pessoal do Software Freedom Law Center, que estuda licenças de software para analisar sua compatibilidade com o Software Livre, procurou analisar a OSP e verificar sua compatibilidade com as licenças livres, como a GPL, a Artistic (do Apache) ou a CDDL (Sun/OpenOffice.org). O resultado é:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…), we publicly conclude that the OSP provides no assurance to GPL developers and that it is unsafe to rely upon the OSP for any free software implementation, whether under the GPL or another free software license.

traduzindo:

(…), concluímos publicamente que a OSP não oferece nenhuma segurança para desenvolvedores que usem a GPL e que não é seguro se basear na OSP para qualquer implementação livre [do OOXML], seja segundo a GPL ou segundo qualquer outra licença de software livre. (grifos meus)

Você pode se perguntar: “o que mais esses open-xiitas querem? Não basta as especificações da ECMA?
Não basta! Tanto não basta que a própria ISO não aceita padrões que possuam patentes, a não ser que essas patentes estejam para acesso a qualquer um sem cobrança de royalties. A pergunta então pode ser: “qual é o problema?” Bem, vamos aos fatos:


Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

Microsoft makes its promise “irrevocably,” but upon careful reading of the entire OSP, this promise is weakened considerably in the definition of Covered Specifications. In that provision, Microsoft clarifies that:

New versions of previously covered specifications will be separately considered for addition to the list.

Because of this narrow definition of the covered specifications, no future versions of any of the specifications are guaranteed to be covered under the OSP. Each new version is subject to Microsoft’s ongoing discretion on a case by case basis. In other words, every time a specification changes, Microsoft can effectively revoke the OSP as it had applied to previous versions of that same specification. Microsoft states that it will commit to renewal of the promise for future versions of specifications subject to standardizing activity “to the extent that Microsoft is participating in those efforts,” which means that Microsoft reserves the right to cancel the promise with respect even to standardized specifications, by merely withdrawing from the relevant standard-setting workgroup or activity. While technically an irrevocable promise, in practice the OSP is good only for today.

tradução:

A Microsoft torna sua promessa “irrevogável”, mas se lemos a OSP completamente, percebemos que essa promessa é enfraquecida sensivelmente pela definição de Especificações Cobertas pela mesma. Nessa provisão, a Microsoft deixa claro que:

Novas versões de especificações anteriormente cobertas pela mesma poderão ser consideradas separadamente para serem adicionadas à lista [de especificações].

Devido à essa definição ampla de Especificações Cobertas, nenhuma versão futura de nenhuma dessas especificações estarão seguramente cobertas pela OSP. Cada nova versão é alvo da decisão da Microsoft em uma situação caso-a-caso. Em outras palavras, cada vez que uma especificação mudar, a Microsoft pode efetivamente revogar a OSP do modo como ela se aplica às versões anteriores da mesma especificação. A Microsoft determinou que irá renovar a promessa para futuras versões das especificações sujeitas à atividade de padronização “enquanto a Microsoft participar desses esforços”, o que na prática quer dizer que a Microsoft se reserva no direito de cancelar a promessa até mesmo para as especificações que passaram por padronização, simplesmente abandonando os grupos de trabalho ou atividades relevantes. Embora tecnicamente ela seja irrevogável, na prática a OSP só funcionaria de imediato. (grifos meus)
Atentemos aos grifos: por eles, compreendemos que, ao bel-prazer, a Microsoft pode, mesmo após aprovado o padrão, revogar sua OSP e sair processando todo mundo, criando uma patente submarina potencial, uma vez que, pelos termos citados, ao revogar sua OSP, todo usuário potencial da OSP estaria infringindo direitos de patente e, com isso, sendo alvo potencial de processos. Sem sombra de dúvidas, uma forma capciosa de implementar minas-terrestres de Propriedade Intelectual contra os usuários.
Mas não acabou: você não poderia incorporar código de implementações do OOXML em qualquer coisa que não envolva implementação OOXML. Vejamos o que a SFLC tem a dizer sobre isso:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…) any code written in reliance on the OSP is covered by the promise only so long as it is not copied into a program that does something other than implement the specification. This is true even if the code has not otherwise been modified, and code that conforms to the specification cannot be modified if the resulting modified code does not conform.

Traduzindo:

(…) qualquer código que tenha sido escrito em observância à OSP estará coberto pela promessa enquanto ele não for incorporado a qualquer programa que faça qualquer outra coisa que imp,ementar a especificação. Isso é verdadeiro mesmo se o código não for modificado, e o código que estiver seguindo a especificação não pode ser modificado se o código modificado resultante não estiver em observância.

O que isso quer dizer? Basicamente, não temos um uso livre para incorporação em qualquer situação, o que é definido pela Liberdade 2 da Free Software Foundation e que é parte do princípio por trás da GPL. Embora possa-se alegar que uma biblioteca poderia rodar segundo LGPL e assim trabalhar em conjunto com software GPL, ainda assim não pode-se afirmar que esse seja um uso livre ou mesmo seguro do mesmo.
O pior é que, segundo a Microsoft, a culpa é da GPL:
Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

In its FAQ regarding the OSP, Microsoft confuses the issue further, saying:

Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

While not attempting to clarify the text of the OSP to indicate compatibility with the GPL or provide a safe harbor through its guidance materials, Microsoft wrongly blames the free software legal community for Microsoft’s failure to present a promise that satisfies the requirements of the GPL. It is true that a broad audience of developers could implement the specifications, but they would be unable to be certain that implementations based on the latest versions of the specifications would be safe from attack. They would also be unable to distribute their code for any type of use, as is integral to the GPL and to all free software.

traduzindo:

Em sua FAQ relacionada à OSP, a Microsoft distorce essa questão [do licienciamento segundo a GPL] dizendo que:

Uma vez que a Licença Pública Geral (GPL) não é universalmente interpretada da mesma forma por todos, não podemos dar uma opinião legal sobre como nosso texto se relaciona à GPL e a outras licenças de software livre ou aberto, mas baseado no feedback que recebemos da comunidade do software aberto acreditamos que uma ampla gama de desenvolvedores pode implementar a(s) especificação(ões).

Além de não tornar claro o texto da OSP para indicar compatibilidade com a GPL ou oferecer um porto seguro por meio de eus materiais, a Microsoft erroneamente culpa a comunidade jurídica relacionada ao software livre por sua incapacidade de oferecer uma promessa que satisfaça as condições da GPL. É verdade que uma ampla gama de desenvolvedores poderá implementar as especificações [segundo a OSP], mas eles não terão certeza de que implementações baseadas nas versões mais recentes estarão seguras contra litígios. Eles também não terão garantias de que poderão distribuir tais códigos para serem usados como necessário, o que é uma parte fundamental da GPL e de qualquer software livre. (Grifos meus)

Perceba que citei anteriormente a possibilidade de adotar-se a LGPL. O problema é que pela primeira questão levantada (a possibilidade de revogação da OSP), não há garantias de que, mesmo sob LGPL, o software continue legalmente sendo aceito, devido às patentes.
Pretendo comentar mais sobre essa questão, uma vez que em alguns dias haverá a decisão final sobre a padronização do OOXML. Mas é importante ficarmos com a orelha em pé: não sabe-se o que pode acontecer.

Office OpenXML (OOXML) e inapto pela ISO 29500