Eine der zentralsten Funktionen einer Entwicklungsumgebung ist, den geschriebenen Code auszuführen. Gerade bei einer Web-Entwicklungsumgebung wie der Hedgehog IDE ist das ein kritischer Punkt: Webanwendungen im Browser haben keinen Zugriff auf den Computer des Benutzers, einfach so Python aufrufen oder eine Windows-Anwendung ausführen geht nicht. Was die Webanwendung tun will, passiert entweder im Browser, auf einem Server oder "in der Cloud". Für die Hedgehog IDE, bei der Datenschutz und Privatsphäre einen großen Stellenwert einnehmen, entstehen dadurch interessante Abwägungen.

Offline first

Den besten Schutz haben Daten, die nie ins Internet übertragen werden. Was man im Browser machen kann, sollte deswegen im Browser passieren. "Offline first" nennt sich diese Philosophie, dass eine Webanwendung nicht ständig das Internet brauchen sollte. Neben den Datenschutzvorteilen verbessert dieser Grundsatz auch gleich die Benutzbarkeit bei langsamer oder fehlender Internetverbindung, und schont obendrein das Datenvolumen und den Akku unserer Nutzer.

Web vs Native

Der Browser ist eingeschränkt auf die Ausführung von JavaScript-Programmen; neuerdings beinhaltet die Palette zusätzlich noch WebAssembly. Wenn eine Webanwendung Zugriff auf eine native Anwendung braucht, muss diese auf einem Server aufgerufen werden. In Sachen Datenschutz heißt das, dass zu diesem Zeitpunkt von den Benutzern geschriebener Code ins Internet geschickt wird.

Früher oder später werden wir natürlich Code unserer Nutzer speichern müssen. Ob ich Code zwischen meinen Geräten synchronisieren oder mit anderen teilen will: eine zentrale Speicherung auf unseren Servern wird nötig sein. Soweit möglich wollen wir aber den Nutzern ihren Code überlassen, wenn sie für diese Funktionen keinen Bedarf haben.

Compiler und Interpreter

Viele für die Software-Entwicklung interessante Programme sind nur nativ verfügbar: Compiler wie der gcc, oder Interpreter für Sprachen wie Python kann man nicht einfach im Browser ausführen. Auch wenn gcc mit seiner Arbeit fertig ist, ist das Ergebnis normalerweise ein natives Programm, das heißt unsere User wären gleich doppelt auf den Server angewiesen.

Das klingt nach einer schlechten Ausgangslage, aber das ist nur die halbe Wahrheit. Das Wort "WebAssembly" ist hier ein riesiger Hoffnungsschimmer, der das Potenzial hat die Grenze zwischen webfähigen und nativen Anwendungen verschwimmen zu lassen. Aber zuerst ein paar Beispiele zum Status quo:

• Kompilierte Programmiersprachen wie C und Rust: Ein Compiler, also eine native Anwendung, ist notwendig, um eine ausführbare Datei zu erzeugen. Diese ist normalerweise wieder eine native Anwendung, muss also ebenso am Server ausgeführt werden. Mittlerweile unterstützen viele Compiler aber schon die WebAssembly Plattform, womit diese Programme für die Ausführung im Browser kompiliert werden können.
• Interpretierte Programmiersprachen wie Python und Ruby: Compiler sind nicht notwendig, aber die Interpreter liegen oft nur als native Anwendungen vor. Manche Sprachen haben auch webbasierte Interpreter, aber auch diese haben oft Nachteile: sie sind langsamer, nicht ganz kompatibel mit dem Original, und/oder groß und damit langsam herunterzuladen.
• JavaScript: ist natürlich auch eine interpretierte Sprache, hat aber im Web eine Sonderstellung. JavaScript-Code kann von Browser direkt ausgeführt haben, was exakt die Nachteile aus dem vorigen Punkt ausgleicht: kein extra Download nötig, volle Performance und Kompatibilität.

Security

Egal ob Browser oder Server: von Benutzern eingegebenen Programmcode ohne Sicherheitsvorkehrungen auszuführen ist gefährlich. Auf dem Server steht viel auf dem Spiel, aber auch im Browser gibt es Risiken.

Moderne Browser bieten dem Benutzer viel Schutz vor allerlei Bedrohungen: Webanwendungen können nicht auf das Dateisystem zugreifen, außer über einen expliziten Up- oder Download, und auch verschiedene Webseiten sind voneinander isoliert. Zumindest, solange der Browser weiß, dass es sich um verschiedene Webseiten handelt. "Cross-Site-Scripting" heißt die Angriffstechnik, die diese Sicherheitsvorkehrung umgeht: Wenn ein Angreifer es schafft, dass die Webanwendung selbst den schädlichen Javascript-Code lädt, bekommt dieser Code Zugriff auf den Rest der Webanwendung, und kann zum Beispiel im Namen des Benutzers Formulare ausfüllen und abschicken.

Eine Web-IDE muss natürlich Code von einer "fremden Quelle" (dem Benutzer) ausführen, möglicherweise will der Benutzer auch Programme von anderen ausprobieren. Die Hedgehog IDE muss also sich selbst und die Benutzer vor solchen Angriffen schützen.

Fazit

In Zukunft wird das Spektrum, was eine Web-Entwicklungsumgebung offline bewerkstelligen kann, sicher größer werden. In der Zwischenzeit aber ist JavaScript-Ausführung im Browser definitiv der richtige Startpunkt. Wie das sicher umgesetzt werden kann, darum wird es im nächsten Post gehen.