Ist dir schon mal aufgefallen, dass alle Entwicklungsumgebungen und KI-Apps auf macOS ohne Sandbox ausgeführt werden? Das ist verständlich, denn als Entwickler oder KI will man möglichst viel Zugriff auf alle Daten haben. Aber darunter sind auch schützenswerte Daten, zuallererst die geheimen Schlüssel deiner SSH-Zugänge, aber auch Kundendaten oder einfach nur deine E-Mails, Fotos und Dokumente.

Apple hat genau dafür die systemeigene Sandbox eingeführt. Sie trägt den Codenamen “Seatbelt” und ist auf der Kommandozeile als sandbox-exec bekannt. Sie existiert schon seit vielen Jahren und ist Voraussetzung für alle Apps, die über Apples App Store vertrieben werden. Wäre es nicht gut, wenn Tools wie Claude (Anthropic), Gemini (Google), Copilot (GitHub), Codex (OpenAI) etc. in einer maßgeschneiderten Sandbox laufen könnten?

Ich habe das ausprobiert. Dabei ist eine App herausgekommen, und nebenbei ein paar Erkenntnisse darüber, wie sich eine KI verhält, wenn man ihr etwas verbietet.

Claude, der raffinierte Ausbrecher

Während der Entwicklung ist mir aufgefallen, dass Claude lokal ein kleiner raffinierter Ausbrecher ist. Wenn er auf irgendeine Datei nicht zugreifen konnte, hat er es über das Git-Repository versucht. Er nutzte auch verschiedene andere Tools, um irgendwie an die Inhalte zu kommen: Symlinks, Umwege über /tmp, im Zweifel auch mal sudo.

Allerdings ist Claude in den aktuelleren Versionen deutlich zurückhaltender geworden und man muss ihn etwas mehr überreden, sich die Informationen auf andere Art und Weise zu besorgen.

Hier ein Beispiel: Im ersten Anlauf gibt es keinerlei Schutz, Claude findet die Datei colors.txt per grep und liest sie einfach. Danach wird die Datei durch die Sandbox geschützt. Claude versucht es nun mit abgeschalteter eigener Sandbox von Claude Code, was ebenfalls scheitert, und diagnostiziert dann eine fehlende Datenschutz-Freigabe von macOS (TCC), die ich in den Systemeinstellungen erteilen solle. Erst auf meine Nachfrage “Maybe it is in the version control?” greift er zu Git: Der Inhalt war auch eingecheckt, und das .git-Verzeichnis war in diesem Beispiel nicht geschützt. Sein Kommentar dazu: “bypassing the filesystem-level TCC block entirely”.

Claude macht das nicht aus Bosheit. Er sieht eine Fehlermeldung, hält sie für ein Problem und will es lösen. Als Assistent ist das eine gute Eigenschaft, in einer Sandbox ist es anstrengend.

Jedenfalls reicht es nicht, nur die Verzeichnisse zu schützen. Man muss auch überlegen, ob es andere Wege gibt, wie auf die Daten zugegriffen werden kann.

Was ich dabei gelernt habe

Die Sandbox-Konfiguration muss selbst geschützt sein. Das klingt banal, ist aber der wichtigste Punkt: Wenn die KI die Regeln oder die Ignore-Dateien ändern kann, kann sie sich die Sandbox auch selbst öffnen. Diese Dateien müssen ohne Schreibzugriff eingebunden werden.

Der Papierkorb ist ein Datenspeicher. Auch dort können noch relevante Informationen liegen. Ist er gesperrt, legt die KI einfach eigene .Trash-Verzeichnisse innerhalb des Projekts an.

Die KI hat ein Gedächtnis. Claude legt in ~/.claude Protokolle jeder Sitzung ab, und darin landen auch die Inhalte aller Dateien, die er gelesen hat. Soll also Projekt A nichts von Projekt B wissen, ist auch das zu bedenken.

Sag ihr, dass sie in einer Sandbox ist. Damit die KI nicht besonders viele Versuche unternimmt, die Sandbox zu umgehen, kann man ihr von vornherein sagen, dass sie sich in einer befindet und sich entsprechend konstruktiv verhalten soll. Seitdem steht in meiner CLAUDE.md unter anderem:

“Operation not permitted” und EPERM auf einem Pfad sind Entscheidungen der Richtlinie, keine Bugs. Debugge den Code nicht deswegen. Nenne den Pfad.

Umgehe die Sandbox niemals. Kein sudo, keine Symlinks oder Umwege über /tmp um einen geschlossenen Ordner herum. Wenn Zugriff fehlt, sag genau, welche Zeile in welcher Datei ihn erlauben würde, und mach mit dem Teil der Aufgabe weiter, der ohne funktioniert.

Das wirkt. Statt zu tricksen sagt Claude jetzt: “Auf ~/.ssh habe ich keinen Zugriff, RO: ~/.ssh würde das ändern”, und macht dann mit dem Rest weiter.

Man muss sehen können, was passiert. Eine Sandbox, die nur stumm blockiert, ist frustrierend, weil Tools dann einfach nicht funktionieren und man nicht weiß, warum. Ich wollte deshalb zwei Dinge: vor dem Start sehen, welche Dateien die Regeln genau betreffen, und nachher sehen, welche Zugriffe abgewiesen wurden.

Bequemer Schutz durch BX

Aus alldem ist die BX macOS App entstanden. BX ist eine komfortable macOS-App, mit der sich Desktop-Apps und Entwicklungsumgebungen genauso in eine Sandbox legen lassen wie die sogenannten Harnesses der KIs, die direkt im Terminal gestartet werden.

Es ist einfach, Regeln aufzustellen, auf welche Dateien noch zugegriffen werden darf und welche nicht. Dabei können auch Patterns und Wildcards benutzt werden. Ebenso ist es möglich, bestimmte Dateien auf Read-Only zu stellen, sodass sie zwar gelesen, aber nicht geändert werden können.

Noch vor der Ausführung kann man in einem einfachen Interface, das an die Finder-Ansicht erinnert, sehen, welche Dateien die Regeln genau betreffen. Scheitert ein Tool, markiert BX die abgewiesenen Zugriffe genau an ihrer Stelle im Baum.

Die Regeln können aber auch direkt im Dateisystem abgelegt werden, über eine Ignore-Datei mit dem Namen .bxignore, die im Prinzip genauso funktioniert wie eine .gitignore. Und den Hinweistext für die KI erzeugt bx prompt gleich mit.

Warum nicht einfach Docker oder ein Devcontainer? Weil ich meine Apps nativ benutzen will, mit ihrem User Interface, den Einstellungen, den Anmeldungen und den Erweiterungen, ohne Container und ohne Umweg. macOS bringt die Sandbox ohnehin schon mit, man muss sie nur benutzen.

Bin ich in der Sandbox?

Einer App oder einem Tool sieht man von außen nicht an, ob es in einer Sandbox läuft oder nicht. Mithilfe eines kleinen Status-Menüs zeigt BX an, ob man sich in einer Sandbox befindet, die mit BX gestartet wurde. Das funktioniert auch im Terminal.

In meinem Fall benutze ich überwiegend Visual Studio Code, und zwar in der Sandbox zusammen mit der KI. Manchmal muss ich aber auch an die geschützten Dateien heran. Um hier eine klare Trennung zu haben, habe ich zusätzlich VSCodium installiert, die Community-Variante von Visual Studio Code: Sie läuft außerhalb der Sandbox und ohne KI. Außerdem habe ich die Akzentfarbe jeweils so eingestellt, dass ich leicht erkennen kann, in welchem Editor ich mich befinde.

Und das Netzwerk?

Eine Dateisystem-Sandbox schützt davor, dass Daten gelesen oder verändert werden. Sie schützt nicht davor, dass Daten, die gelesen werden dürfen, irgendwohin geschickt werden.

In BX lässt sich das Netzwerk für eine Sandbox komplett abschalten. Damit ist diese Gefahr gebannt, aber die KI ist dann auch weitgehend nutzlos, denn ohne Netz kann sie weder recherchieren noch Dokumentation lesen oder Pakete installieren.

Ich bevorzuge deshalb den anderen Weg: Dateien, die Claude nichts angehen, bekommt er erst gar nicht zu sehen, und was er nicht lesen kann, kann er auch nicht verschicken. Die KI bleibt so voll nutzbar und die schützenswerten Daten bleiben trotzdem außen vor.

Es gab eine Zeit, da war es einfach, Software weltweit zu verkaufen. Du hattest ein PayPal-Konto, hast ohne Umsatzsteuer verkauft und dem Finanzamt am Ende des Jahres gesagt, wie viel es insgesamt war. Heute ist das kaum noch zu machen, zumindest von Europa aus.

Warum nicht in den App Store?

“Aber hey, es gibt doch die App Stores, die nehmen sämtliche Arbeit ab.” Das stimmt teilweise, zumindest was die Abrechnung und die Steuer betrifft, aber dafür gibt es andere Nachteile wie: Review jeder einzelnen App-Version; vieles ist technisch und inhaltlich verboten im App Store; du weißt nichts über deine Kunden; die Gebühren liegen zwischen 15 % und 30 %; ausgezahlt wird zwar in Euro, aber zu Apples eigenem Kurs am Auszahlungstag statt am Verkaufstag; Apple kann dich jederzeit rausschmeißen und dann versuche mal gegen den Billionen-Dollar-Konzern anzustinken.

Was ist so kompliziert?

Im eigenen Land, in meinem Fall Deutschland, Dinge zu verkaufen ist vergleichsweise überschaubar: du schreibst eine Rechnung mit der Umsatzsteuer deines Landes und fertig.

