A plataforma aberta de aplicativos web da Mozilla

Mozilla’s open web app platform

Autor original: Nathan Willis

Publicado originalmente no: lwn.net

Tradução: Roberto Bechtlufft

O projeto Mozilla Labs está desenvolvendo o framework Open Web Apps, que tem como objetivo aprimorar a integração de aplicativos web com o sistema operacional. O framework usa recursos do HTML5 como o armazenamento local e padrões pré-existentes como o OpenID para criar um processo de instalação para aplicativos web que se assemelhe mais ao processo usado tradicionalmente para aplicativos feitos para o desktop. Anunciado oficialmente em outubro, as primeiras amostras de código já começaram a aparecer no Github.

Com base no anúncio oficial de outubro, e em um post de maio, a teoria parece ser a de que, no paradigma atual, os usuários praticamente só podem contar com os favoritos do navegador para manter o controle sobre os aplicativos web que usam com frequência. Por causa disso, os aplicativos web (mesmo com sua crescente popularidade) continuam separados do resto da experiência do sistema operacional. Sem uma presença persistente, cada um se comporta de maneira diferente em termos de procedimentos de login e afins.

Para completar, o post de maio sugere que quanto mais os desenvolvedores web criam aplicativos web disfarçados de aplicativos para smartphones, como o Android ou o iPhone da Apple, mais esses desenvolvedores passam a gostar da interface navegável e pesquisável das “lojas de aplicativos móveis”, que ainda permitem ao usuário dar nota aos aplicativos.

Do que se trata isso?

O Open Web Apps é uma experiência que tenta resolver os dois problemas ao mesmo tempo. Na parte dos aplicativos web, ele define um arquivo de manifesto baseado em JSON que cada aplicativo teria que incluir, com a descrição de seus metadados básicos – nome, ícone, criador, caminho de inicialização, URL de verificação e um conjunto de capacidades básicas. No que diz respeito ao navegador, o framework estabelece um padrão para um “repositório” de aplicativos web (que poderia ser implementado diretamente no código do navegador, na forma de uma extensão ou via JavaScript) composto de uma coleção desses manifestos, armazenados localmente.

Painel de controle do Mozilla Open Web Apps

O repositório tem duas APIs: uma que os sites podem usar para oferecer ao usuário uma opção “instalar este aplicativo web”, e outra que o navegador pode usar para mostrar ao usuário os aplicativos que ele já instalou. Há um demo em JavaScript rodando no site myapps.mozillalabs.com, usando a API de interface com o usuário para criar um painel que exibe o lançador de cada aplicativo do repositório e ainda oferecer uma opção de desinstalação.

Demonstração da loja do Mozilla Open Web Apps

Em apps.mozillalabs.com (atenção, é sem o “my” no início), o projeto tem várias implementações de demonstração do código de servidor, ilustrando várias possibilidades. Um aplicativo simples pode ser publicado automaticamente, ou seja, pode trazer seu próprio arquivo de manifesto e seu próprio botão de instalação, mas outros interessados podem criar listas, catalogar manifestos encontrados pela internet e apresentar esses aplicativos aos visitantes de seus sites, separando-os em categorias com avaliações. Também há uma demonstração da “loja” mostrando o esquema opcional de verificação, que pode ser usado para trabalhar com o login via OpenID e até para cobrar pela instalação de um aplicativo.

No momento, o conjunto de recursos oferecido pela demonstração é pequeno. Há meia dúzia de aplicativos disponíveis, mas só um usa a arquitetura de pagamento. É um aplicativo falso chamado TaskTracker, e você não paga nada por ele, já que o aplicativo nem existe de verdade. O painel tem ícones grandes, mas não oferece nenhuma funcionalidade que vá além do sistema de favoritos do Firefox (que ele se propõe a substituir).

Com isso, é fácil imaginar que o sistema de manifesto possa ser bom para desenvolvedores de aplicativos web se o modelo de loja de aplicativos decolar mesmo (a Mozilla não cansa de repetir na documentação que não está interessada em comandar uma loja ou um diretório desse tipo). A possibilidade de dar notas aos aplicativos e organizá-los é interessante, e o método unificado de verificação e pagamento simplificaria o login. Porém, do ponto de vista do usuário, não há nada de muito interessante. Atalhos são só atalhos, não importa o tamanho do ícone.

Expandindo a ideia

Talvez o futuro reserve coisas interessantes para essa arquitetura. O recurso (ainda não totalmente explorado) de descrever de antemão o que um aplicativo pode fazer ajuda os usuários a procurarem pelos aplicativos que querem. O wiki lista um punhado de propostas, incluindo suporte a localização geográfica, captura de mídia, acesso de leitura e escrita a arquivos, acesso de leitura aos contatos e por aí vai.

Tirando a geolocalização, poucos dos aplicativos web atuais usam recursos pelos quais os usuários possam estar procurando (ou querendo evitar), mas presume-se que haja novidades a caminho. O projeto Rainbow, da própria Mozilla, vincula hardware de gravação de áudio e vídeo em desktops a aplicativos web, por exemplo. A lista atual de recursos vem do grupo de trabalho de Permissões do W3C. A documentação e os posts também mencionam a renderização 3D, que também pode ser viável.

Um post de novembro apresenta um aprimoramento do esquema original que oferece benefícios claros ao usuário: a sincronização de repositórios entre vários computadores. O código desse recurso já está disponível no Github, mas como um servidor em separado. A funcionalidade de sincronizar dados de cliente entre os navegadores já está presente no Firefox Sync (que antes era chamado de Weave), então a sincronização de repositórios de aplicativos pode acabar chegando ao navegador.

