Abertura de APIs Microsoft pode causar avalanche de bugs?
Nessa semana o Higor Fernandes, membro do MSRio.Net, iniciou uma discussão no grupo sobre o assunto-título desse post. Como minha argumentação sobre o assunto é relativamente grande pra ficar em um email, acabei resolvendo escrever por aqui, sendo assim, vamos lá:
Tudo começou com essa notícia aqui: http://computerworld.uol.com.br/seguranca/2008/02/25/abertura-de-softwares-da-microsoft-pode-causar-avalanche-de-bugs/
Antes de dar a opinião sobre o tema, registro a dica sobre como se ler um artigo e não ser enganado por pessoas mal entendidas do assunto que escrevem bobeira na internet. Acredito que o primeiro ponto a se fazer quando lemos uma declaração é procurar pela credibilidade de quem a declarou e analisando a notíca encontramos que as declarações foram dadas pela nCircle Inc. A nCircle é uma empresa de segurança americana com um enorme background em análise de riscos, sendo assim: eles realmente sabem do que estão falando. Uma outra coisa que eu, como bom paranóico de segurança, me acostumei a fazer nessas notícias foi buscar a fonte real da informação. Como a Computer World é uma revista americana, fui atrás da notícia real que poder ser lida em http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9064500&taxonomyId=17&intsrc=kc_top.
Pra finalizar e realmente poder opinar sobre o artigo (já que você precisa ter conhecimento do assunto pra isso), é necessário entender a estratégia Open Source da Microsoft. Ao contrário do que tem muito profeta do apocalipse afirmando por aí, a Microsoft não vai virar Open Source da noite pro dia. A liberação das APIs é conseqüência das exigências feitas pela União Européia de quebra de monopólio. Sim, aquelas exigências que levaram a Microsoft a pagar a maior multa de sua história. Sendo assim, não é que a Microsoft quer mudar, mas é que ela não tinha opções. Ou abre a API, ou venda para Americanos e Asiáticos. Como ninguém quer perder o filão europeu (que é o continente mais rico), adapta-se ao mercado.
Outra coisa que é necessário entender é: O que vai ser liberado exatamente? É o código fonte de todos os programas? Nada disso. APIs (Application Programming Interface) são bibliotecas de código fonte de algum programa que estão disponíveis para permitir que outros programas conversem ou utilizem funcionalidades do mesmo. Por exemplo, um Sistema Operacional em sua definição mais acadêmica é uma abstração do hardware, fazendo o papel de intermediário entre o aplicativo (programa) e os componentes físicos do computador (Tannebaum, 1999). Sendo assim quando criamos um programa em .net que cria um arquivo texto em uma pasta qualquer, fazemos isso acessando a API de criação de arquivo do windows. Sendo assim, qual era a grande vantagem de ter as APIs fechadas? Ora. Se só a Microsoft conhece todas as APIs, os softwares Microsoft experimentavam de funcionalidades e integrações entre si que nenhum outro concorrente poderia sonhar em ter. Além disso, depois do Steve Ballmer sair gritando "Developers, Developers, Developers", veja os investimentos da MS na área de desenvolvimento de software. Repare que o ambiente .net oferece uma integração e poder em cima de ambientes Windows que nenhum Java/Python ou seja lá quem for pode se aproximar e essa vantagem se amplia para qualquer ramo de software. Enfim: Para "equalizar o mercado", a UE decidiu proibir essa vantagem comercial para a Microsoft que se viu obrigada a liberar as suas APIs.
Uma outra coisa que aconteceu recentemente e as pessoas se confudem é: A BCL (Base Class Library) do .net framework agora tem o código aberto. Isso não faz parte das imposições da UE. Isso ocorreu como que um presente para os desenvolvedores .net. Mas repare que você não pode editar a BCL, ou coisa do tipo. É Open Source. Não é Software Livre. Então você deve estar se perguntando "se não pode editar, pra que serve essa bagaça?". Simples, facilitar o debug. Ponto. Aumentar o seu conhecimento de como as coisas funcionam internamente. Ponto.
Enfim, uma vez entendida a história das APIs vamos finalmente a análise da segurança. Numa análise óbvia, a partir do momento em que o código fonte está disponível, será mais fácil encontrar bugs sim, porque ao invés de ficar testando por fora, você abre o código fonte e encontra o problema, mas essa análise seria baseada em cima daquele método "nas coxas" de desenvolvimento seguro: "Software Proprietário é mais seguro porque ninguém vê o código fonte" vs "Software Livre é mais seguro porque todo mundo testa, encontra os problemas e resolve melhor" e sobre isso eu já falei na última vez, acho uma grande baboseira, já que o que garante a segurança é um processo conciso de desenvolvimento seguro. Enfim, sempre falamos no mundo de segurança que "Esconder o código fonte nunca é um recurso" e espero que o pessoal da Microsoft tenha seguido isso a risca. Nos últimos anos eles tem desenvolvido os softwares utilizando o SDL (Secure Development Lifecycle) do qual eu sou fã. Se tudo aquilo que eles falaram que fizeram na implementação do SDL foi feito e se tudo o que eles pregam realmente for seguido, disponibilizar o código fonte não será problema porque os bugs foram realmente resolvidos e não "escondidos". Porém, se a coisa não for tão rígida quanto as literaturas sugerem: podemos esperar a chuva dos bugs sim, porque o que estava escondido embaixo do tapete, certamente virá a tona.
Sendo assim concluo que: Confiando no SDL, a chuva de bugs não será grande. Encaro a situação como o grande teste do SDL. Será que ele foi realmente implementado perfeitamente por seus criadores? Ou será que ele não funciona bem com projetos open? Vale lembrar que os autores do SDL sempre identificaram que é muito difícil garantir a segurança de projetos legados e, nas APIs de ferramentas como Windows e Office, podemos ter certeza que projetos legados estão envolvidos neste processo.
Quer fazer parte da lista de discussão do MsRio.net?
Inscreva-se já, enviando o pedido para o email msriodotnet-subscribe@yahoogrupos.com.br
Att,
Rodrigo Moreira
MCP, MCTS
Microsoft Student Partner Co-Lead
http://jackflashspot.spaces.live.com
Líder do MSRio.Net
TANENBAUM, Andrew. Sistemas operacionais modernos. Rio de Janeiro: LTC. 1999.
Tudo começou com essa notícia aqui: http://computerworld.uol.com.br/seguranca/2008/02/25/abertura-de-softwares-da-microsoft-pode-causar-avalanche-de-bugs/
Antes de dar a opinião sobre o tema, registro a dica sobre como se ler um artigo e não ser enganado por pessoas mal entendidas do assunto que escrevem bobeira na internet. Acredito que o primeiro ponto a se fazer quando lemos uma declaração é procurar pela credibilidade de quem a declarou e analisando a notíca encontramos que as declarações foram dadas pela nCircle Inc. A nCircle é uma empresa de segurança americana com um enorme background em análise de riscos, sendo assim: eles realmente sabem do que estão falando. Uma outra coisa que eu, como bom paranóico de segurança, me acostumei a fazer nessas notícias foi buscar a fonte real da informação. Como a Computer World é uma revista americana, fui atrás da notícia real que poder ser lida em http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9064500&taxonomyId=17&intsrc=kc_top.
Pra finalizar e realmente poder opinar sobre o artigo (já que você precisa ter conhecimento do assunto pra isso), é necessário entender a estratégia Open Source da Microsoft. Ao contrário do que tem muito profeta do apocalipse afirmando por aí, a Microsoft não vai virar Open Source da noite pro dia. A liberação das APIs é conseqüência das exigências feitas pela União Européia de quebra de monopólio. Sim, aquelas exigências que levaram a Microsoft a pagar a maior multa de sua história. Sendo assim, não é que a Microsoft quer mudar, mas é que ela não tinha opções. Ou abre a API, ou venda para Americanos e Asiáticos. Como ninguém quer perder o filão europeu (que é o continente mais rico), adapta-se ao mercado.
Outra coisa que é necessário entender é: O que vai ser liberado exatamente? É o código fonte de todos os programas? Nada disso. APIs (Application Programming Interface) são bibliotecas de código fonte de algum programa que estão disponíveis para permitir que outros programas conversem ou utilizem funcionalidades do mesmo. Por exemplo, um Sistema Operacional em sua definição mais acadêmica é uma abstração do hardware, fazendo o papel de intermediário entre o aplicativo (programa) e os componentes físicos do computador (Tannebaum, 1999). Sendo assim quando criamos um programa em .net que cria um arquivo texto em uma pasta qualquer, fazemos isso acessando a API de criação de arquivo do windows. Sendo assim, qual era a grande vantagem de ter as APIs fechadas? Ora. Se só a Microsoft conhece todas as APIs, os softwares Microsoft experimentavam de funcionalidades e integrações entre si que nenhum outro concorrente poderia sonhar em ter. Além disso, depois do Steve Ballmer sair gritando "Developers, Developers, Developers", veja os investimentos da MS na área de desenvolvimento de software. Repare que o ambiente .net oferece uma integração e poder em cima de ambientes Windows que nenhum Java/Python ou seja lá quem for pode se aproximar e essa vantagem se amplia para qualquer ramo de software. Enfim: Para "equalizar o mercado", a UE decidiu proibir essa vantagem comercial para a Microsoft que se viu obrigada a liberar as suas APIs.
Uma outra coisa que aconteceu recentemente e as pessoas se confudem é: A BCL (Base Class Library) do .net framework agora tem o código aberto. Isso não faz parte das imposições da UE. Isso ocorreu como que um presente para os desenvolvedores .net. Mas repare que você não pode editar a BCL, ou coisa do tipo. É Open Source. Não é Software Livre. Então você deve estar se perguntando "se não pode editar, pra que serve essa bagaça?". Simples, facilitar o debug. Ponto. Aumentar o seu conhecimento de como as coisas funcionam internamente. Ponto.
Enfim, uma vez entendida a história das APIs vamos finalmente a análise da segurança. Numa análise óbvia, a partir do momento em que o código fonte está disponível, será mais fácil encontrar bugs sim, porque ao invés de ficar testando por fora, você abre o código fonte e encontra o problema, mas essa análise seria baseada em cima daquele método "nas coxas" de desenvolvimento seguro: "Software Proprietário é mais seguro porque ninguém vê o código fonte" vs "Software Livre é mais seguro porque todo mundo testa, encontra os problemas e resolve melhor" e sobre isso eu já falei na última vez, acho uma grande baboseira, já que o que garante a segurança é um processo conciso de desenvolvimento seguro. Enfim, sempre falamos no mundo de segurança que "Esconder o código fonte nunca é um recurso" e espero que o pessoal da Microsoft tenha seguido isso a risca. Nos últimos anos eles tem desenvolvido os softwares utilizando o SDL (Secure Development Lifecycle) do qual eu sou fã. Se tudo aquilo que eles falaram que fizeram na implementação do SDL foi feito e se tudo o que eles pregam realmente for seguido, disponibilizar o código fonte não será problema porque os bugs foram realmente resolvidos e não "escondidos". Porém, se a coisa não for tão rígida quanto as literaturas sugerem: podemos esperar a chuva dos bugs sim, porque o que estava escondido embaixo do tapete, certamente virá a tona.
Sendo assim concluo que: Confiando no SDL, a chuva de bugs não será grande. Encaro a situação como o grande teste do SDL. Será que ele foi realmente implementado perfeitamente por seus criadores? Ou será que ele não funciona bem com projetos open? Vale lembrar que os autores do SDL sempre identificaram que é muito difícil garantir a segurança de projetos legados e, nas APIs de ferramentas como Windows e Office, podemos ter certeza que projetos legados estão envolvidos neste processo.
Quer fazer parte da lista de discussão do MsRio.net?
Inscreva-se já, enviando o pedido para o email msriodotnet-subscribe@yahoogrupos.com.br
Att,
Rodrigo Moreira
MCP, MCTS
Microsoft Student Partner Co-Lead
http://jackflashspot.spaces.live.com
Líder do MSRio.Net
TANENBAUM, Andrew. Sistemas operacionais modernos. Rio de Janeiro: LTC. 1999.
Comments