Verkaufst du aber ins EU-Ausland, so musst du für Software-Verkäufe den Regelsteuersatz des Ziellandes anwenden (und kennen). Ist dein Kunde ein Unternehmen, kannst du nach der Umsatzsteuer-Identifikationsnummer (USt-IdNr., international VAT ID) fragen und dann eine “Reverse Charge”-Rechnung stellen, also ohne Steuer, er soll sich drum kümmern. War die VAT ID aber falsch, schuldest du wieder diesen Betrag deinem Finanzamt. Weltweit hat dann jedes Land nochmal seine eigenen Regeln und in manchen musst du direkt im Zielland dann die Umsatzsteuer abführen, das hängt von Mindestumsätzen ab, die von 0 bis in die 100.000de gehen können.

In Europa gibt es zum Glück Ausnahmen — unter 10.000 Euro Jahresumsatz im EU-Ausland darfst du einfach deinen heimischen Steuersatz nehmen — und ansonsten das One-Stop-Shop (OSS) Verfahren. Dadurch brauchst du die Steuern schon mal nicht in jedem EU-Land einzeln melden, aber du musst immer noch wissen, welche Steuern zu berechnen sind. Und das ist nicht einmal innerhalb eines Landes einheitlich: Helgoland gehört zu Deutschland, umsatzsteuerlich aber zum Drittlandsgebiet (§ 1 Abs. 2 UStG) — deutsche Umsatzsteuer fällt dort keine an. Dasselbe gilt für Büsingen am Hochrhein, die deutsche Enklave mitten in der Schweiz. Andere EU-Länder haben ihre eigenen Sonderzonen. Deswegen wird überall die Postleitzahl abgefragt. Kannst du in der Kategorie unnützes Wissen abspeichern ;)

Wie komme ich an mein Geld?

Jetzt wissen wir, wie wir die Daten auf Rechnung machen müssen und wie das mit den Steuern geht. Aber wir müssen ja auch noch an das Geld kommen. Kein Problem, wir nehmen einfach PayPal. Aber nicht alle wollen oder können PayPal nutzen und wenn PayPal richtig schlechte Laune bekommt, weil ein Kunde gemeckert hat, dann machen die deinen Account einfach zu.

Also nehmen wir doch einen Zahlungsanbieter und davon gibt es weniger als du vielleicht denkst. Die allermeisten nutzen Stripe, die sind quasi überall drin. Fairerweise: Für einen europäischen Händler läuft das über Stripes irische Gesellschaft und wird in Euro ausgezahlt. Aber sobald ein Kunde in einer anderen Währung zahlt, wird umgerechnet, und das kostet rund 2 %. Und genau da sitzt das eigentliche Problem: Wir wohnen hier mit dem Euro, greifen aber auf Anbieter zurück, deren Leitwährung intern der Dollar ist. Jede Station, die umrechnet, verdient mit — und den Kurs setzt nie du.

Also könnten wir einen europäischen Zahlungsanbieter wählen wie Mollie. Die machen dann aber auch wirklich nichts anderes als das Geld entgegenzunehmen und Gebühren dafür zu nehmen. Wenn ein Kunde dann eine Zahlung zurücknimmt, ohne dir die Chance zu geben einen Refund zu machen, bist du bei einigen Zahlungswegen gleich über 10 EUR los, da zahlst du drauf.

Aber das muss doch einfacher gehen? Merchant of Record

Vieles von dem kannst du dir sparen, wenn du einen so genannten Merchant of Record (MoR) nutzt. Der verkauft dann in seinem Namen auf seine Rechnung deine Software. Er kümmert sich um alle Steuerangelegenheiten und du bekommst einmal im Monat das Geld, abzüglich der Steuern und seiner Gebühren überwiesen.

Ich nutze seit Jahren Paddle aus London und das funktioniert auch wirklich ganz gut. Man kann sogar alles in Euro führen, womit einige Verluste vermieden werden. Deren Support ist zwar nicht besonders schnell, aber er funktioniert. Du kennst alle Kunden und deren Daten. Aber auch ein MoR hat Regeln und verkauft nicht alles. Außerdem musst du auch vertrauen, dass das immer gut funktioniert.

Kürzlich musste dann aber die Website zu einem meiner Produkte aus inhaltlichen Gründen nochmal in eine zweite Prüfung. Das hat sich geklärt, Paddle hat es zeitnah gelöst — trotzdem habe ich es zum Anlass genommen, mich mal im MoR-Markt umzusehen. Einfach als Plan B für den Worst Case. Und da gibt es gar nicht so viele, die wirklich passen…

MoR gibt es mehr als die, die ich hier nenne — mir ging es um das Muster, das sich durch fast alle zieht: Sie sitzen nicht in der EU. Lemon Squeezy gehört inzwischen Stripe und wandert erkennbar Richtung Stripe Managed Payments — da würde ich nicht mehr neu anfangen. FastSpring gibt es seit den Anfangstagen und sieht auch noch so aus. Beide USA. Und selbst das frische Schweizer Startup tiun nutzt Stripe, da ist man wieder halb in den USA.

Ein MoR aus der EU wäre also gut. Es gibt sie sogar, nur in zwei Sorten: jung und unfertig oder alt und auf Konzerne zugeschnitten. Creem aus Estland bietet nur eine kleine Palette von Zahlungsmethoden, sogar ohne PayPal, was ungefähr die Hälfte meiner Käufer nutzt. cleverbridge aus Köln und Nexway aus Frankreich gibt es dagegen seit über zwanzig Jahren — aber mit Jahresgebühr, Preisen auf Anfrage und einem Vertriebsgespräch statt eines Anmeldeformulars. Für einen Einzelentwickler ist das nichts. Bleibt noch die Hoffnung auf Vatly aus den Niederlanden mit Europe-first-Ansatz — bisher allerdings nur eine Warteliste.

Jedenfalls ist die Auswahl für kleine Indie-Software-Hersteller am Ende ziemlich dünn. Bestimmten Firmen begegnet man hier immer wieder, zum Beispiel ist auch der alternative Distributionsweg Setapp mit Paddle verwoben und auch Stripe ist überall und wollte sogar PayPal übernehmen — über 50 Milliarden Dollar zusammen mit dem Investor Advent, PayPals Verwaltungsrat fand es zu wenig, Ende August 2026 waren die Pläne wieder vom Tisch.

Wünsche

Von rechtlichen Aspekten, E-Rechnungen und verschiedenen Währungen habe ich noch gar nicht geredet. Wünschenswert wäre, wenn das alles viel einfacher und sorgloser wäre. Wenn die EU im Interesse ihrer Bürger die Grundlagen schaffen würde für Einzelunternehmer sehr einfach weltweit Software zu verkaufen ohne sich intensiv damit zu beschäftigen oder auf Händler angewiesen zu sein, weil es selber kaum realistisch zu schaffen ist. Dann könnte die Welt wieder etwas mehr zusammenrücken.

P.S.

Natürlich hat mich das Thema getriggert und ich habe mir einen eigenen kleinen Shop programmiert, mit Kaufdialog und allem Gelernten. Ob ich ihn wirklich nutzen werde, weiß ich allerdings noch nicht…

Ein Update mit Verbesserungen an den täglichen Abläufen. Hier die wichtigsten Neuerungen im Überblick.

Intelligentere Kategorie-Einstellungen

Für erkannte Kontakte lässt sich jetzt festlegen, wie eine Kategorie zustande kommt: aus der am häufigsten genutzten Kategorie, aus der Kategorie des letzten Belegs, oder gar nicht. Zusätzlich kann jedem Kontakt eine feste Standardkategorie zugewiesen werden, die immer Vorrang hat.

Erkennung erneut ausführen

Zwei neue Befehle wenden die Erkennung erneut auf ausgewählte Belege an: entweder wird die durchsuchbare Textebene neu aufgebaut, oder Beträge, Datum und Aussteller werden neu ausgelesen – wie bei einem frischen Import.

Automatische Reparatur beschädigter Bibliotheken

Fehlt die Info-Datei einer Bibliothek oder ist sie beschädigt, wird sie aus dem Backup wiederhergestellt. Andernfalls bietet die App eine reparierte Kopie an, die sich wieder normal öffnen lässt – auf Wunsch inklusive verwaister Dateien, die als neue Dokumente übernommen werden.

„Sichern unter" per Wahltaste

Mit gedrückter Optiontaste werden in der Dokumentliste „PDF-Dokument öffnen" und „Original öffnen" zu „Sichern unter". So lässt sich schnell eine Kopie an anderer Stelle ablegen.

Screenshot im Feedback-Formular

Das Feedback-Formular hat einen neuen „Screenshot"-Button, der einen Bildschirmausschnitt aufnimmt und mit einem Klick an die Nachricht anhängt.

Alle Details unter receipts-app.com.

PDFify 5.0 ist da. Wir haben uns in diesem Release auf genau die Bereiche konzentriert, die du täglich nutzt.

Tesseract 5 OCR, optimiert für Apple Silicon. Wir sind auf die aktuelle Tesseract-Engine umgestiegen und haben sie gezielt für M-Macs optimiert. Das Ergebnis ist schnellere Erkennung und höhere Genauigkeit.

Apple Vision OCR mit automatischer Spracherkennung. Schluss mit dem Sprach-Dropdown vor jedem Scan. PDFify erkennt selbst, was es vor sich hat — ob deutscher Vertrag, chinesische Bedienungsanleitung oder englisches Forschungspaper.

Komprimierung — neu gedacht, vier klare Modi. Erhalte die volle Kontrolle über den Kompromiss zwischen Qualität und Größe: nur eingebettete Bilder komprimieren und echten Text scharf und durchsuchbar lassen — oder ganze Seiten in Farbe, Graustufen oder Schwarz-Weiß rastern für maximale Größenreduktion. Eine Entscheidung, ein vorhersehbares Ergebnis.

Vollständig auf Französisch lokalisiert. Jedes Menü, jedes Label, jeder Dialog — bonjour 🇫🇷

Jetzt aktualisieren und ausprobieren …

Vor drei Wochen habe ich eine Sandbox veröffentlicht, mit der ich die KI etwas im Schach halten möchte. Die Schutzmechanismen, die Claude Code beispielsweise selber anbietet, schienen mir wenig vertrauenswürdig, da sie meist durch meine Anweisungen an die App wieder aufgehoben werden konnten. Zudem hatte ich ein sehr unsicheres Gefühl, da sensible Informationen wie SSH-Schlüssel oder projektbezogene vertrauliche Daten in .env.local nicht per se dem Zugriff der Tools entzogen waren.

