Spritely stellt ein Konzept für die Entwicklung dezentraler Anwendungen vor, die standardmäßig sicher sind, und geht dabei von der Behandlung dreier grundlegender Probleme verteilter Systeme aus: Zugriffskontrolle, Prozesskommunikation und Ressourcenbenennung. Dies geschah in einem Vortrag von Christine Lemmer-Webber, der Geschäftsführerin des Spritely Institute, und David Thompson, dem technischen Leiter des Instituts.
Die Idee geht davon aus, dass zentrale Dienste technisch einfacher sind, der betreibenden Stelle jedoch weitreichende Möglichkeiten geben, den Dienst zu ändern, Nutzer zu überwachen oder das Produkt vollständig einzustellen. Spritely ist der Ansicht, dass die Abhängigkeit von zentralen Plattformen den Nutzern nur begrenzte Optionen lässt. Zudem könnten einige Gesetze, die auf große Unternehmen abzielen, zu «gesetzgeberischen Burggräben» werden, die die Einhaltung der Vorschriften für kleine Projekte und selbst gehostete Angebote kostspielig machen.
Sicherheit beginnt mit Capabilities, nicht mit allgemeinen Berechtigungen
Der Beitrag kritisiert Modelle mit Zugriffskontrolllisten und Rollen, da diese häufig auf weit gefassten Gruppen und Berechtigungen sowie auf einer zentralen Verwaltungsstelle zur Vergabe von Autorisierungen beruhen. Die von Spritely vorgestellte Alternative ist Capability-Security, bei der eine Capability eine nicht fälschbare Referenz darstellt, die die Identifizierung einer Ressource und die Erlaubnis zu ihrer Nutzung miteinander verbindet.
Praktisch erhält ein Programm nur die Capabilities, die ihm ausdrücklich übergeben werden. Wird eine nicht vertrauenswürdige Anwendung ausgeführt, kann ihr beispielsweise nur die Berechtigung zur Verwendung von Bildschirm und Tastatur erteilt werden, anstatt sie mit allen Berechtigungen des Nutzers auszustatten. Dieses Modell ermöglicht es, eine Capability bei ihrer Weitergabe einzuschränken und sie ohne Rückgriff auf einen zentralen Verwalter an eine andere Partei weiterzugeben; außerdem kann sie später widerrufen werden.
Spritely setzt diese Prinzipien in Goblins um, einer sicheren verteilten Programmierumgebung, die auf Capabilities basiert. Der Beitrag stellt eine Verbindung zwischen der Übergabe von Capabilities und der Übergabe von Argumenten in Programmiersprachen her: Der Zugriff auf Ressourcen wird dadurch zu einem unmittelbaren Ergebnis dessen, was eine Funktion oder ein Prozess erhält, und nicht dessen, worauf er implizit zugreifen kann. Goblins unterstützt außerdem Nebenläufigkeit, Persistenz und Transaktionen, einschließlich der Rückkehr zu einem früheren Zustand, wenn der Vorgang fehlschlägt.
Das Actor-Modell und das OCapN-Protokoll
Zur Organisation der Kommunikation zwischen Prozessen setzt Spritely auf das Actor-Modell. Dabei empfängt jeder Actor jeweils eine Nachricht und kann Nachrichten an andere Actors senden, neue Actors erzeugen oder sein Verhalten für die nächste Nachricht ändern. Dieses Modell verbindet asynchrone Kommunikation mit Zustandsverwaltung auf eine Weise, die die Abhängigkeit von gemeinsam genutzten Sperren verringert.
Spritely ist der Ansicht, dass REST in erster Linie für Client-Server-Anwendungen geeignet ist, jedoch nicht zu einem Peer-to-Peer-Netz passt, das aus Parteien besteht, die einander nicht vertrauen. OCapN, also Object-Capability Network, ergänzt entfernte Prozeduraufrufe um die Übergabe sicherer Referenzen. Das Protokoll ist unabhängig vom Übertragungsweg und kann über WebSockets, Tor-Onion-Dienste oder andere Mittel betrieben werden. Außerdem unterstützt es die Kommunikation zwischen zwei Parteien und die Weitergabe von Objekten an eine dritte Partei.
OCapN verwendet auf der Basisebene ein Datenmodell ohne vorgeschriebenes Schema und unterstützt asynchrone Aufrufe sowie Promise-Werte. Der Beitrag erwähnt, dass es derzeit Implementierungen in Scheme, JavaScript und Dart gibt.
Lokale Benennung statt blindem Vertrauen in öffentliche Namen
Spritely befasst sich mit dem Problem der Ressourcenbenennung durch Petname-Systeme, die Nutzern lokale Namen geben, die sie für ihnen bekannte Parteien oder Objekte auswählen. Dies ist eine Reaktion auf Probleme von Domainnamen wie Phishing, Namensübernahmen und visuelle Ähnlichkeitsangriffe.
Der Beitrag verknüpft diese Herausforderung mit dem sogenannten Zooko-Dreieck, das von der Schwierigkeit ausgeht, in einem einzigen System einen für Menschen verständlichen Namen, Dezentralisierung und Sicherheit zu vereinen. Anstatt einen globalen Namen als ausreichenden Identitätsnachweis zu präsentieren, konzentriert sich das Petname-Modell auf die lokale Beziehung des Nutzers zur Ressource.
Was ändert sich praktisch?
Spritely bietet eher ein Bündel von Prinzipien und Werkzeugen als ein fertiges Produkt, das zentrale Dienste ersetzt. Der zentrale Wert liegt in dem Versuch, Sicherheit und Dezentralisierung für Entwickler standardmäßig bereitzustellen, anstatt von ihnen zu verlangen, Jahrzehnte der Forschung zu verteilten und sicheren Systemen erneut zu erschließen. Der Vortrag selbst beantwortet jedoch nicht abschließend die Fragen der breiten Akzeptanz, der Nutzererfahrung, der Kompatibilität mit bestehenden Anwendungen oder des Umgangs mit Ressourcen, wenn Parteien ausfallen oder voneinander abweichen.
Für Softwarearchitekten liegt die Bedeutung des Ansatzes in der Verbindung einer präzisen Berechtigungskontrolle mit asynchroner Kommunikation und der Übergabe von Referenzen. Für Entwickler bleibt die Herausforderung, wie ausgereift die Werkzeuge und Protokolle sind und ob einfachere Betriebsmodelle als die üblichen zentralisierten Architekturen verfügbar sind.