Alguns dos recursos tidos como possíveis nas futuras melhorias da parte de cliente não podem ser implementadas no painel de demonstração em JavaScript no site myapps.mozillalabs.com devido à necessidade de acesso a código de baixo nível do navegador. O projeto afirma que as implementações baseadas em complementos vêm por aí, provavelmente para o Firefox primeiro, e também para o Firefox Mobile, mas é possível que apareçam também em outros navegadores com HTML5.

Outra melhoria na arquitetura, que já foi proposta e tem implicações para desenvolvedores de aplicativos é o suporte a manifestos assinados com criptografia, permitindo ao navegador verificar se o manifesto não foi alterado por alguém mal intencionado. A especificação do manifesto ainda está sendo revisada, e inclui uma discussão sobre a melhor maneira de permitir que um aplicativo delegue autoridade de instalação a terceiros – permitindo, por exemplo, que o manifesto de um aplicativo especifique quais lojas estão autorizadas a vender ou listar o aplicativo.

Para completar, o projeto menciona várias ideias para expandir as funcionalidades do repositório e do painel para uma melhor integração ao sistema operacional, como um framework de notificações, métodos de pesquisa entre aplicativos e um possível suporte a esquemas de experiência de usuário entre sites, como o OExchange, que poderia ser usado para unir o conteúdo de vários aplicativos diferentes em um mesmo conjunto unificado de documentos.

Segurança

Quando se fala em funcionalidade entre sites, a segurança é um assunto importante. O projeto tem uma página especial resumindo possíveis questões de segurança e privacidade na arquitetura Open Web App, e quando possível indica soluções.

Como o sistema é usado principalmente como forma de conexão a sites de terceiros, a maior parte dos vetores potenciais de ataques não se baseia em uma exploração direta do aplicativo web em questão (por exemplo, uma tentativa de roubar a senha do GMail de um usuário); isso seria uma falha de segurança do serviço em si. Em vez disso, a página descreve ataques contra as funções de repositório, instalação e verificação e também ao painel.

Alguns aspectos do sistema não introduzem novos vetores de ataques. Tentar adulterar o repositório em si ou os manifestos dos aplicativos instalados é como atacar a implementação do navegador para o armazenamento local do HTML5, mas é bom observar que a proposta de manifestos assinados mencionada anteriormente é uma medida de proteção contra esse problema. Situação parecida acontece no caso de uma interceptação do lançamento de um aplicativo por meio de um ataque man-in-the-middle, que equivale ao mesmo tipo de ataque contra a implementação de login do OpenID do site comum.

Por outro lado, seria possível construir um painel man-in-the-middle que interceptasse as solicitações de instalação ou lançamento de aplicativos e fornecesse conteúdo adulterado ao cliente. Isso só é possível com um painel hospedado, em JavaScript, e não em uma implementação nativa do painel em um navegador. O painel de demonstração em myapps.mozillalabs.com, obviamente, é um painel hospedado. A página do projeto sugere a implementação de painéis apenas sobre HTTPS para oferecer uma camada de proteção contra esse tipo de ataque. Mas segundo uma observação, se o navegador começar a implementar o painel em código local, o vetor de ataque desaparece.

Por fim, seria possível construir uma loja de aplicativos mal intencionada, que fizesse uso de iframes para enganar o usuário e fazê-lo instalar um aplicativo diferente do que ele desejava. A página observa que a Política de Segurança de Conteúdo pode oferecer proteção contra essa vulnerabilidade.

O retorno do Appzilla

Uma estranha ausência na documentação do projeto é como fica o esquema em relação ao outro produto de aplicativos web e integração ao desktop da Mozilla, o Mozilla Prism. O Prism é o navegador XULRunner renomeado, e pode ser usado para abrir sites em processos separados e que se comportam de forma mais semelhante a um aplicativo de desktop – residindo na bandeja do sistema, sendo executado durante a inicialização e coisas do gênero. Algumas das extensões propostas à arquitetura Open Web App parecem se encaixar bem com o Prism, mas não há nenhuma indicação de que a funcionalidade de repositório esteja a caminho dele.

O maior desafio ao crescimento do Open Web App não é a falta de suporte dos navegadores, mas sim o trabalho que vai dar para convencer os desenvolvedores web a criar sites que funcionem da mesma forma em todos os navegadores. A documentação do Open Web App toda hora menciona (inclusive no título do framework) a noção de que os aplicativos devem ser baseados em padrões livres e abertos: HTML5, CSS e JavaScript. Mas isso não vai acontecer só porque a Mozilla está pedindo. Nada no sistema impede os desenvolvedores de criarem sites que só rodem no Internet Explorer ou no iPhone e tascarem um arquivo de manifesto em plena conformidade no servidor – só o que vai acontecer é que a coisa não vai funcionar direito se a instalação for feita em um navegador diferente.

Ainda assim, essa é uma barreira que só pode ser superada evangelizando as pessoas, e não com especificações. A comunidade de desenvolvimento ao menos está ciente da diferença. Outro dia o Google anunciou uma loja de aplicativos semelhante, feita para operar apenas no navegador Chrome. Durante uma conferência de imprensa, um comentário de um leitor no Twitter foi retwitado várias vezes, onde ele perguntava “por que estamos criando aplicativos web para o Chrome, e não para a web?” Se a Mozilla estiver certa e os desenvolvedores quiserem mesmo um modelo de loja de aplicativos para levar seus trabalhos ao público, essa pergunta certamente vai soar encorajadora, mas ela provavelmente ainda vai ter uma longa estrada pela frente para tornar padrão aplicativos que funcionem em todos os navegadores.

Créditos a Nathan Willis – lwn.net

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>