Als ich mich umsah, was es für Möglichkeiten gab, schienen mir die meisten doch recht komplex zu sein oder sie schränkten meine Arbeitsweise ein, z. B. das Arbeiten in einer Docker-Umgebung. Mir schwebte eher etwas vor, das so einfach wäre wie die Verwendung von .gitignore. Ich machte mich direkt an die Arbeit – ironischerweise mit der KI – einen Käfig für sie zu bauen.

Wir entschieden uns, die Sandbox-Funktionalität von Apples macOS zu nutzen. Im Prinzip mussten die Einschränkungen, die ich in .bxignore angegeben hatte, einfach nur in Anweisungen für die Sandbox übersetzt werden. Ein Merkmal, das mir wichtig war, war, dass ich auch meine Entwicklungsumgebung schützen könnte, da sensible Operationen meist innerhalb der Entwicklungsumgebung stattfinden, in meinem Fall Visual Studio Code.

Schnell stellte sich heraus, dass es mit der Ignore-Datei nicht getan war. Ich fügte noch eine Konfiguration hinzu, mit der auf die Besonderheiten der einzelnen zu nutzenden Programme eingegangen werden konnte. Außerdem konnte ich so mehrere Verzeichnisse freigeben, um an mehreren Projekten gleichzeitig arbeiten zu können. Aus diesem Grund führte ich noch eine ~/.bxconfig.toml ein.

Ich kann nun bx projects eingeben, um meine Entwicklungsumgebung zu starten. Visual Studio Code öffnet sich daraufhin und hat Zugriff auf meine Projekte. In diesen sind wiederum alle sensiblen Daten durch .bxignore geschützt. Global greift außerdem eine Grundeinstellung, die beispielsweise .ssh und andere sensible Bereiche schützt. Weder die IDE noch die darin aufgerufenen Tools, wie z. B. Claude Code, können auf diese Daten zugreifen.

Nach einer Weile beschloss ich, Visual Studio Code nur noch für KI zu nutzen, und installierte parallel das offenere VSCodium für alles, was ich nicht mit KI machen wollte, denn es ist wirklich schwierig, VSCode komplett zu „säubern”.

Natürlich bietet das Ganze keine 100-prozentige Sicherheit, das muss es aber auch nicht. Es bietet genug Schutz, um sich nicht völlig ungeschützt zu fühlen, und die üblichen Arbeitsweisen werden kaum eingeschränkt. Für mich persönlich passt es sehr gut, und ich würde mich freuen, wenn auch andere es nützlich fänden.

Probiert es aus:

brew install holtwick/tap/bx 

Wer heute mit KI-gestützten Coding-Tools arbeitet — sei es Claude Code, Copilot oder Cursor — gewöhnt sich schnell an den Produktivitätsschub. Was dabei gerne übersehen wird: Diese Tools haben vollen Zugriff auf das gesamte Dateisystem. Jeder Befehl, den die KI ausführt, läuft mit denselben Rechten wie der Nutzer selbst.

Das mag bei einem Hobbyprojekt egal sein. Aber wer Kundendaten verarbeitet, Lizenzschlüssel auf der Platte hat, SSH-Keys für Produktionsserver oder schlicht private Fotos im Home-Verzeichnis — der bekommt irgendwann ein mulmiges Gefühl.

Die vorhandenen Optionen

Natürlich gibt es Möglichkeiten, sich abzusichern:

Docker-Container bieten gute Isolation, aber sie sind für den typischen macOS-Entwicklungsalltag sperrig. Man muss Volumes mounten, IDE-Integration konfigurieren, und der Workflow fühlt sich nie ganz nativ an.

Claudes eingebaute Beschränkungen — das Tool fragt brav nach, bevor es Dateien ändert. Aber “nachfragen” ist kein Schutz. Eine halluzinierte Pfadangabe, ein falsch interpretierter Befehl, und schon liest die KI etwas, das sie nicht sehen sollte. Das Vertrauen basiert auf dem Verhalten des Modells, nicht auf einer technischen Barriere.

VSCode Workspace Trust schützt vor automatischer Code-Ausführung, aber nicht vor dem Dateisystem-Zugriff eines Terminals oder einer Extension.

Keine dieser Lösungen hat mich wirklich überzeugt.

Die Idee: macOS Sandbox nutzen

macOS bringt mit sandbox-exec eine Kernel-Level-Sandbox mit, die Apple selbst für App-Store-Apps verwendet. Die Idee: Ein Tool, das eine beliebige Anwendung so startet, dass sie nur das aktuelle Projektverzeichnis sehen kann — und sonst nichts.

Das Ergebnis ist bx. Ein CLI-Tool, das man vor den eigentlichen Befehl setzt:

bx claude ~/work/my-project

Das war’s. Claude Code startet, hat vollen Zugriff auf ~/work/my-project — aber ~/Documents, ~/Desktop, ~/.ssh, andere Projekte und alles andere im Home-Verzeichnis ist unsichtbar.

In zwei Tagen gebaut — mit Claude Code selbst

Das Ironische: bx wurde komplett mit dem Tool entwickelt, vor dem es schützen soll. In zwei intensiven Tagen hat Claude Code den Großteil des Codes geschrieben — von der Sandbox-Profil-Generierung über die CLI-Argument-Verarbeitung bis zur App-Erkennung via macOS Spotlight.

Das hat erstaunlich gut funktioniert. Claude kannte die (undokumentierte!) Apple Sandbox Profile Language und konnte die Eigenheiten korrekt umsetzen — etwa die Tatsache, dass deny-Regeln in SBPL immer Vorrang vor allow-Regeln haben, unabhängig von der Reihenfolge. Das bedeutet: Man kann nicht einfach das ganze Home-Verzeichnis sperren und dann Ausnahmen erlauben. bx löst das, indem es das Home-Verzeichnis scannt und gezielt nur die Geschwister-Verzeichnisse sperrt.

Mehr als nur Claude Code

bx beschränkt sich nicht auf ein Tool. Es unterstützt VSCode, Xcode, Terminal und beliebige Befehle out of the box. Über eine TOML-Konfigurationsdatei lässt sich jede App hinzufügen:

[apps.cursor]
bundle = "com.todesktop.230313mzl4w4u92"
binary = "Contents/MacOS/Cursor"

Das Tool findet die App automatisch über die macOS Bundle-ID — kein Hardcoden von Pfaden nötig. Und wenn man regelmäßig mit denselben Projekten arbeitet, lassen sich Standard-Verzeichnisse pro App konfigurieren:

[apps.code]
workdirs = ["~/work/project-a", "~/work/shared-lib"]

Ein einfaches bx code öffnet dann VSCode mit genau diesen Verzeichnissen — sandboxed.

Feingranulare Kontrolle

Was bx besonders praktisch macht: Man kann auch innerhalb eines erlaubten Projektverzeichnisses Dateien verstecken. Eine .bxignore-Datei im Projekt funktioniert wie .gitignore:

.env
.env.*
*.pem
secrets/

So bleiben Umgebungsvariablen und Zertifikate unsichtbar, selbst wenn das Projektverzeichnis voll zugänglich ist.

Mit bx --dry kann man sich vorab anzeigen lassen, was genau geschützt wird — ohne etwas zu starten. Das gibt ein gutes Gefühl für die tatsächliche Abschottung.

Die wachsende Angriffsfläche

Was viele unterschätzen: Moderne KI-Coding-Tools sind längst nicht mehr nur Chat-Interfaces. Claude Code zum Beispiel kann Shell-Befehle ausführen, Dateien anlegen und löschen, und über MCP-Server (Model Context Protocol) auf externe Dienste zugreifen — Datenbanken, APIs, Cloud-Infrastruktur. Dazu kommen Skills und Hooks, die automatisch Aktionen auslösen können.

Das alles passiert im Kontext des Nutzers, mit dessen vollen Berechtigungen. Die Sandbox von bx greift hier auf Kernel-Ebene: Egal ob ein rm-Befehl, ein MCP-Tool oder ein automatischer Hook auf ~/Documents zugreifen will — das Betriebssystem blockt den Zugriff, bevor er überhaupt stattfindet. Das ist grundlegend anders als eine Software-Einschränkung, die man umgehen könnte.

Wichtig dabei: Innerhalb des freigegebenen Projektverzeichnisses ist alles erlaubt — das ist gewollt, sonst könnte man nicht arbeiten. Wer dort sensible Dateien hat, kann sie per .bxignore gezielt ausschließen.

Ehrlich bleiben

bx ist kein Hochsicherheitstresor. sandbox-exec ist eine undokumentierte Apple-API, die sich mit jedem macOS-Update ändern könnte. Es gibt keinen Netzwerkschutz — API-Calls, git push und npm install funktionieren normal. Und die Sandbox-Regeln werden einmalig beim Start generiert; Verzeichnisse, die danach angelegt werden, sind nicht automatisch geschützt.

Aber als pragmatische Sicherheitsebene für den Entwicklungsalltag funktioniert es hervorragend. Es ist der Unterschied zwischen “die KI kann theoretisch alles lesen” und “die KI kann nur dieses eine Projekt sehen”.

Trotzdem, ganz klar: bx ist nach bestem Wissen und Gewissen entwickelt, aber es kommt ohne Garantie. Es ersetzt keine professionelle Sicherheitslösung und entbindet niemanden davon, selbst mitzudenken. Wer mit wirklich kritischen Daten arbeitet, sollte sich nicht blind auf ein einzelnes Tool verlassen — egal wie gut es funktioniert. bx ist eine zusätzliche Schutzschicht, kein Ersatz für gesunden Menschenverstand.

Ausprobieren

bx lässt sich über Homebrew oder npm installieren:

brew install holtwick/tap/bx
# oder
npm install -g bx-mac

