Chegou a hora de desativar seu plugin Java?

por | ago 13, 2012 | Sem categoria, TechTudo | 0 Comentários

Variados fornecedores de sistemas operacionais têm recomendado cautelas especiais ou mesmo reduzido seu suporte a aplicações Java, por motivos que incluem aspectos de mercado, de tecnologia e de segurança. Os de segurança me chamam a atenção de maneira especial, e creio que vale a pena parar de pensar no Java como se fosse componente necessário ao uso da web.

Vale a pena parar de pensar no Java como se fosse componente necessário ao uso da web. 

AutorA versão TL;DR do que vem a seguir é: provavelmente vale a pena você começar a levar a sério a ideia de manter desativados seus plugins (e a bola da vez é o Java) e começar a incluir a independência em relação a eles como critério na hora de escolher serviços on-line.

Para quem tem tempo de ler, a seguir eu digo a razão, começando pelo histórico, e depois dou dicas de como fazer.

De onde viemos

A experiência da web altamente dependente de plugins e outros penduricalhos é uma herança da metade da década retrasada, um tempo em que não existiam tecnologias como o Ajax, HTML5 ainda não era nem mesmo um sonho, e as opções para oferecer ao usuário interação confortável em uma janela do navegador ainda eram extremamente restritas.

Como havia demanda por sistemas na web mas o navegador ainda não era capaz de oferecer recursos essenciais de interface, a bola estava evidentemente quicando na área e não faltaram atacantes para chutar: a Adobe ofereceu o Flash, a Sun escalou o Java, e a Microsoft aproveitou e inseriu uma maneira de fazer aplicativos web ActiveX que rodavam nativamente e assim só podiam ser executados no sistema operacional dela, por exemplo.

Começou assim um longo período de relação muito próxima entre navegador e plugins, a ponto de por mais de uma década as tecnologias como Flash e Java serem consideradas indispensáveis para a experiência on-line.

Contornando um problema e dando origem a outros

java (Foto: Reprodução)Java (Foto: Reprodução)

A ideia de plugin, como uma solução “por fora” construída ao redor do navegador, ao mesmo tempo em que foi a solução na época, traz também algumas desvantagens inerentes, incluindo o fato de ser um processo a mais rodando na nossa CPU, bem como envolver todo um ecossistema de desenvolvimento a mais, o que se traduz em treinamento a mais, ferramentas (proprietárias do autor do plugin) a mais, suporte a mais, etc.

E isso vale para Flash, Java, QuickTime, WMP, Real Player e tantos outros, muitos dos quais felizmente já são vistos como obsoletos.

Os anos passaram e as razões que levaram à demanda por plugins foram sendo resolvidas, mas sua continuidade era mantida devido a uma inércia natural: a quantidade de sites e serviços on-line feitos em Flash, em Java, etc. justificava continuar mantendo o suporte a eles, e o suporte existente justificava continuar desenvolvendo sites em Flash e Java, por exemplo.

Só que algumas revoluções ocorreram: a primeira entre as mais evidentes foi a explosão do acesso móvel, que fez o consumo de CPU, memória e espaço dos plugins ficar bem mais perceptível, já que os megabytes que nem notamos no nosso PC de mesa podem ser essenciais para o funcionamento de um tablet ou smartphone – e assim, em novembro do ano passado a Adobe capitulou, avisando que ia parar de manter o Flash para dispositivos móveis e desde já reorientar seu foco para o HTML5. Não faltaram desenvolvedores antenados para complementar: isso significa que conteúdo que rode em dispositivos móveis não pode mais depender do Flash, e indica que o Flash nos PCs também já pode antever o momento em que colocará seu pé na cova.

A segurança como força disruptiva

 

Na época em que os plugins começaram a brilhar, segurança de informática ainda era assunto quase restrito aos profissionais, e as iniciativas se concentravam principalmente em restringir acesso a servidores.

Os computadores dos usuários estavam entregues à sua própria sorte, e logo os malfeitores perceberam que havia grande oportunidade de ganho se deixassem de agir só no atacado (explorando brechas em servidores) e passassem a ir ao varejo, aproveitando que tantos computadores estavam com a porteira aberta.

Foram tantos ataques, infecções, desvios de operações bancárias, roubos de senhas, etc. que os desenvolvedores de sistemas operacionais comerciais logo perceberam a necessidade de mudança de enfoque, e (numa revolução lenta, que durou anos) passaram a oferecer segurança por design do sistema, com sistemas de manutenção e atualização preparados para reagir de forma mais rápida em relação a falhas. Até que funcionou bem, embora com seus percalços.

