Faktencheck zu Progressive Web Apps, Teil 2: Sicherheit und Privatsphäre

PWAs greifen auf mächtige Webschnittstellen zurück. Ob sie die Sicherheit und Privatsphäre des Anwenders wahren, wird in diesem Teil des Faktenchecks besprochen.

In Pocket speichern vorlesen Druckansicht 19 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Christian Liebel

Im vergangenen Teil des PWA-Faktenchecks ging es um die Plattformunabhängigkeit des Anwendungsmodells und seine Abgrenzung zu früheren, Plug-in-basierten Ansätzen. In diesem Teil möchte ich die Aspekte Sicherheit und Privatsphäre besprechen.

Webschnittstellen werden grundsätzlich mit dem Hintergedanken entwickelt, Sicherheit und Privatsphäre der Anwender zu wahren. In den Spezifikationen findet sich diesbezüglich oftmals ein Abschnitt namens "Security and Privacy Considerations". Die meisten Webschnittstellen erfordern mittlerweile außerdem, dass der Website-Inhalt über eine gesicherte Verbindung (HTTPS) übertragen wird. Das stellt sicher, dass die Kommunikation zwischen Webserver und Browser nicht von Dritten mitgelesen werden kann. Für die Kerntechnologie der Progressive Web Apps, den Service Worker, gilt all das.

Nein. Das Konzept der Browser-Sandbox wird durch moderne Webschnittstellen nicht unterminiert: Progressive Web Apps mögen sich zwar in einem eigenen Fenster oder in einer vollflächigen Darstellung öffnen, doch im Hintergrund tickt als Ausführungsplattform nach wie vor der Webbrowser. Die Progressive Web App wird wie gehabt in einer Sandbox ausgeführt. Sie kann also fremde Browser-Tabs nicht manipulieren und auch nicht wahlfrei auf Systemressourcen zugreifen.

Innerhalb der Sandbox läuft auch die Technologie WebAssembly (wasm), die die Kompilierung von in anderen Sprachen wie C oder Rust verfasstem Quellcode in Bytecode erlaubt, der plattformübergreifend in Webbrowsern zum Laufen gebracht werden kann. Dieser Code wird letztlich aber auch nur durch dieselbe JavaScript-Runtime innerhalb der Browser-Sandbox ausgeführt, sodass auch WebAssembly nur auf solche Funktionen zugreifen kann, die auch aus JavaScript heraus aufgerufen werden können. Sicherheitslücken im Webbrowser selbst können selbstverständlich nicht ausgeschlossen werden, wie es auch für jede andere Laufzeitumgebung gilt.

Steuerung der vergebenen Berechtigungen in Google Chrome

Dass es Betrüger gibt, die die Macht moderner Webschnittstellen ausnutzen wollen, ist den Autoren der Schnittstellenspezifikationen und den Browserherstellern bewusst. Zugriff auf die angeschlossenen Gamepads gibt es für die Webanwendung bei der Gamepad API zum Beispiel erst, nachdem die Anwender eine Taste auf dem Gamepad gedrückt haben, um Fingerprinting vermeiden. Sobald auf besonders datenschutzrelevante Funktionen zugegriffen werden soll, zum Beispiel Kamera und Mikrofon oder den Standort des Anwenders, holt der Webbrowser zuvor dessen Einverständnis ein.

Dieses Verfahren ist von mobilen Plattformen bekannt und erlaubt den Anwendern eine sehr feingranulare Kontrolle darüber, auf welche Funktionen die Webanwendung zugreifen darf. Berechtigungen lassen sich auch nachträglich vergeben oder widerrufen. Gegenüber nativen Anwendungen auf Desktopsystemen stellt dies einen deutlichen Fortschritt dar. Wie WinRT und macOS ab Mojave zeigen, schwappen Berechtigungsabfragen sogar in die Desktop-Welt zurück.

Mit dem Google-Projekt Fugu sollen weitere mächtige Schnittstellen ins Web Einzug erhalten, etwa für den Zugriff auf einen Teilbereich des nativen Dateisystems oder das Adressbuch des Anwenders. Im nächsten Teil geht es um die Offenheit und Abwärtskompatibilität dieser Schnittstellen. ()