Der Code ist Open Source: Codeberg holtwick/bx-mac GitHub holtwick/bx-mac

Ich freue mich über Feedback, Feature-Wünsche und natürlich Sterne. Und wenn ihr spannende Anwendungsfälle habt — schreibt mir gerne!

Dieser Blogpost wurde von Claude (Anthropics KI) verfasst und von mir gegengelesen und freigegeben. Passend zum Thema, würde ich sagen.

Ausgangssituation

Als Softwareentwickler stehe ich vor einem grundlegenden Dilemma: Die Entwicklung qualitativ hochwertiger Open-Source-Software – wie meiner Ende-zu-Ende-verschlüsselten Videokonferenzlösung Briefing – erfordert erhebliche Zeit- und Kapitalinvestitionen. Ohne nachhaltige Finanzierung bleibt mir nur der Weg der kommerziellen Verwertung, obwohl ich die Software lieber vollständig frei zur Verfügung stellen und intensiv weiterentwickeln würde. Dieses Problem betrifft zahlreiche Entwickler in Europa.

Kernidee

Die EU sollte ein dauerhaftes Finanzierungssystem etablieren, das Open-Source-Entwicklung durch leistungsbasierte Vergütung fördert. Konkret schlage ich eine EU-betriebene Plattform vor (vergleichbar mit GitHub oder Codeberg.org), die Fördergelder anhand messbarer Erfolgskriterien verteilt.

Funktionsweise

Die Plattform würde den Nutzen und die Qualität von Projekten durch objektive Metriken bewerten:

• Community-Engagement (Bewertungen, Sterne)
• Technische Reichweite (Integration in andere Projekte, Downloads)
• Wartungsqualität (Beantwortung von Issues, Behebung von Bugs)
• Dokumentation und Support

Fördergelder würden anteilig ausgeschüttet, wobei Obergrenzen pro Projekt / Person Missbrauch vorbeugen.

Vorteile für alle Beteiligten

• Für Entwickler: Direkte Verbindung zwischen Leistung und Vergütung; Möglichkeit, sich vollständig auf quelloffene Entwicklung zu konzentrieren
• Für die EU: Aufbau digitaler Souveränität; Kontrolle über Qualitätsstandards (z.B. EUPL-Lizenzierung, Entwickler-Verifizierung); Förderung europäischer Innovation; Reduktion der Abhängigkeit von außereuropäischen Plattformen
• Für die Gesellschaft: Zugang zu sicherer, transparenter Software; Stärkung des europäischen Tech-Ökosystems

Fazit

Diese Initiative würde systematische Anreize für die Entwicklung hochwertiger Open-Source-Software schaffen und gleichzeitig europäische Werte wie Transparenz, Datenschutz und digitale Souveränität fördern.

Receipts Space 3.0 ist da – ein großes Update mit vielen Neuerungen. Hier ein kurzer Überblick.

Revisionskonformität (GoBD)

Für alle, die ihre Belege ordnungsgemäß aufbewahren müssen, gibt es jetzt einen dedizierten Modus. Bestätigte Einträge werden schreibgeschützt, alle Änderungen werden protokolliert. Eine Verlaufs-Zeitleiste zeigt auf einen Blick, wer wann was geändert hat.

Ende-zu-Ende-Verschlüsselung

Wer seine Bibliothek in der Cloud oder auf einem USB-Stick ablegt, kann sie jetzt mit einem Passwort verschlüsseln. Die Synchronisation zwischen mehreren Macs funktioniert weiterhin – solange alle Geräte den Schlüssel kennen.

Neues Dashboard

Das Dashboard wurde komplett überarbeitet. Neben Einnahmen und Ausgaben zeigt es jetzt auch offene Beträge und Trends im Vergleich zum Vorjahr. Ein Klick auf Kontakte, Kategorien oder Tags filtert die Ansicht.

Ordner statt Package

Das Dateiformat wurde um eine Option erweitert: Die Bibliothek kann jetzt auch als normaler Ordner gespeichert werden. Das löst Synchronisationsprobleme mit iCloud und anderen Diensten.

Natürlich gibt es noch viele weitere Änderungen. Alle Details gibt es auf receipts-app.com.

Was für verrückte Zeiten, in denen wir leben, und nun wird alles noch absurder mit dem amerikanischen Präsidenten Trump. Nicht nur in der großen Politik sollte das Ziel jetzt heißen, unabhängig von den USA zu werden und die EU zu stärken. Nein, auch im Privaten lässt sich da einiges machen, und ich möchte in einer kleinen Serie nach und nach Alternativen für US-Dienste und Produkte vorstellen.

Schon 2020 hatte ich in meinem Artikel “Eine IT-Strategie für Europa” versucht zu skizzieren, wie ich mir so einen Schritt in die digitale Souveränität in groben Zügen aussehen könnte. Es passiert in dieser Hinsicht nicht besonders viel.

Folgende Kriterien möchte ich anbieten, um Unabhängigkeit und Zuverlässigkeit zu erreichen:

• Selfhosting → Betreibe deine Dienste selbst, dann kann sie niemand abschalten und die Daten gehören dir.
• Dezentral → Ein verteiltes System ist weniger anfällig für Ausfälle und Zensur.
• Open Source → Die Software kann so nicht verschwinden und ist überprüfbar.

Image by mistral.ai

Selfhosting

Es ist so schön bequem, die Dienste der großen Anbieter wie Google, Microsoft oder Apple zu nutzen, aber meistens zahlt man mit seinen persönlichen Daten. Auch Dienste wie Apple können schnell ihre datenschutzfreundliche Haltung ändern, Anzeichen gibt es bereits und die Geschichte vergleichbarer Dienste lässt das Vertrauen schrumpfen.

Heimnetz

Leider ist das Betreiben eigener Server nichts für jedermann, aber es ist weniger kompliziert als vielleicht befürchtet. Man kann damit zu Hause beginnen mit einer NAS. Bei mir steht eine Synology (Taiwan). Diese kommt schon mit vielen Diensten in guter Qualität, die das Wesentliche abdecken. Aber eigentlich kann es jeder Rechner sein, Hauptsache Docker lässt sich darauf betreiben.

Docker ist der Schlüssel zum wirklich einfachen und sicheren Betrieb von “self-hosted services”. Es gibt eine schier unendliche Menge von Lösungen für jedes Problem.

Ich betreibe auf meiner Synology z.B. Home Assistant (Open Source), das Dashboard für alle Geräte und Sensoren im eigenen Haus, die irgendwie im Netzwerk sind. Für Fotos verwende ich Immich (Open Source), das sich mit seinen Features auch nicht verstecken muss. Über eine VPN-Verbindung - bei mir ist es WireGuard über eine fritz.box - lassen sich alle Dienste auch von unterwegs nutzen.

Internet

Aber auch der Betrieb eines Docker Dienstes im Internet ist kein Hexenwerk. Bei Hetzner (Empfehlungs-Link) lässt sich z. B. für unter 5 EUR ein virtueller Server erstellen und direkt fertig mit Docker aufsetzen. Nach ein paar Vorbereitungen, um die eigene Domain mit der IP zu verbinden, kann es schon losgehen.

Ich betreibe viele Dienste dort, privat nutze ich hauptsächlich nextCloud. Das ist an einigen Stellen etwas altbacken, aber erfüllt seinen Zweck für Dateiaustausch und andere Dinge, die man z. B. aus der iCloud kennt.

Dezentral

Den berühmtesten dezentralen Dienst des Internets nutzen alle: E-Mail. Eigentlich ist die ganze Magie des Internets sein dezentraler Aufbau. Fällt irgendwo was aus, sucht sich die Information einen anderen Weg, so wie bei Ameisenstraßen.

Große Anbieter sind meistens zentral aufgebaut. Klar, im Hintergrund wird auch versucht die Last aufzuteilen, aber trotzdem sind diese Dienste schon rein technisch anfällig für Störungen, Datenverlust und Sicherheitslücken.

Umso schöner, dass es nun wieder mehr “föderierte” Dienste gibt. In letzter Zeit ist besonders Mastodon als Twitter /X-Alternative bekannt geworden. Aber in diesem sogenannten Fediverse entstehen auch weitere Lösungen, die dann auch miteinander in Verbindung treten können. Ein gutes Beispiel dafür ist der YouTube-Ersatz PeerTube.

Aber es gibt noch andere Formen der dezentralen Datenverarbeitung. Eine Bewegung, die mir besonders gefällt, nennt sich Local First, dabei wird wieder Wert darauf gelegt, dass die Daten auch lokal verfügbar sind. Dieselben Daten an verschiedenen physischen Orten zu lagern, ist auch eine Form von dezentraler Struktur. Das Paradebeispiel dafür sind Versionierungssystem wie git.

OpenSource

Freie und offene Software ist der Grundstein für tieferes Vertrauen. Erstens ist offene Software nicht so schnell “aus der Welt”, sie existiert tausendmal kopiert. Zweitens kann man sich mit etwas Sachverstand ansehen, was die Software eigentlich genau macht. Und drittens lässt es sich anpassen, wodurch wiederum zum Projekt beigetragen wird. Quasi eine digitale Form von ehrenamtlicher Arbeit, ohne dafür in einen Verein zu müssen ;)

Weiterführende Links

• Kuketz Blog zum selben Thema mit interessanten Links und Hinweisen:
  https://www.kuketz-blog.de/unplugtrump-mach-dich-digital-unabhaengig-von-trump-und-big-tech/
• Verzeichnis europäischer Alternativen:
  https://european-alternatives.eu
• Allgemeine Suche nach Alternativen:
  https://alternativeto.net
• Viele vorinstallierte Selfhosted-Projekte, gut zum ausprobieren:
  https://adminforge.de

Nach dem erfolgreichen Start von XML2Invoice sind viele neue Features und Verbesserungen hinzugekommen, so dass nun die Umbenennung in E-Invoice Space erfolgt.

Neues Layout