Mas e os plugins? Ah, os plugins… Eles continuavam sendo desenvolvidos por terceiros, com seus próprias interesses, que resultavam em seus próprios níveis de atenção a vulnerabilidades, em seus próprios mecanismos de atualização (com eficácia variável) e outras características que destoam da afinação segura idealizada pelos fornecedores de sistemas operacionais.

O momento da virada

Considerando o Flash uma (lenta e pesada) página virada nas minhas próprias demandas, eu comecei a me preocupar com o plugin Java quando a Oracle descontinuou a licença que permitia a sua inclusão em distribuições Linux, que permitiu ao longo de anos que este ambiente de execução estivesse presente e em uso por default nos computadores dos usuários. A partir daquele momento, usuários interessados teriam de obter o Java diretamente da Oracle, sem uma estratégia de transição eficaz.

Na ocasião eu pensei: eles têm conhecimento de que isso vai impedir que atualizações e correções de vulnerabilidades continuem sendo oferecidas pelos mecanismos de pacotes das distribuições, e certamente vão abrir uma exceção para evitar que estes usuários fiquem expostos a vulnerabilidades.

Mas eu fui otimista demais. Não foi aberta exceção à mudança de licença e, como previsto, logo havia uma enorme quantidade de usuários rodando instalações do Java com vulnerabilidades conhecidas, o que provocou até mesmo o anúncio de medidas extremas, como a do Ubuntu, que chegou aanunciar que iria forçar a remoção do plugin Java da Oracle dos navegadores de seus usuários em uma atualização.

Este foi o ponto em que me convenci que manter ativado o plugin não era mais do meu interesse, e que valeria a pena começar a procurar serviços que não dependessem dele, ou ativá-lo só sob demanda quando absolutamente necessário.

Na mesma época, fornecedores de outros sistemas operacionais anunciaram medidas similares, deixando de incluir o ambiente de execução Java como um elemento default da sua instalação e, quando vulnerabilidades do plugin causaram comprometimentos de segurança em série, oferecendo ferramentas para facilitar sua ativação e desativação quando necessário.

Viva o Java

Uma alternativa de transição pode ser começar a manter os plugins desativados exceto quando a necessidade imediata de uso for percebida
Autor

A proposta do Java é cheia de méritos. Um ambiente de execução que esteja disponível em múltiplas plataformas, com ferramentas de desenvolvimento em comum entre elas, é uma ótima ideia. A existência de implementações em código aberto a torna ainda mais simpática para mim.

Já o plugin Java visto como parte integrante e fundamental do navegador web é um conceito para o qual hoje há alternativas, e eu recomendo que você mantenha os olhos abertos a elas.

Caso vá manter o plugin Java (ou o Flash, ou qualquer outro) em uso, vale tomar cautelas extras de configuração, para garantir que você está sempre com a versão mais recente instalada – caso contrário, as estatísticas vêm indicando que é grande a chance de eles se transformarem em um vetor com grande potencial para a execução de código malicioso a partir de páginas que você visitar, mesmo em um sistema que nos demais aspectos esteja bastante seguro.

Uma alternativa de transição pode ser começar a manter os plugins desativados exceto quando a necessidade imediata de uso for percebida – por exemplo, na hora de acessar o serviço web do seu banco, ainda implementado como um applet. Para fazer isso nos navegadores mais comuns no Linux, recomendo seguir as instruções oficiais para o Chrome e as do Firefox. Há outros softwares que podem ajudar, e é possível até mesmo que o seu sistema operacional tenha uma ferramenta pronta para isso, vale a pena pesquisar!

Mas não deixe que essas cautelas sejam percebidas como uma rejeição ao Java em si: há bastante lugar para sistemas em Java, eles podem ser muito bem-vindos, e de modo geral as vulnerabilidades identificadas ao longo de períodos recentes não são culpa dos sérios e competentes profissionais que desenvolvem softwares em Java. Eles também merecem uma situação de segurança que permita aos usuários executar com tranquilidade seus produtos!

By Adilson

Confira estas postagens relacionadas

Em Busca da Cidade Mais Perigosa da Internet, o documentário da Norton sobre cibercrime

Em Busca da Cidade Mais Perigosa da Internet, o documentário da Norton sobre cibercrime

O que leva um hacker a invadir sistemas ou interceptar dados? Interesses financeiros? A adrenalina do desafio? Motivações políticas? O apreço pelo caos? A Norton decidiu abordar o assunto em um documentário deveras interessante: Em Busca da Cidade Mais Perigosa da Internet. Líder mundial em segurança digital, a Norton utilizou a sua vasta

ler mais

0 Comentários

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Pin It on Pinterest