A Spritely apresenta uma visão para construir aplicações descentralizadas e seguras por padrão, partindo do tratamento de três problemas fundamentais em sistemas distribuídos: controle de acesso, comunicação entre processos e nomenclatura de recursos. A apresentação foi conduzida por Christine Lemmer-Webber, diretora-executiva do Spritely Institute, e David Thompson, diretor técnico do instituto.
A ideia parte do princípio de que os serviços centralizados são mais fáceis de desenvolver do ponto de vista de engenharia, mas dão à entidade operadora grande capacidade de alterar o serviço, monitorar os usuários ou encerrar completamente o produto. A Spritely considera que a dependência de plataformas centralizadas deixa os usuários diante de opções limitadas, e que algumas leis criadas para atingir grandes empresas podem se transformar em «trincheiras legislativas», tornando a conformidade onerosa para projetos pequenos e para a hospedagem autônoma.
A segurança começa pelas capacidades, não por permissões gerais
O artigo critica os modelos de listas de controle de acesso e de funções, porque eles frequentemente dependem de grupos e permissões amplas, além de uma entidade administrativa central para conceder autorização. A alternativa apresentada pela Spritely é a segurança baseada em capacidades, na qual uma capacidade representa uma referência impossível de falsificar que combina a identificação do recurso com a concessão de permissão para utilizá-lo.
Na prática, o programa recebe apenas as capacidades que lhe são explicitamente transmitidas. Se uma aplicação não confiável for executada, por exemplo, ela pode receber permissão apenas para interagir com a tela e o teclado, em vez de ser executada com todas as permissões do usuário. Esse modelo permite reduzir a permissão ao delegá-la e transmiti-la a outra parte sem recorrer a um administrador central, além de possibilitar sua revogação posterior.
A Spritely traduz esses princípios em Goblins, um ambiente de programação distribuída segura baseado em capacidades. O artigo relaciona a transmissão de capacidades à passagem de argumentos em linguagens de programação, de modo que o acesso aos recursos se torna consequência direta do que a função ou o processo recebe, e não do que pode acessar implicitamente. Goblins também oferece suporte a concorrência, persistência e transações, incluindo o retorno a um estado anterior quando uma operação falha.
O modelo de atores e o protocolo OCapN
Para organizar a comunicação entre processos, a Spritely utiliza o modelo de atores, no qual cada ator recebe uma mensagem por vez e pode enviar mensagens a outros atores, criar novos atores ou alterar seu comportamento para a mensagem seguinte. Esse modelo combina comunicação assíncrona e gerenciamento de estado de uma forma que reduz a dependência de bloqueios compartilhados.
A Spritely considera que REST é adequado principalmente para aplicações cliente-servidor, mas não se ajusta a uma rede ponto a ponto composta por partes que não confiam umas nas outras. Já o OCapN, ou Object-Capability Network, acrescenta a transmissão de referências seguras às chamadas de procedimentos remotos. O protocolo é independente do meio de transporte e pode funcionar por WebSockets, serviços Tor onion ou outros meios; também oferece suporte à comunicação entre duas partes e à transmissão de objetos a uma terceira parte.
O OCapN utiliza um modelo de dados sem um esquema imposto na camada básica e oferece suporte a chamadas assíncronas e valores de promessa. O artigo menciona que já existem implementações em Scheme, JavaScript e Dart.
Nomenclatura local em vez de confiança cega em nomes públicos
A Spritely aborda o problema da nomenclatura de recursos por meio de sistemas de petnames, que dão aos usuários nomes locais escolhidos por eles para as entidades ou objetos que conhecem. Isso responde a problemas dos nomes de domínio, como phishing, sequestro de nomes e ataques de similaridade visual.
O artigo relaciona esse desafio ao chamado triângulo de Zooko, que pressupõe a dificuldade de combinar, em um único sistema, um nome compreensível para humanos, descentralização e segurança. Em vez de apresentar um nome global como prova suficiente de identidade, o modelo de petname concentra-se na relação local do usuário com o recurso.
O que muda na prática?
A Spritely oferece um conjunto de princípios e ferramentas mais do que um produto pronto para substituir os serviços centralizados. O valor central é a tentativa de tornar a segurança e a descentralização padrões para o desenvolvedor, em vez de exigir que ele redescubra décadas de pesquisas em sistemas distribuídos e segurança. No entanto, a própria apresentação não resolve as questões de adoção em larga escala, experiência do usuário, compatibilidade com as aplicações atuais ou gestão de recursos quando as partes se desconectam ou divergem.
Para arquitetos de software, a importância da abordagem está em combinar controle preciso de permissões com comunicação assíncrona e transmissão de referências. Para os desenvolvedores, o desafio continua sendo avaliar o grau de maturidade das ferramentas e dos protocolos e a disponibilidade de modelos operacionais mais simples do que as arquiteturas centralizadas habituais.