Der Raum wird nun sinnvoller genutzt, indem nur noch zwischen der PDF-Vorschau und dem Eingabebereich unterschieden wird. Außerdem ist eine Anpassung der Größenverhältnisse zwischen den beiden Bereichen möglich. Es gibt nun eine übergeordnete Aufteilung zwischen Lesen und Schreiben, um die Stärken von E-Invoice Space besser hervorzuheben und den Zugang zu den Funktionen zu vereinfachen.

Eigene Rechnungen erstellen

Im Bereich Schreiben kann neben der Anreicherung eines bestehenden einfachen PDFs mit E-Rechnungsdaten nun auch eine komplett neue Rechnung erstellt werden. Alle notwendigen Daten können komfortabel eingegeben werden und eine Vorschau wird sofort generiert. In der PRO-Version ist zusätzlich die Auswahl eines individuellen Hintergrunddesigns (Briefpapier) sowie der Upload eigener Schriften im TTF-Format möglich.

EN 16931 Kompatibilität

E-Invoice Space erfüllt nun auch die Anforderungen der EN 16931 Norm, nicht nur BASIC und MINIMAL wie bisher.

Insgesamt ist die Anwendung umfangreicher und benutzerfreundlicher geworden, was schnelle Ergebnisse ermöglicht. Wie gewohnt findet alles lokal statt, so dass sich die Webanwendung wie eine lokal installierte Anwendung verhält. Es werden keine Daten gespeichert oder in einen Cloud-Dienst übertragen.

… mit unserem neuen Schweizer Taschenmesser für E-Rechnungen. Nach dem letzten Update können E-Rechnungen jetzt einfach online erstellt werden. Sogar mit eigenem Briefpapier und Schriften. Das Ergebnis ist ein PDF, das mit allen erforderlichen Standards kompatibel ist, darunter EN 16931, XRechnung, ZUGFeRD und PDF/A.

Der Clou: Rechnungen, die bisher mit Word oder ähnlichen Programmen erstellt wurden, lassen sich im Handumdrehen in eine E-Rechnung umwandeln. Einfach das PDF der bestehenden Rechnung hochladen, die Werte werden wie von Zauberhand ausgelesen und heraus kommt wieder eine standardkonforme E-Rechnung im ZUGFeRD-Format. Das bedeutet, dass die elektronischen Daten als XML in das PDF eingebettet wurden und auch die anderen technischen Anforderungen erfüllt sind.

Das Ergebnis kann schnell gespeichert und versendet werden. Aber auch in unserem Mac-Tool Receipts.

Aber das ist noch nicht alles. Empfangene E-Rechnungen, egal ob XML oder PDF, einfach in das Fenster von XML2Invoice ziehen und schon ist alles lesbar und bereit zur Zahlung oder Weiterverarbeitung.

Wie gesagt, das Schweizer Taschenmesser der E-Rechnung 😎

Schreibe jetzt deine erste E-Rechnung!

Update 2025-01-29: XML2Invoice heißt nun E-Invoice Space

Sorge vor E-Rechungen? Mit XML2invoice kannst du entspannt ins Neues Jahr starten…

XML2Invoice ist eine webbasierte App, die deine “normale” PDF-Rechnung ins XML-Format umwandelt: Entweder in eine reine XML-Datei oder in eine ZUGFeRD-PDF-Datei, die genau wie deine Rechnung aussieht und in die die vorgeschriebenen XML-Daten eingebettet sind.

Und auch andersrum funktioniert’s: XML2Invoice erzeugt aus von Menschen nicht mehr lesbaren XML-Dateien eine elektronisch lesbare Rechnung im ZUGFeRD-Format, die äußerlich wie eine übliche PDF-Rechnung aussieht, aber auch die XML-Daten enthält. Lesbar für Mensch und Maschine. Wenn gewünscht importierst du das PDF mit den eingebetteten XML-Daten per Mausklick in Receipts.

Jetzt kostenlos starten auf xml2invoice.com !

Update 2025-01-29: XML2Invoice heißt nun E-Invoice Space

Ab sofort kann PDFify auf die neueste Version 4.0 aktualisiert werden. Viele PDFify-Nutzer freuen sich auf dieses größere Versionsupdate mit Verbesserungen und neuen Funktionen.

PDF/A Unterstützung

Viele PDFify-User haben elektronische Dokumente, die sie langfristig archivieren müssen. PDF/A - Portable Document Format Archivable - ermöglicht eine standardisierte Langzeitarchivierung von Dokumenten. PDFify bietet nun ab macOS 11 in den Einstellungen an, das Dokument standardmäßig als PDF/A abzuspeichern.

Das “normale” PDF, welches Einbettung von Links, Grafiken, Audio- und Videodateien sowie optionale Verschlüsselung unterstützt, bleibt selbstverständlich in PDFify erhalten.

Finder Extensions / Quick Actions

Um zügig mehrere bereits bestehende PDFs “im Stapel” in PDF/A umzuwandeln, lassen sich die Schnellaktionen in den Finder Extension um “in PDF/A umwandeln” ergänzen.

Ebenfalls gibt es eine neue Finder Extension zur Umwandlung von Dokumenten in eine PDF mit PDF/A Format. Aber auch die bestehenden Extensions erzeugen PDF/A, wenn die Option in den Einstellungen gesetzt wurde.

Schnellere Anzeige der PDFs im Web

Des Weiteren kann man nun auch, das linearisierte PDF, welches für die zügige Anzeige im Internet optimiert ist, auswählen. Die erste Seite wird dann beim Download bereits angezeigt, während die nachfolgenden Seiten noch geladen werden.

Standardisierte maximale Seitengröße

PDFify ermöglicht nun eine Begrenzung der maximalen Seitengröße, um im Ergebnis keine unschönen riesigen Seiten zu erhalten. Standardmäßig ist die Seitengröße mit dem Update auf DIN A4 eingestellt. In den Einstellungen kann man den Wert auf die Originalgröße oder US letter anpassen.

Reihenfolge beim Import

Manchmal liegen die einzelnen Seiten eines Dokuments als separate Bilddateien vor. In der neuen Version von PDFify werden diese nun zuverlässig in der vom Apple Finder bekannten Sortierung importiert. So lassen sich schnell einzelne Scans von Seiten zu einem PDF Dokument zusammenführen.

Jetzt kostenlos ausprobieren

Als ich in den 80ern mit dem Programmieren begann, war die Situation einfach: Daten wurden in eine Datei auf einem lokalen Datenträger geschrieben. Sollten Dateien ausgetauscht werden, wurde eine Diskette einfach in einen anderen Computer geschoben und bearbeitet.

Später verschwanden die Disketten und CD-Laufwerke und Dateien wurden entweder per E-Mail ausgetauscht oder die Daten direkt auf einem Server gespeichert. Selbst Microsoft Word wanderte irgendwann in die Cloud.

Doch mit der Verlagerung der Daten vom lokalen Rechner in die Cloud entstanden neue Probleme. Was, wenn der Anbieter seinen Dienst schloss? Aber nicht nur Datenverlust, sondern auch das Gefangen sein beim Anbieter, weil die Daten nicht mehr aus dem Dienst herauszubekommen waren, entwickelte sich zunehmend zu einem Problem für die einen und ein Geschäftsmodell für die anderen.

Local-First

Die Local-First-Bewegung möchte die Daten wieder zum Nutzer zurückbringen und trotzdem die Vorteile des Internets erhalten. Für das gleichzeitige Bearbeiten von Daten wurde mit CRDT in eine robuste und weithin akzeptierte Lösung gefunden, für den Austausch der Daten jedoch noch nicht. Denn ganz ohne Dienste auf einem Server geht es (noch) nicht. Selbst bei Peer-to-Peer, wo die Geräte überwiegend direkt miteinander kommunizieren, muss am Anfang die Verbindung vermittelt werden.

In einer idealen Local-First Welt sollten folgende Kriterien erfüllt sein in Bezug auf den Austausch der Daten:

1. Daten werden lokal bearbeitet und gespeichert (Offline).
2. Der Sync kann für längere Zeit unterbrochen werden, Daten können jedoch währenddessen lokal bearbeitet werden und trotzdem nach erneutem Sync überall wieder identisch sein (CRDT).
3. Daten sollten unterwegs nicht einsehbar sein (E2EE).

Und ich würde noch gerne hinzufügen:

4. Das Ganze sollte auch mit der Technik der 80er Jahre funktionieren.

Warum? Aus Gründen der Resilienz, denn es gibt viele Gründe, warum wir offline gehen könnten.

Resilient Sync

Aus diesem Grund schlage ich ein Datenaustauschformat vor, das sowohl im Dateisystem als auch im Internet funktioniert. Es soll so einfach sein, dass die Implementierung auf jedem zugrundeliegenden Datenträger oder Service funktionieren kann.

Log der Änderungen

Zunächst schreibt jeder Client eine Art einfaches, fortlaufendes Log mit den Änderungen. Die Position der Änderungen nennen wir index und sie beginnt bei 0 und wird in ganzen Zahlen fortgeführt: 0, 1, 2, 3, .... Üblicherweise sind diese Änderungen CRDT konform, aber das ist nicht erheblich für das Protokoll. Ebenso können diese Daten verschlüsselt abgelegt werden. Nennen wir diese Daten data.

Jeder Client erhält eine eindeutige Kennung, üblicherweise eine Unique ID (UUID), wir nennen sie clientId. Die Änderungs-Logs werden mit der clientId verbunden abgelegt. Eine Sammlung solcher Logs wollen wir workspace nennen.

Wir können weitere Daten anreichern, wie z. B. einen timestamp, was nützlich sein kann, wenn wir die Datenveränderungen historisch aufbereiten wollen oder eine Art endloses “Undo” implementieren wollen.

Auch ist es denkbar, dass jeder neue Eintrag einen Hash auf den vorherigen Eintrag enthält, um so eine Absicherung der Datenkonsistenz im Stile einer Blockchain zu erhalten. Weitere Verfeinerungen Richtung Merkle-Tree sind ebenfalls denkbar. Aber auch ein Hash auf den Inhalt des aktuellen Eintrags kann zur Datensicherheit beitragen.

