Spritely presenta una visión para construir aplicaciones descentralizadas y seguras por defecto, partiendo del tratamiento de tres problemas fundamentales de los sistemas distribuidos: el control de acceso, la comunicación entre procesos y la nomenclatura de recursos. Así se expuso en una presentación ofrecida por Christine Lemmer-Webber, directora ejecutiva de Spritely Institute, y David Thompson, director técnico del instituto.
La idea parte de que los servicios centralizados son más sencillos desde el punto de vista de la ingeniería, pero otorgan a la entidad operadora una gran capacidad para cambiar el servicio, vigilar a los usuarios o detener por completo el producto. Spritely considera que la dependencia de plataformas centralizadas deja a los usuarios ante opciones limitadas, y que algunas leyes diseñadas para dirigirse contra las grandes empresas pueden transformarse en «trincheras legislativas» que encarecen el cumplimiento para los proyectos pequeños y el alojamiento propio.
La seguridad comienza con las capacidades, no con permisos generales
El artículo critica los modelos de listas de control de acceso y roles, porque suelen depender de grupos y permisos amplios, así como de una entidad administrativa central para conceder la autorización. La alternativa que presenta Spritely es la seguridad basada en capacidades, en la que una capacidad representa una referencia imposible de falsificar que combina la identificación del recurso con la concesión del permiso para utilizarlo.
En la práctica, el programa solo obtiene las capacidades que se le pasan explícitamente. Si se ejecuta una aplicación no confiable, por ejemplo, se le puede conceder permiso para interactuar únicamente con la pantalla y el teclado, en lugar de ejecutarla con todos los permisos del usuario. Este modelo permite reducir el permiso al delegarlo y pasarlo a otra parte sin volver a un administrador central; también es posible revocarlo posteriormente.
Spritely traduce estos principios en Goblins, un entorno seguro de programación distribuida basado en capacidades. El artículo relaciona el paso de capacidades con el paso de argumentos en los lenguajes de programación, de modo que el acceso a los recursos se convierte en un resultado directo de lo que recibe la función o el proceso, y no de aquello a lo que puede acceder implícitamente. Goblins también admite la concurrencia, la persistencia y las transacciones, incluido el retroceso a un estado anterior cuando falla la operación.
El modelo de actores y el protocolo OCapN
Para organizar la comunicación entre procesos, Spritely se basa en el modelo de actores, en el que cada actor recibe un mensaje a la vez y puede enviar mensajes a otros actores, crear actores nuevos o cambiar su comportamiento para el mensaje siguiente. Este modelo combina la comunicación asíncrona con la gestión del estado de una manera que reduce la dependencia de bloqueos compartidos.
Spritely considera que REST es adecuado principalmente para aplicaciones de cliente y servidor, pero que no encaja en una red entre pares formada por partes que no confían unas en otras. OCapN, u Object-Capability Network, añade el paso de referencias seguras a las llamadas a procedimientos remotos. El protocolo es independiente del medio de transporte y puede ejecutarse mediante WebSockets, servicios onion de Tor u otros medios; también admite la comunicación entre dos partes y el paso de objetos a una tercera parte.
OCapN utiliza un modelo de datos sin un esquema impuesto en la capa básica y admite llamadas asíncronas y valores de promesa. El artículo señala que actualmente cuenta con implementaciones en Scheme, JavaScript y Dart.
Nomenclatura local en lugar de confiar ciegamente en nombres públicos
Spritely aborda el problema de la nomenclatura de recursos mediante sistemas petname, que proporcionan al usuario nombres locales que este elige para las entidades u objetos que conoce. Esto responde a problemas de los nombres de dominio, como el phishing, el secuestro de nombres y los ataques de similitud visual.
El artículo relaciona este desafío con lo que se conoce como el triángulo de Zooko, que presupone la dificultad de combinar en un mismo sistema un nombre comprensible para los seres humanos, la descentralización y la seguridad. En lugar de presentar un nombre global como prueba suficiente de identidad, el modelo petname se centra en la relación local del usuario con el recurso.
¿Qué cambia en la práctica?
Spritely ofrece un conjunto de principios y herramientas más que un producto listo para sustituir a los servicios centralizados. El valor fundamental consiste en intentar que la seguridad y la descentralización sean opciones predeterminadas para el desarrollador, en lugar de exigirle redescubrir décadas de investigación sobre sistemas distribuidos y seguridad. Sin embargo, la propia presentación no resuelve las cuestiones de la adopción a gran escala, la experiencia de usuario, la compatibilidad con las aplicaciones actuales ni la forma de gestionar los recursos cuando las partes se desconectan o discrepan.
Para los arquitectos de software, la importancia del enfoque reside en combinar un control preciso de los permisos con la comunicación asíncrona y el paso de referencias. Para los desarrolladores, el desafío sigue siendo determinar hasta qué punto han madurado las herramientas y los protocolos, y si existen modelos operativos más sencillos que las arquitecturas centralizadas habituales.