segunda-feira, 13 de agosto de 2012

Java


Chegou a hora de desativar seu plugin Java?

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
!

Nenhum comentário:

Postar um comentário