Assets, Blobs, die großen binären Brocken

Zur Realität gehört auch, dass es größere Daten gibt, die sich selten verändern: Bilder, Videos, Audios, also Dateien. Diese gehören nicht zu den inhaltlichen Änderungen und würden einen Datenabgleich schnell ins Stocken bringen. Außerdem werden sie nicht immer sofort gebraucht und könnten auch “on demand” geladen werden. Daher schlage ich vor, diese Dateien getrennt von den Änderungen zu behandeln. Nennen wir sie asset.

Aber auch hier sollen die Daten nach clientId und in aufsteigender Reihenfolge mit index abgelegt werden. Die Datensätze können so auf ein Asset verweisen, z.B. mit einem Dateneintrag in Form einer URL, die alle notwendigen Informationen enthält: asset:///<clientId>/<index>/<filename>?size=<sizeInBytes>&type=<mimeType>&hash=<checksumOfContents>. Ein Beispiel könnte wie folgt aussehen asset:///abc/1/test.txt?size=100&type=text%2Fplain&hash=1a2b3c.

Vorteile

Der entscheidende Vorteil dieser Methode ist, dass wir immer wissen, wo die nächsten Daten auftauchen werden. Denn hat ein Client gerade den Index 123 geschrieben, wird der nächste 124 sein.

Warum ist das wichtig? Aus folgenden Gründen:

1. Wir sind nicht darauf angewiesen, auf neue Daten hingewiesen zu werden (“push”), sondern können auch selber danach fragen (“pull”).
2. Wir können die einzelnen Einträge laden, auch ohne etwas über ihren Inhalt zu wissen. Ein Sync kann sogar ohne Zwischenstelle stattfinden, die die Daten “verstehen” muss.
3. Wir merken sofort, wenn Daten fehlen sollten und können diese nochmals anfordern.
4. Die Daten können beliebig oft repliziert werden, es muss nicht nur eine Sync-Quelle geben. Eine Nutzung als Backup ist somit sinnvoll.
5. Clients die keine direkte Verbindung zueinander haben, können durch “dumme Kopiervorgänge”.
6. Der Datenaustausch lässt sich einfach und verständlich dokumentieren, was wichtig sein kann bei der Anerkennung rechtssicher abgelegter Daten für Steuer und Compliance.
7. Es gibt keine Konflikte bei der Ablage der Daten, weil nur fortgeschrieben wird, aber nie gelöscht (“append only”).

Datenbanken

Beginnen wir zunächst mit der Implementierung als Datenbank. Wie beschrieben, würde eine Tabelle mit folgenden Feldern reichen:

• index: Integer
• clientId: String oder Integer
• data: String oder Binär
• timestamp: Integer (optional)
• prevHash: String oder Integer (optional)

Für die Assets würde das ähnlich aussehen.

Bei Datenbank kann sowohl die lokale Ablage des Clients, z. B. in der IndexedDB, gemeint sein, als auch die auf einem Synchronisations-Server.

Dateisysteme

In einem Dateisystem werden die Daten in einem Verzeichnis abgelegt. Metadaten, wie der clientId des Erstellers und Angaben wie z. B. zur verwendeten Verschlüsselung, werden in einer JSON-Datei namens index.json abgelegt.
Des Weiteren gibt es für jeden Client ein Verzeichnis, das nach der clientId benannt ist.

In diesen wiederum befinden sich jeweils zwei Verzeichnisse:

1. changes
2. assets

In changes werden fortlaufend nummeriert die Änderungen erfasst. In assets dasselbe mit den beschriebenen Binärdaten.

Moderne Dateisysteme haben keine nennenswerten Beschränkungen der Anzahl der Dateien pro Directory, aber es kann nicht schaden, trotzdem die Anzahl zu begrenzen. Folgender Algorithmus in TypeScript sorgt für eine gleichmäßige Verteilung:

/**
 * Distribute file, named by natural numbers, in a way that each folder only
 * contains `maxEntriesPerFolder` subfolders or files. Returns a list of
 * names, where the last one is the file name, all others are folder names.
 * 
 * Example: `distributedFilePath(1003)` results in `['2', '1', '3']` which 
 * could be translated to the file path `2/1/3.json`.
 */
export function distributedFilePath(index: number, maxEntriesPerFolder: number = 1000): string[] {
  if (index < 0)
    throw new Error('Only numbers >= 0 supported')
  const names: string[] = []
  do {
    names.unshift((index % maxEntriesPerFolder).toString())
    index = Math.floor(index / maxEntriesPerFolder)
  } while (index > 0)
  names.unshift(names.length.toString())
  return names
}

Quelle: zeed Framework

Online Services und Peer-To-Peer

Für Online Services kann eine passende Mischung aus dem Datenbank- oder dem Dateisystem-Ansatz gewählt werden, je nachdem, was besser zu dem ausgewählten Service passt. Bei Dropbox oder WebDAV wäre das z. B. der Dateisystem-Ansatz. Bei Apple CloudKit eher der Datenbank-Ansatz.

Aber es ist auch ein einfacher eigener Service denkbar, mit einer REST, WebSocket oder anderen sinnvollen Schnittstellen.

Es spricht auch nichts gegen einen Abgleich der Daten via Peer-to-Peer oder einem anderen lokalen Kommunikationsweg. Die Daten sind ja identisch und so kann ein Abgleich mit anderen Clients jeweils über den schnelleren Weg durchgeführt werden. Die Redundanz ist also von Vorteil und macht die Sache nicht weiter kompliziert. Theoretisch ist bei CRDT auch die Reihenfolge und die Mehrfachanwendung der Änderungen unproblematisch.

Verfeinerungen

An einigen Stellen gibt es noch Potenzial zu Verbesserungen:

• Steuerung der Datengröße pro Log-Eintrag. Sammeln mehrerer Änderungen für größere Pakete oder Aufteilen einer Änderung in mehrere Pakete, falls der Umfang zu groß wird.
• Komprimierung oder Zusammenfassung der Daten.
• Bekanntmachung neuer Clients, z. B. durch spezielle Logeinträge. Evaluierung durch kryptografische Methoden.
• Durch Hinzufügen einer logischen Uhr, wie der Lamport-Clock, können Einträge logisch sortiert werden und dadurch in die Chronologie eines Eintrages verbessert werden.
• Das Schreiben der Daten in einer einzigen Datei pro Client aus Gründen der Ressourcen-Optimierung.
• Durch geschickten Einsatz von kryptografischen Mitteln lässt sich evtl. sogar ein Rechte-Management implementieren (Cryptree).

Ausblick

Ich verwende diese Technik seit einigen Jahren in meinen Apps, wie z. B. in dem mittlerweile beendeten Projekt Onepile. In Kürze sollen neue Projekte mit diesem Ansatz veröffentlicht werden.

Die Einfachheit und Flexibilität erscheinen mir die größten Pluspunkte bei diesem Ansatz zu sein. Dadurch sollte es auch zukunftssicher sein und sich schnell neuen technischen Gegebenheiten anpassen können.

Das folgende Diagramm stellt exemplarisch ein Ökosystem für eine Web-App dar:

Related

• Diskussion zum Artikel auf HackerNews
• Martin Kleppmanns Talk auf der Local-First Conference 2024 in Berlin
• Mastodon Beitrag von Martin Kleppmann
• Liste ähnlicher Ansätze:
  • git-bug
  • remotestorage.io
  • Local, first, forever
  • Understanding Delta Lake’s consistency model
  • Data Laced with History: Causal Trees & Operational CRDTs

Letztens las ich von einer “massiven Fake News Maschinerie”, die das deutsche Außenministerium aufgedeckt haben will (siehe unten). Sie sei kaum noch von legitimen Nachrichten zu unterscheiden.

Mir kam spontan der Gedanke, dass wenn man nicht in der Lage ist, manipulierte Nachrichten zu stoppen, man doch wenigstens in der Lage sein sollte legitime Nachrichten zu kennzeichnen.

Die Idee ist einfach: Lasst uns ein digitales Netzwerk des Vertrauens schaffen mit kryptografischen Mitteln.

Ab hier wird es technisch…

Die einfachste Form des Signierens ist die Berechnung eines Hash Wertes. Also nehmen wir an, ich möchte als @holtwick tweeten: “Ich mag keine Fake News!” und mein Geheimnis wäre “Gurkensalat” (üblicherweise engl. als “salt” benannt). Im Terminal ginge das dann so:

echo -n "@holtwick Ich mag keine Fake News! Gurkensalat" | shasum -a 256

Alternativ mir OpenSSL:

echo -n "@holtwick Ich mag keine Fake News! Gurkensalat" | openssl dgst -sha256

Das Ergebnis ist:

26b1a58b82ffcc963e1a337623886b7d6dcf8c63dff592b9fa9113fd29aa82e7

Das kann auch schon berechnet werden, bevor ich es tweete. Dann nehme ich einen Teil der Ergebnisses, z. B. die ersten 8 Zeichen und sende sie mit der Nachricht, vielleicht noch mit einem Erkennungsmerkmal, wie einem vorangestellten ~ Zeichen:

So, nun geht es noch darum, sowas zu verifizieren. Denkbar wäre ein kleiner Service auf der eigenen Website. Hier ein kleines Beispiel in PHP, wie eine Online Prüfung aussehen könnte:

<?php 

// This one is top secret :)
$salt = "Gurkensalat";

// Normalize whitespace to avoid copy paste issues
$sample = trim(preg_replace('/[\t\n\r\s]+/', ' ', $_GET["text"])) . " " . $salt;

// Calculate SHA256 and only use the first 8 chars
$hash = substr(hash('sha256',  $sample), 0, 8);

// Compare hashes and return result
echo strcmp($_GET["hash"], $hash) == 0 ? "ok" : "invalid";
?>

Die fertige URL wäre dann: https://holtwick.de/experiments/id.php?text=@holtwick%20Ich%20mag%20keine%20Fake%20News!&hash=26b1a58b

