Spritely propose une vision pour construire des applications décentralisées et sécurisées par défaut, en partant du traitement de trois problèmes fondamentaux des systèmes distribués : le contrôle d’accès, la communication entre processus et le nommage des ressources. Cette vision a été présentée par Christine Lemmer-Webber, directrice exécutive du Spritely Institute, et David Thompson, directeur technique de l’institut.
L’idée part du constat que les services centralisés sont plus faciles à concevoir sur le plan technique, mais qu’ils donnent à l’opérateur une grande capacité de modifier le service, de surveiller les utilisateurs ou d’arrêter complètement le produit. Spritely estime que la dépendance à des plateformes centralisées laisse les utilisateurs face à des choix limités. En outre, certaines lois conçues pour cibler les grandes entreprises peuvent se transformer en « tranchées législatives », rendant la conformité coûteuse pour les petits projets et l’auto-hébergement.
La sécurité commence par les capacités, et non par des autorisations générales
L’article critique les modèles fondés sur les listes de contrôle d’accès et les rôles, car ils reposent souvent sur des groupes et des autorisations étendus, ainsi que sur une autorité administrative centrale chargée d’accorder les délégations. L’alternative présentée par Spritely est la sécurité fondée sur les capacités, dans laquelle une capacité est une référence infalsifiable combinant l’identification d’une ressource et l’autorisation de l’utiliser.
En pratique, un programme ne reçoit que les capacités qui lui sont explicitement transmises. Si une application non fiable est exécutée, on peut par exemple lui accorder uniquement l’autorisation d’interagir avec l’écran et le clavier, au lieu de l’exécuter avec tous les privilèges de l’utilisateur. Ce modèle permet de réduire une autorisation lorsqu’elle est déléguée et de la transmettre à une autre partie sans passer par un administrateur central ; elle peut également être révoquée ultérieurement.
Spritely traduit ces principes dans Goblins, un environnement de programmation distribuée sécurisé fondé sur les capacités. L’article établit un lien entre le passage de capacités et le passage d’arguments dans les langages de programmation : l’accès aux ressources devient ainsi la conséquence directe de ce que reçoit la fonction ou le processus, et non de ce auquel il peut accéder implicitement. Goblins prend également en charge la concurrence, la persistance et les transactions, y compris le retour à un état antérieur en cas d’échec de l’opération.
Le modèle des acteurs et le protocole OCapN
Pour organiser la communication entre les processus, Spritely s’appuie sur le modèle des acteurs. Chaque acteur reçoit un seul message à la fois et peut envoyer des messages à d’autres acteurs, en créer de nouveaux ou modifier son comportement pour le message suivant. Ce modèle associe la communication asynchrone et la gestion de l’état d’une manière qui réduit la dépendance aux verrous partagés.
Spritely considère que REST convient principalement aux applications client-serveur, mais qu’il est mal adapté à un réseau de pair à pair composé de parties qui ne se font pas confiance. OCapN, ou Object-Capability Network, ajoute le passage de références sécurisées aux appels de procédures distantes. Le protocole est indépendant du moyen de transport et peut fonctionner via des WebSockets, des services onion Tor ou d’autres moyens. Il prend également en charge la communication entre deux parties et le passage d’objets à une troisième partie.
OCapN utilise un modèle de données sans schéma imposé dans la couche de base et prend en charge les appels asynchrones ainsi que les valeurs de promesse. L’article indique qu’il dispose actuellement d’implémentations en Scheme, JavaScript et Dart.
Le nommage local plutôt qu’une confiance aveugle dans les noms publics
Spritely aborde le problème du nommage des ressources au moyen de systèmes de petname, qui attribuent aux utilisateurs des noms locaux qu’ils choisissent pour les entités ou les objets qu’ils connaissent. Cette approche répond aux problèmes liés aux noms de domaine, tels que l’hameçonnage, le détournement de noms et les attaques par similarité visuelle.
L’article relie ce défi à ce que l’on appelle le triangle de Zooko, qui suppose qu’il est difficile de réunir dans un même système un nom compréhensible par les humains, la décentralisation et la sécurité. Au lieu de présenter un nom global comme une preuve suffisante de l’identité, le modèle petname met l’accent sur la relation locale de l’utilisateur avec la ressource.
Qu’est-ce qui change en pratique ?
Spritely propose un ensemble de principes et d’outils davantage qu’un produit prêt à l’emploi destiné à remplacer les services centralisés. Sa valeur fondamentale réside dans la tentative de rendre la sécurité et la décentralisation natives pour le développeur, plutôt que de lui demander de redécouvrir des décennies de recherches sur les systèmes distribués et la sécurité. Toutefois, la présentation elle-même ne tranche pas les questions de l’adoption à grande échelle, de l’expérience utilisateur, de la compatibilité avec les applications actuelles ou de la gestion des ressources lorsque des parties sont déconnectées ou divergent.
Pour les architectes logiciels, l’importance de cette approche réside dans l’association d’un contrôle précis des autorisations avec la communication asynchrone et le passage de références. Pour les développeurs, le défi reste de déterminer le degré de maturité des outils et des protocoles, ainsi que la disponibilité de modèles d’exploitation plus simples que les architectures centralisées habituelles.