Native File System API: Dateisystemzugriff für Websites und PWAs im Anflug

Inhaltsverzeichnis

Word braucht es, Visual Studio Code braucht es, Photoshop braucht es: Die Rede ist vom Zugriff auf das native Dateisystem. Was im Web lange Zeit unerreichbar schien, wird nun bald Wirklichkeit: Die Native File System API könnte gleich einen ganzen Schwung von Anwendungen ins Web bringen. Mit Google Chrome 77 wird ein erster Wurf der Schnittstelle getestet.

Für eine Vielzahl von Anwendungen ist der fehlende Zugriff auf das native Dateisystem der wohl größte Blocker, um sie als Progressive Web App – also als reine Web-Applikation ohne nativen Unterbau – herauszugeben. Office-Anwendungen, Medienplayer, IDEs sowie Text-, Bilder oder Videoeditoren brauchen schlichtweg einen Zugriff auf Dateien und Ordner, die im Dateisystem des Computers abgelegt sind. Als Teil der Project-Fugu- bzw. Web-Capabilities-Schnittstellen testet Google nun die Native File System API, die es Webanwendungen erlaubt, Ordnerinhalte aufzulisten sowie Dateien zu lesen und zu schreiben.

Zum Beispiel Microsoft Visual Studio Code: Der quelloffene Editor von Microsoft ist bereits eine Webanwendung, die derzeit in einem nativen Container (Electron) verpackt ausgeliefert wird. Dieser Container bündelt einen Chromium-Browser mit einer Node.js-Installation und gewährt der Webanwendung darüber Zugriff auf native Funktionen wie das Dateisystem oder das Terminal.

Allerdings werden somit selbst Hello-World-Anwendungen gleich mehrere dutzend Megabyte groß. Weiterhin ergibt sich durch die separaten Laufzeitprozesse ein RAM-Overhead. Beides entfällt, wenn die Anwendung direkt innerhalb des Browsers ausgeführt werden kann. Das setzt aber voraus, dass es eine passende Webschnittstelle gibt, die die gewünschte Funktionalität implementiert. Mit Erscheinen der Native File System API sinkt daher die Notwendigkeit, einen Texteditor wie VS Code als native App herausgeben zu müssen.

Plattformübergreifende Schnittstelle

Moderne Webschnittstellen werden so entworfen, dass sie grundsätzlich plattformübergreifend verwendbar sind. Entwickler müssen also nicht das Betriebssystem prüfen und davon abhängig verschiedene Implementierungen ansprechen, sondern verwenden immer dieselbe API. Das gilt auch für die Native File System API. Spezifiziert wird sie bei der Web Incubator Community Group (WICG) des W3C.

Die Native File System API erweitert dabei die Schnittstellen des globalen Window-Objekts. Durch den Aufruf der Methode chooseFileSystemEntries() öffnet sich der bekannte Dateiauswahldialog. Der Methode lässt sich ein Konfigurationsobjekt übergeben. Darüber kann die Mehrfachauswahl aktiviert, die erlaubten Dateiendungen eingeschränkt und der Dialogtyp (Datei öffnen, Verzeichnis öffnen, Datei speichern) angegeben werden. Standardmäßig wird ein Datei-öffnen-Dialog mit Einfachauswahl angezeigt. Das nachstehende Listing zeigt, wie eine Auswahl für TXT-Dateien angezeigt und der Inhalt der gewählten Datei ausgelesen werden kann:

btnOpenFile.addEventListener('click', async () => {
  const handle = await window.chooseFileSystemEntries({
    accepts: [{ extensions: ['txt'] }]
  });
  const file = await handle.getFile();
  console.log(await file.text());
});

Bricht der Benutzer den Dateiauswahldialog ab, erhält die Webanwendung gar keinen Zugriff. Andernfalls erhält sie ein Handle, mithilfe dessen auf die vom Benutzer gewählte Dateien beziehungsweise Verzeichnisse zugegriffen werden kann. Mit dem Handle ist auch ein Überschreiben der gewählten Datei möglich. Dazu steht auf ihm die Methode createWritable() bereit. Der Aufruf dieser Methode gibt einen FileSystemWritableFileStream zurück, der schreibenden Zugriff auf die zuvor ausgewählte Datei erlaubt.

const writable = await handle.createWritable(); 
await writable.write('this is Chrome'); 
await writable.close(); 

Der Webbrowser fordert Anwender in diesem Fall noch einmal gesondert auf, das Überschreiben der Datei zu bestätigen. Stimme sie zu, darf die Webanwendung die Datei ohne weitere Abfrage überschreiben – bis die aktuelle Registerkarte geschlossen wird.

Schutzmaßnahmen

Alle modernen Webschnittstellen müssen Sicherheitsvorkehrungen gegen eine missbräuchliche Verwendung der API ergreifen – das gilt auch für die Native File System API. Wie für die meisten modernen Webschnittstellen üblich, wird die Übertragung der Website über eine gesicherte Verbindung (HTTPS) vorausgesetzt. Der Dateisystemzugriff darf nur infolge einer Benutzerinteraktion (Klick oder Tastendruck) angefordert werden. Anwender müssen das Lesen und Speichern von Dateien jeweils vorher bestätigen.

Hat eine Webanwendung gerade schreibenden Zugriff auf das Dateisystem, weist Chrome durch ein Symbol in der Adresszeile prominent darauf hin. Darüber hinaus verweigert der Webbrowser den Zugriff auf Systemordner und andere sensible Verzeichnisse.

Sonderrechte für PWAs geplant

Im ersten Wurf ist es nicht möglich, das Handle und somit die Berechtigung zum Zugriff auf bestimmte Dateien oder Verzeichnisse zu persistieren. Anwender müssen stattdessen vor jeder Verwendung den Zugriff explizit wieder freigeben – vergleichbar zur Contacts Picker API. Für die Zukunft ist angedacht, dass auf dem Gerät installierte Progessive Web Apps das Handle in der lokalen Clientdatenbank IndexedDB speichern dürfen. Das erlaubt es etwa, "Zuletzt verwendet"-Menüs anzubieten. Nicht installierte Webanwendungen müssen die Erlaubnis hingegen erneut einholen.

Die Native File System API wird mit Google Chrome 77 erstmals ausgerollt, verbirgt sich jedoch noch hinter einem Flag (chrome://flags/#native-file-system-api). Die Schnittstelle kann schon heute in Google Chrome Canary und Microsoft Edge Canary ausprobiert werden. Wie üblich soll die API in der sogenannten Origin Trial einem begrenzten Publikum auch ohne vorherige Aktivierung des Flags verfügbar gemacht werden können. Diese Implementierungsphase wird für Chrome 78 erwartet. Das Google-Entwicklerteam freut sich auf Feedback seitens der Webentwickler im zugehörigen Discourse-Thread bei der WICG sowie auf Twitter unter dem Hashtag #nativefs.

()