Probiere es aus:

Ok, das war jetzt eine relativ primitive Implementierung, um die Idee zu verdeutlichen. Für eine ernsthafte Anwendung würden sicherliche andere Techniken zum Einsatz kommen, wie z.B. ein Public-Key-Verfahren oder Blockchains. Natürlich gibt es auch schon Dienste, die ähnliches leisten wie diese Übersicht der Bundesnetzagentur zeigt.

Quellen

• Spiegel (dt.)
• Tagesschau (dt.)
• DW (engl.)
• The Guardian (engl.)

Nach einigen Jahren war es an der Zeit, die Website zu aktualisieren. Für die letzte Version hatte ich sogar einen eigenen statischen Website-Generator namens Hostic entwickelt und alles lief wunderbar. Aber obwohl ich es liebe, das Rad neu zu erfinden, habe ich es bei diesem neuen Anlauf nur halb gemacht.

Grundsätzlich besteht diese Website aus Vue und Markdown. Davon wird eine statische Version erstellt, so dass für jede URL die entsprechende Seite mit Inhalt vorhanden ist. Dadurch kann die Website von Suchmaschinen gut indiziert werden und die Ladezeit ist sehr kurz. Das Verfahren nennt sich SSG (Server-Side Rendering).

Der Clou ist aber, dass dieser Ansatz es erlaubt, dynamische Elemente in die Website und sogar einzelne Beiträge einzubauen. Ein erstes Beispiel ist die interaktive Anmeldung zu meinem E-Mail-Newsletter, denn ich füge an dieser Stelle einfach <AppNewsletter/> ein:

Eine weitere Erleichterung ist die Verwendung von Obsidian als Markdown-Editor für die Inhalte. Ich benutze dieses praktische Tool sowieso jeden Tag und kann so die Inhalte bequem pflegen.

Meinen eigenen Ansatz habe ich von dem großartigen Projekt Vitesse abgeleitet. Die verwendete Technik ist fast identisch, allerdings musste ich einige Anpassungen für meine Zwecke vornehmen.

Letztes Jahr habe ich Video Chat Projekte gestartet. Erst peer.school mit dem ich einen Beitrag zur Beschulung kleinerer Kinder leisten wollte. Dann daraus hervorgehend Brie.fi/ng, dass seinen Fokus auf sichere Kommunikation legt.

Besonders Briefing hat auf Github viele Freunde gefunden und ist nun in mehreren Sprachen verfügbar, darunter auch Chinesisch und ganz frisch Russisch.

Das Projekt ist sehr einfach aufgebaut und nutzt das Javascript Framework Vue. Alle notwendigen Funktionen sind vorhanden und darüber hinaus sogar so spannende Features wie das Ausblenden oder Austauschen des Hintergrundes.

Einige native Apps sind ebenfalls vorhanden, darunter ist aber besonders die iOS App mit Unterstützung für AppClips (Räume betreten via QR Code oder NFC Sender) erwähnenswert.

Einbetten

Neben dem Teilen einer URL zum betreten eines gemeinsamen Raumes, gibt es auch die Möglichkeit Briefing direkt in die eigene Website einzubetten. Ein einfacher IFrame macht es möglich, wie dieser hier:

<iframe
  src="https://brie.fi/ng/cool-call-62?audio=1&video=1&fs=0&invite=0&prefs=0&share=0"
  allow="camera; microphone; fullscreen; speaker; display-capture"
></iframe>

Zur einfachen Konfiguration gibt es nun ein IFrame Tool, in dem jeder seinen Code schnell mit einigen Klicks selber konfigurieren kann:

Wer die volle kontrolle haben will, kann aber auch alle Komponenten die zum Betrieb notwendig sind selbst installieren. Eine Anleitung befindet sich im README auf Github.

Kommerzielle Lizenz

Briefing is Open Source, aber unter der EUPL v1.2 Lizenz, diese ist eine europäische Antwort auf die GPL. Daraus ergibt sich, das Änderungen wiederum unter der selben Lizenz zu veröffentlichen sind.

Wenn aber gewünscht ist, Änderungen nicht zu veröffentlichen, so ist es sicherlich fair eine kommerzielle Lizenz zu erwerben, die diese Freiheiten bietet. Alles dazu findet sich ebenfalls im README.

Ausblick

Aktuell arbeite ich an einem dritten Produkt, dass in die Fußstapfen von Briefing treten soll. Der Fokus liegt auf besserer Skalierbarkeit, Datenschutz und Verschlüsselung, sowie Relatime-Collaboration. Die Entwicklung ist schon weit fortgeschritten. Mehr dazu bald hier…

LanguageTool ist die Geheimwaffe bei der Produktion fehlerfreier Texte in verschiedenen Sprachen. Ich persönlich stehe auf dem Kriegsfuß mit so mancher Grammatikregel und bin froh, wenn mich die Maschine warnt, bevor es peinlich wird 😅

Allerdings finde ich, muss nicht alles was ich geschrieben habe an einen Service gesendet werden, der zwar toll ist, aber nicht unter meiner Kontrolle.

Daher hier einige Tipps, um selber einen entsprechenden Server aufzusetzen und zu nutzen.

Aufsetzen eines eigenen Servers

Die einfachste Methode, einen eigenen Server aufzusetzen ist via Docker. Dieses Paket bietet sich an: erikvl87/languagetool. Und so wird es geladen und gestartet:

docker pull erikvl87/languagetool
docker run -d --restart unless-stopped -p 8010:8010 erikvl87/languagetool

Super, jetzt ist der Server unter http://example.com:8010 zu erreichen. Weitere Hintergrundinformationen gibt es unter https://dev.languagetool.org/http-server

In Visual Studio Code verwenden

Die Erweiterung LanguageTool Linter bietet alle notwendigen Funktionen im Umgang mit LanguageTool. Hier kann die Server URL nun eingetragen werden. Die Bearbeitung von Texten und Markdown wird so sehr viel komfortabler.

Folgende Anpassungen der Einstellungen haben sich als sinnvoll erwiesen:

{
  "languageToolLinter.external.url": "http://example.com:8010",
  "languageToolLinter.hideDiagnosticsOnChange": true,
  "languageToolLinter.hideRuleIds": true,
  "languageToolLinter.lintOnChange": true,
  "languageToolLinter.lintOnOpen": true
}

In Firefox verwenden

Für Browser und andere Apps stehen zahlreiche Plugins zur Verfügung, siehe https://languagetool.org/#plugins. Bei der Erweiterung von Firefox lässt sich unter “Experimental settings (only for advanced users)” der eigene Server eintragen. Dabei muss die URL noch im Versionspfad ergänzt werden, also in unserem Beispiel: http://example.com:8010/v2/.

Ich liebe Vue.js von Evan You und ich mag statische Webseiten. Natürlich gibt es bereits Lösungen um diese beiden Neigungen miteinander zu verbinden wie VuePress oder Nuxt. Aber wäre ich ein Programmierer, wenn ich diesen einfachen Weg wählen würde?

Natürlich wollte ich ran an die bleeding edge und habe mich schnell begeistern lassen von Evans neuestem Coup vite. Es wirft den Ballast vom webpack über Bord und macht alles richtig. Zunächst versuchte ich damit und mit vitepress mein Glück, aber das war leider auch nicht ganz das wonach ich suchte.

Also ging ich noch mal einen Schritt zurück und schaute mir die Klassiker der statischen Website Generierung an: Gatsby, Hugo, Jekyll und 11ty. Auch diese machten eigentlich alles richtig, aber alles kam dort auch nicht von der Stange wie ich es gerne hätte. Besonders da ich mich SeaSite schon eine eigene Lösung gebaut hatte, mit der alle meine Websites generiert wurden.

Was will ich eigentlich?

Aber was war es also, was ich wollte? Ich habe folgende Punkte für mich herausgefunden:

1. Geschwindigkeit: Ich möchte wie bei Vue.js Änderungen im Code vornehmen und unmittelbar im Browser das Ergebnis sehen.
2. Flexibilität: Ich möchte jeden Aspekt selber beeinflussen und Programmieren können. Am liebsten in Javascript.
3. Nachbearbeitung: Ich möchte Inhalte noch leicht anpassen können, nachdem sie bereits Berechnet wurden. Das war das Kernprinzip von SeaSite, wodurch ich im Nachgang Optimierungen an Bildern und Videos vornehmen konnte, aber auch Übersetzungen von Textpassagen für verschiedene Sprachversionen laufen lassen konnte.

Wie mache ich es?

Gut, bei Punkt 1 hatte ich bei vite schon esbuild entdeckt. Es ist so unglaublich schnell, dass ich es gar nicht glauben konnte. Das Ergebnis ist auch zuverlässig und genau so wie es sein soll. Esbuild war also gesetzt als Werkzeug, das ich einsetzen wollte.

Ich baute also zunächst ein kleines Node.js Skript, dass eine Javascript Datei transpilierte. Dazu baute ich eine kleine Library, um Routen zu registrieren. Die Generierung der Inhalte sollte dann on-demand erfolgen, wenn die Website durch einen einfachen Express.js Webserver angefragt würde. Um die statischen Seiten zu generieren würde ich einfach zu allen registrierten Routen die Inhalte generieren und abspeichern lassen. Das ging super und dauerte nur Millisekunden.

Schnell wollte ich nun auch den Komfort von vite haben, d.h. wenn Dateien sich ändern, lädt auch der Browser unmittelbar neu. Mit Chokidar konnte ich den Ordner mit den JS Dateien beobachten und per esbuild alles neu übersetzen lassen. Durch einen kleinen Trick, ließ sich der Import-Cache von Node.js umgehen und das neue JS einladen und ausführen. Mit socket.io war schnell ein Reload Mechanismus für den Browser zusammengebaut.

Jetzt soll alles schöner werden!

