Unhosted web applications: a new approach to freeing SaaS
Autor original: Nathan Willis
Publicado originalmente no: lwn.net
Tradução: Roberto Bechtlufft
Há muitos anos os defensores do software livre vêm se opondo à onda cada vez maior do SaaS comercial (ou “software como serviço”) e à perda de autonomia e liberdade no software decorrente dela. Um novo projeto chamado Unhosted aborda essa questão de uma maneira diferente de outros exemplos mais conhecidos, como o Diaspora e o StatusNet. O Unhosted está criando um framework no qual todo o código de um aplicativo Web é executado no lado do cliente, e os usuários têm a liberdade de escolher qualquer local de armazenamento remoto que desejarem. Os nós de armazenamento usam uma criptografia forte, e como não estão diretamente associados ao provedor do aplicativo, o usuário sempre tem a liberdade de trocar ou de encerrar completamente sua conta.
A abordagem do Unhosted
As linhas gerais do modelo de serviço imaginado pelo Unhosted podem ser encontradas na página de manifesto do projeto, escrita pelo fundador Michiel de Jong:
“Um site hospedado oferece duas coisas: processamento e armazenamento. Um site com o Unhosted só hospeda o código fonte (ou talvez apenas um programa que dispare o carregamento dele). O processamento é feito no navegador, com Ajax, baseado em um armazenamento criptografado na nuvem.”
Em outras palavras, ainda segundo o manifesto, a licença Affero GPL (AGPL), que exige que o código fonte seja disponibilizado aos usuários finais na rede, não basta para preservar a liberdade dos usuários, já que os sites de SaaS proprietários exigem que o usuário suba seus dados para o armazenamento do provedor de serviço. Um aplicativo do Unhosted é um programa em JavaScript que roda no navegador, mas acessa o armazenamento online em um nó de armazenamento compatível. Não importa para o aplicativo se o nó de armazenamento é de responsabilidade do provedor do aplicativo, do usuário ou de terceiros.
Os nós de armazenamento são basicamente uma infraestrutura comum, mas para preservar a liberdade do usuário, o Unhosted exige que os aplicativos criptografem os dados que armazenam. O projeto define um protocolo de camada de aplicativo chamado UJJP (ou apenas UJ) para que os aplicativos se comuniquem com os nós de armazenamento para solicitar e trocar objetos no formato JSON.
Conforme explica o FAQ, isso constitui um modelo distintamente diferente da maioria dos demais projetos de SaaS de software livre. A maioria deles, como o StatusNet e o Diaspora, se concentra na federação, que permite a cada usuário rodar seu próprio nó e não exige uma autoridade centralizada unindo todas as contas de usuário. O lado negativo dos sistemas federados é que eles ainda exigem que os usuários confiem seus dados a um servidor remoto.
O FreedomBox de Eben Moglen, por outro lado, se concentra em deixar o armazenamento sob o controle direto do usuário (armazenado em casa, em um PC gerenciado por ele). Teríamos um grau maior de liberdade, mas a hospedagem doméstica é menos acessível pela internet do que a maioria dos serviços web, porque geralmente depende de DNS dinâmico. A hospedagem doméstica também está sujeita às limitações de largura de banda e às restrições comuns que os provedores impõem à execução de servidores.
O Unhosted tenta preservar a “acessibilidade em qualquer lugar” dos populares serviços da web 2.0, mas desvinculando o aplicativo dos dados que o provedor do aplicativo armazenaria.
Conectando aplicativos ao armazenamento
É óbvio que criar aplicativos totalmente em HTML5 e JavaScript não é uma ideia nova. O tempero secreto do Unhosted é o método de conexão que vincula o aplicativo ao nó de armazenamento remoto – ou, para ser mais preciso, que vincula o aplicativo a qualquer nó de armazenamento definido pelo usuário. O sistema depende do Cross-Origin Resource Sharing (CORS), um mecanismo do W3C pelo qual um servidor pode optar por disponibilizar seus recursos a solicitações originárias de outros servidores.
No canônico exemplo “web mail”, o nó de armazenamento do Unhosted enxerga uma solicitação de origem cruzada do aplicativo de webmail, confere a fonte, as credenciais do usuário e o tipo de solicitação com base em sua lista de controle de acesso, e retorna os dados solicitados apenas se a solicitação for considerada válida. O UJJP define as operações que um aplicativo pode realizar no nó de armazenamento, incluindo a criação de um novo armazenamento de dados, a configuração e a recuperação de pares de chave-valor, a importação e a exportação de conjuntos de dados e a completa exclusão de um armazenamento de dados.
Em termos de segurança, cada aplicativo tem acesso apenas a seu próprio armazenamento de dados, e não a todo o espaço de armazenamento do usuário, e o CORS não permite que cada nó de armazenamento determine uma política quanto às origens que serão aceitas. O sistema também se apoia no acesso do usuário a todo o código fonte do aplicativo, porque ele roda no navegador. Portanto, o usuário pode observar se o aplicativo está fazendo algo suspeito, como retransmitindo credenciais de usuário para terceiros não confiáveis. Lidar com JavaScript potencialmente ofuscado pode ser problemático para os usuários, mas ainda assim é um avanço em relação ao processamento no lado do servidor, que acontece totalmente fora de seu alcance.
Por fim, cada aplicativo precisa de uma maneira de descobrir a qual nó de armazenamento um usuário está associado, de preferência sem ficar solicitando essas informações ao usuário toda hora. O código de demonstração atual do projeto Unhosted depende de descoberta de serviço baseada no Webfinger, que associa uma conta de usuário exclusivamente a um endereço de email. O usuário faz o login no aplicativo com um endereço de email, o aplicativo faz a consulta à identidade Webfinger do endereço para recuperar uma matriz em formato JSON de identificadores de recursos do Unhosted e se conecta da maneira apropriada para localizar o armazenamento de dados da conta.
A solução não é perfeita, porque exige que o provedor de email tenha suporte ao Webfinger. Outros mecanismos já foram propostos, incluindo o uso de IDs do Jabber e o Freedentity.
Onde a coisa complica
No momento, o ponto mais controverso do sistema é como proteger os dados armazenados sem tornar o sistema muito complicado de usar para os usuários finais. O modelo atual aposta na criptografia RSA e em assinaturas para todos os armazenamentos de dados. Embora o projeto afirme que isso se dê de forma totalmente transparente para os usuários, fica mais complicado quando um usuário de um aplicativo do Unhosted quer mandar uma mensagem para outro. Como o outro usuário está em um nó de armazenamento diferente, a chave pública desse usuário tem que ser recuperada para criptografar a mensagem. Mas o sistema não pode confiar cegamente em nenhum nó de armazenamento remoto para verificar de forma autoritativa a identidade de outro usuário – seria trivial interceptar essas informações. Para resolver esse problema, os desenvolvedores do Unhosted estão trabalhando em uma “infraestrutura de chave pública baseada em malha“ que permitirá que os usuários passem por uma rede confiável de um ID de usuário para outra. Os detalhes sobre essa parte do sistema ainda não foram revelados.
Outra pergunta no ar é qual tipo de mecanismo de armazenamento seria uma base adequada a um nó de armazenamento do Unhosted. O código de demonstração inclui servidores escritos em PHP, Perl e Python, todos rodando sobre servidores web HTTP comuns. Na lista de discussão, outros debateram uma maneira mais simples de implementar o armazenamento do Unhosted com o WebDAV, mas não há motivo para que um nó de armazenamento não possa ser implementado sobre um sistema de arquivos distribuído como o Tahoe, ou uma rede descentralizada como o BitTorrent.
Talvez o obstáculo mais fundamental ao Unhosted seja o fato dele abrir mão completamente do processamento no lado do servidor. Consequentemente, nenhum processo pode ocorrer enquanto o usuário estiver desconectado do aplicativo. “Desconectado” pode significar que a página ou aba está fechada, ou um aplicativo poderia oferecer um mecanismo de desconexão do nó de armazenamento, mas continuar realizando outras funções. Isso não é problema com aplicativo interativos ou baseados em mensagens, como os mensageiros instantâneos, mas limita o tipo de aplicativo que pode ser inserido no “molde” do Unhosted. A julgar pela lista de discussão, os integrantes do projeto vêm explorando o enfileiramento de operações no lado do nó de armazenamento, o que proporcionaria maior funcionalidade assíncrona, mas o Unhosted ainda não é um substituto a todo tipo de SaaS.
O estado do código
O projeto tem um repositório Github, que abriga código de demonstração apresentando as duas partes da plataforma Unhosted – embora avise em alto e bom tom aos seus usuários que o Unhosted não deve ser usado em ambientes de produção. O diretório “cloudside” inclui uma implementação de exemplo do nó de armazenamento do Unhosted, enquanto o diretório “wappside” inclui três aplicativos de exemplo criados para comunicação com o nó de armazenamento.
O módulo do nó de armazenamento fala CORS, e é escrito em PHP com backend MySQL. Ele não contém nenhuma autenticação no lado do servidor, então não deve ser implantado fora da rede local, mas funciona como um backend de amostra para aplicativos de exemplo.
O conjunto de aplicativos de exemplo inclui uma biblioteca JavaScript chamada unhosted.js, que incorpora assinatura de dados e verificação de assinatura RSA, criptografia e descriptografia e comunicação AJAX com o nó de armazenamento CORS. Um utilitário web de geração de chaves RSA é fornecido como cortesia, mas não é integrado aos aplicativos de exemplo.
O exemplo de nome “wappblog” é um aplicativo simples para atualização de blogs. Ele cria um editor de posts no lado do cliente, que atualiza o conteúdo de um arquivo HTML em um nó de armazenamento, que depois é recuperado para leitura por uma página separada. O aplicativo “wappmail” é um aplicativo de webmail simples, que exige que você configure algumas contas de usuário, mas demonstra a capacidade de enfileirar operações – mensagens de entrada são armazenadas e processadas quando cada usuário faz login.
O terceiro exemplo é um catálogo de endereços, que demonstra o sistema PKI baseado em malha (mas o documento avisa, “é tão novo que eu nem entendo como funciona direito, e foi incluído mais para quem estiver interessado em detalhes geek“).
Um conjunto mais prático de aplicativos de exemplo são os projetos de terceiros criados para o Unhosted na competição “Hacky Holydays” em dezembro. O vencedor foi o Scrapbook de Nathan Rugg, que permite que os usuários manipulem textos e imagens em um canvas HTML e mostra como um nó de armazenamento do Unhosted pode ser usado para armazenar mais do que texto puro. O segundo lugar foi dividido entre o mensageiro instantâneo NezAIM e o aplicativo de anotações Notes.
O quarto lugar, que ficou com o vCards, foi considerado uma menção honrosa, apesar de ter usado algumas técnicas de segurança do lado do cliente que não funcionariam em um ambiente distribuído no mundo real (como a criação de listas de controle de acesso no lado do cliente). O autor do vCards foi elogiado pela equipe por ter inovado com o protocolo – ele foi um dos primeiros a experimentar com enfileiramento, fazendo com que um aplicativo do Unhosted pudesse passar mensagens para outro.
Precisa-se de hackers
No momento, o Unhosted ainda é uma prova de conceito. O código do nó de armazenamento foi criado há pouco tempo, e ainda não foi submetido a um bom volume de testes de estresse no mundo real, nem passou por uma boa análise de segurança. Os desenvolvedores estão querendo opiniões para a próxima revisão do UJJP (0.3), na qual esperam definir mecanismos melhores para o controle de acesso dos nós de armazenamento (em parte para permitir a comunicação entre aplicativos) e uma API REST.
Eu posso imaginar avisos de que um script parou de responder no Firefox, e acho que aplicativos ricos em JavaScript rodando no lado do cliente soam como uma ideia terrível, mas temos que pensar na situação como um todo. O StatusNet, o Diaspora e outros serviços web federados fazem um ótimo trabalho ao libertar os usuários da dependência de um fornecedor proprietário de aplicativos, mas eles não foram criados para tornar o armazenamento subjacente um recurso comum, flexível e substituível. Uma das mais vívidas metáforas do projeto Unhosted para seu design “desacoplado” é a que diz que ele fornece “uma camada de graxa“ entre o software hospedado e os servidores que o hospedam. Essa é a ideia original, seja a camada superior escrita em JavaScript ou não.
Créditos a Nathan Willis – lwn.net
Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>
Deixe seu comentário