Isolated Web Apps: Wird die Web-App-Gap ein für alle mal geschlossen?
Das Web ist zur Heimat vieler Anwendungen geworden, doch es bleibt eine Lücke zwischen Web-Apps und nativen Anwendungen. Können IWAs diese Lücke schließen?
(Bild: Andrey Suslov/Shutterstock.com)
- Christian Liebel
Das Web ist in den vergangenen Jahren deutlich leistungsfähiger geworden: Nicht zuletzt hat das Anwendungsmodell der Progressive Web Apps (PWA) sowie die Chromium-Initiative Project Fugu dazu beigetragen, dass zunehmend viele Anwendungen direkt für das Web verfasst und im Browser lauffähig gemacht werden können, wie etwa Photoshop oder Visual Studio Code.
Aufgrund der Sicherheitsarchitektur des Web wird die Web-App-Gap, also die Lücke zwischen den Möglichkeiten plattformspezifischer Anwendungen und Web-Apps aber nie ganz geschlossen werden können.
Fehlender Socket-Zugriff löste die Diskussion aus
Eine Schnittstelle, die direkt im Web nicht verfügbar gemacht werden kann, ist die Direct Sockets API, die Entwicklern die Möglichkeit eröffnen sollte, beliebige Server-Ports anzusprechen – über HTTPS, WebSockets und WebRTC hinaus.
Da diese die Same-Origin-Policy (SOP) des Web umgehen würde, und damit eine zentrale Sicherheitsbarriere im Web, meldete die Technical Architecture Group (TAG) des W3C deutliche Bedenken an. Dieses gewählte Gremium innerhalb des W3C soll sicherstellen, dass sich neue Schnittstellen sinnvoll in das World Wide Web einfügen.
Das Web soll leistungsfähiger werden
Gleichzeitig wünschen sich Softwareentwickler jedoch, diese Fähigkeiten nutzen zu können. Manche komplett grundlegenden Schnittstellen sind im Web oder zumindest nicht in allen Browsern verfügbar.
Die TAG kündigte im September 2023 auf der diesjährigen W3C-Jahreskonferenz TPAC in Sevilla daher die Gründung einer Taskforce an, um auch solche Schnittstellen ins Web bringen zu können.
Untersucht werden soll dabei ein möglicher "powerful context", bei dem der Anwender in die Installation einer Anwendung etwa explizit einwilligen könnte, um weitere Fähigkeiten wie den Zugriff auf Sockets freizuschalten.
Isolated Web Apps als möglicher Ausweg
Einen möglichen Vorschlag für einen solchen leistungsfähigen Kontext lieferte Google in der Vergangenheit bereits: die sogenannten Isolated Web Apps (IWA). Auch bei diesem Anwendungsmodell handelt es sich um Webanwendungen, die dieses Mal aber in Form eines signierten Bündels vertrieben werden, über die klassischen Vertriebswege wie App-Stores, Installationspakete oder Enterprise-Deployments. Auch ein Sideloading durch die direkte Installation des Bundles wäre möglich.
Durch diesen zusätzlichen Vertrauensanker erhalten die Webanwendungen im Gegenzug dann Zugriff auf einen größeren Umfang von Schnittstellen. Ausgeführt würden diese trotzdem durch einen Browser.
Code-Signing trifft auf das Web
Durch die Signatur werden Man-in-the-Middle-Angriffe oder die Manipulation des Quellcodes auf dem Anwendungsserver deutlich erschwert. Aufgrund solcher Bedenken wird etwa der Messenger Signal nur als Electron-App, nicht aber als Progressive Web App herausgegeben.
Alle Folgeversionen müssen mit demselben Schlüssel signiert werden. Um Downgrading-Angriffe zu vermeiden, dürfen Updates ausschließlich auf eine höhere Versionsnummer vorgenommen werden. Das Laden von Quellcode außerhalb des Anwendungskontextes wird unterbunden, daher rührt auch der Name Isolated Web App. Hierfür würde ein eigenes URI-Schema eingeführt: isolated-app://signed-web-bundle-id/path/foo.js?query#fragment
Die signed-web-bundle-id entspricht dabei dem Base32-kodierten öffentlichen Schlüssel.
Vorteile des IWA-Modells
Im Falle der IWAs werden Anwendungen über die klassischen, dem Anwender vertrauten Vertriebswege ausgeliefert. Anwendungsentwickler können ihr bestehendes Webwissen mitnehmen, aber dank des zusätzlichen Vertrauensankers auf noch leistungsfähigere Schnittstellen zugreifen. Diese würden auch weiterhin durch das W3C offen standardisiert.
Die Anwendungen basieren weiterhin auf Webtechnologien und könnten auch Code etwa mit einer PWA teilen. Und das alles ohne die Zusatzlast klassischer Wrapper-Ansätze wie Electron, Tauri, Cordova oder Capacitor.
Smartcard-Demo demonstriert das Anwendungsmodell
Die Web Smart Card API Demo des Chrome-Teams soll das IWA-Anwendungsmodell demonstrieren, indem die verpackte Webanwendung Zugriff auf Smartcards bekommt, um Personen zu identifizieren. Allerdings setzt dies ein ChromeOS-Gerät und die Aktivierung mehrerer Feature-Flags voraus. Unterstützung für die Web Smart Card API soll im Laufe des Jahres 2024 in Chromium für Windows, macOS und Linux hinzugefügt werden.
Fazit
Zusammengefasst könnten Isolated Web Apps die Web-App-Gap tatsächlich erneut deutlich reduzieren und das Cross-Plattform-Feld aufmischen. Allerdings steht die gesamte Anstrengung noch komplett am Anfang. Die im September ausgerufene Taskforce wurde bislang noch nicht eingerichtet. Und auch ein Commitment von Mozilla oder Apple gibt es derzeit noch nicht.
(rme)