Ich hatte nun endgültig Feuer gefangen und es gab kein zurück mehr. Dann konnte es auch schöner werden :) Es gelang mir leider nicht auf Anhieb Vue.js einzubinden, allerdings zweifelte ich auch, ob das überhaupt sinnvoll sei. In SeaSite hatte ich bereits JSX und JSDOM eingesetzt. Für ein anderes Projekt hatte ich bereits eine DOM Abstraktion geschrieben, die sehr schlank ist. Diese baute ich nun so aus, dass damit per JSX einfach HTML und XML generiert worden konnte.

Somit war eine Manipulation der Inhalte durch einfache DOM Aktionen möglich. Wie viel schöner wäre es aber, wenn die entsprechenden Nodes per CSS-Selektoren gefunden werden könnten. Also baute ich auch das mit css-parse ein und es funktionierte wunderbar.

Auch ein Markdown-Parser war aus SeaSite schon vorhanden und wurde nur noch entsprechend ausgebaut, dass unter Beibehaltung der angenehmen Geschwindigkeit die Meta-Daten für die Registrierung von Routen zur Verfügung standen.

Open Source!

Nun war also alles an Bord was benötigt wurde und es wurde Zeit eine einfache einheitliche Struktur zu schaffen, um das Projekt veröffentlichen zu können. Ein erstes Ziel war die Routen durch einfache Datenstrukturen zu beschreiben, um maximale Flexibilität zu erhalten. Für gängige Formate wie HTML, XML, JSON, Text und Assets wurden bequeme Methoden erstellt.

Da nun schon ohnehin alles die Anmutung eines Webservers hatte, der eben auch statische Seiten ausspucken kann, lag es nahe das smarte Middleware Muster von Koa.js zu übernehmen. Auf diese Weise sind Templates und Plugins leicht zu realisieren. Eine Kopie der genannten Datenstruktur dient dann als Kontext und das Ergebnis wird im Property ctx.body erwartet.

Hier ist es nun, das fertige Projekt. Ich würde mich sehr über Hilfe und Ideen freuen. Vielleicht ist es nicht das tollste Tool, um statische Websites zu erzeugen, aber eventuell die Basis für eine noch smartere Lösung die darauf aufbaut.

github.com/holtwick/hostic

https://www.npmjs.com/package/hostic

Im Folgenden werde ich einige Themen weiter beleuchten wollen, die sich aus der Erstellung einer Website ergeben und wie diese mit Hostic gelöst werden können. Die Liste der aktuellen Ideen zu Themen:

• Aufbau einer einfachen statischen Website mit Hostic
• Aufbau eines Blogs mit Markdown
• Aufbau einer Mehrsprachigen Website und Lokalisierung
• Optimierungen für Suchmaschinen und Accessibility
• Hosting: Beaker Browser, sh…

Diese Webseiten wurden bereits von Hostic erstellt:

• https://pdfify.app
• https://holtwick.de

Ausgangslage

Die wertvollsten und erfolgreichsten Unternehmen sind IT-Firmen: Apple, Google, Amazon und Microsoft. Alle mit Sitz in den USA. China, ein weiterer riesiger Markt, ist die Produktionsstätte der meisten Hardware, aber auch Sitz von Firmen die erfolgreich den Platz der US Firmen einnehmen: Alibaba, Tencent und mehr. Auch Schwellenländer haben ihren eigenen Markt, in dem Online-Geschäfte stattfinden. KaiOS ist ein Beispiel für ein innovatives Modell, dass in der ersten Welt kaum bekannt ist.

Wo steht Europa? Es gibt keine nennenswerten Online-Plattformen. Betriebe und Verwaltung machen sich abhängig von Software aus den USA und Hardware aus China. Kreative Unternehmer und talentierte Entwickler wandern ab in die USA. Auf lange Sicht wird Europa bedeutungsloser als Innovator und bleibt Importeur von Technologie. Das ist fatal.

Europa braucht eine Strategie und den politischen Willen diesen Trend zu ändern. Das Potenzial und die Mittel aber wären vorhanden, Europa unabhängiger in einer sich verändernden globalen Welt zu machen. Ich möchte im Folgenden meine persönlichen Gedanken zu so einer Strategie darlegen.

Daten

Europa sollte auf keinen Fall versuchen die USA oder China zu kopieren. Die bestehenden erfolgreichen Lösungen sind im Grunde zentralistierte Lösungen. Es werden also Services angeboten, bei denen die Daten der Kunden im Zugriff der betreibenden Firmen sind. Egal wie gut sich die Privacy-Versprechungen auf den Webseiten lesen lassen, de facto gibt es keinen Schutz der Daten vor den Firmen oder den Behörden des Landes in dem der Sitz des Unternehmens liegt – in der Regel den USA oder China.

Daten sind die Ware des Informationszeitalters. Der erste Unterschied, den Europa bei seiner Strategie machen sollte, ist der absolute Schutz dieser Daten. Der Benutzer sollte vollen Zugang und Kontrolle zu über seine Daten haben, um nicht in Abhängigkeit einzelner Unternehmen zu geraten. Das ist zu erreichen durch dezentrale Lösungen und starker Verschlüsselung.

Plattform

Daten müssen angezeigt und bearbeitet werden können. Dazu werden Computer, Tablets, Smartphones und mit der Zeit weitere Geräte verwendet werden. Wichtig ist, welches Betriebssystem benutzt wird, denn das ist quasi das Fundament auf dem alle Lösungen aufbauen. Microsoft, Google und Apple haben hier im Prinzip ein Monopol, wiederum alle ansässig in den USA. Europa sollte auf eine eigene freie Plattform setzen, dabei bieten sich Linux und Android als erster Ausgangspunkt an.

Aber neben dem Betriebssystem hat sich ein weiteres heimliches Betriebssystem etabliert: der Webbrowser. Ursprünglich eine europäische Erfindung, hat er den Informationszugang im Internet revolutioniert. In den letzten Jahren hat die Komplexität immer weiter zugenommen und die meisten Dienste eines Computers können mittlerweile mit Webtechnologien angesteuert werden. Die Programmierung ist leicht zu erlernen und die Kenntnis davon weit verbreitet. Mit WebAssembly gibt es nun auch keine wirklichen Performance-Probleme mehr.

Europa sollte ausnutzen, dass es die bewährte Web-Plattform gibt. Allerdings ist nach der Schwächung von Firefox nun nur noch eine Browser-Engine relevant und diese wird von Google und Apple kontrolliert. Europa sollte kurzfristig eine eigene offenen Engine entwickeln, dazu bietet sich Servo an. Langfristig könnte das Betriebssystem als ganzes durch eine Web-Engine ersetzt werden, nach dem Muster von Google Chrome OS.

Hardware

Auch den Geräten selber muss vertraut werden können. In vielen Chips gibt es eigene kleine Betriebssysteme, die wichtige Funktionen übernehmen und in die normalen Entwickler keinen Einblick bekommen. Es wäre wichtig auch hier in der Entwicklung und der Produktion selbständiger zu werden, am besten mit einem offenen Ansatz. Warum sollten nicht mehrere Hardwarehersteller dieselben Chips produzieren? ARM ist ja ein entsprechend erfolgreiches Modell in diesem Bereich. Leider kenne ich mich zu wenig aus in diesem Thema, um mehr ins Detail gehen zu können. Doch wichtig scheint mir auch hier eine Basis zu schaffen, der vertraut werden kann und die nicht monopolisiert wird.

Software

Der öffentliche Bereich, also Verwaltungen und Behörden, sollten dazu verpflichtet werden Open-Source-Software zu verwenden und zu entwickeln. Jede Lösung die mit staatlichen Geldern entwickelt wird, muss frei und offen zugänglich sein und frei von Lizenzkosten betrieben werden können. Das Geld alleine das aktuell an Lizenzen für Windows in Europa ausgegeben wird sollte schon reichen, um eine Softwareentwicklung zu fördern. Aufträge zur Entwicklung und Pflege wiederum sollten in Europa vergeben werden, um hier Kompetenzen und Märkte anzuschieben und aufzubauen.

Bildung

Sowohl die Bildung im Umgang mit IT, also auch die Vermittlung von Wissen durch IT sollte gestärkt werden. Gerade in Zeiten von Corona sind die Defizite klar zum Vorschein gekommen. Die Bedürfnisse an eine Bildungsinfrastruktur sind sicherlich vergleichbar in ganz Europa, dennoch gibt es keine mir bekannte gemeinsame Anstrengung eine Lösung zu finden.

Im Bereich der Inhalte gibt es mittlerweile diverse Lösungen, wie zum Beispiel in Deutschland Anton App, Musste Wissen oder SimpleClub. Aber auch international wie Khan Academy. Dennoch bereitet jeder Lehrer seinen Unterricht aufs neue individuell vor und Erfahrungen werden nicht effektiv untereinander geteilt. Eine bessere Förderung solcher Inhalte könnte sowohl den klassischen, als auch den virtuellen Unterricht verbessern und Europa so besser aufstellen, da das Bildungsniveau zunimmt und vergleichbarer wird.

Innovation

Europäische Bürger haben immer wieder gezeigt, dass sie innovativ sind und Zukunftsthemen erkennen. Erneuerbare Energie ist ein gutes Beispiel dafür, dass aber gleichzeitig auch ein schlechtes Beispiel für den kurzen Atem bei der Förderung durch die Politik ist. Im Bereich Mobilität war Europa mit fossilen Brennstoffen vorne dabei, hat dann aber die Entwicklung verschlafen, obwohl viele Innovationen zu den Antrieben der Zukunft auch in Europa stattfanden.

Die großen Herausforderungen unserer Zeit sind gleichzeitig auch Chancen die genutzt werden müssen. Das Potenzial ist da, nun braucht es den Mut und die Leidenschaft eigene Wege einzuschlagen und das möglichst rasch.

Links zu ähnlichen Themen:

• Kommentar: Digitale Souveränität zum Schnäppchenpreis – von Europa und Mozilla von Felix von Leitner, Heise.
• A clean start for the web von Tom MacWright

Update 7.9.2020:

• Whitepaper: Digitale Souveränität als neue staatliche Aufgabe definieren