Isolierte Web-Apps

Das Web ist eine wirklich einzigartige Anwendungsplattform. Apps, die darauf basieren, sind sofort auf jedem Betriebssystem verfügbar, ohne dass Codeänderungen oder eine Kompilierung erforderlich sind. Wenn ein Nutzer Ihre App aufruft, hat er immer die aktuelle Version. Sie sind installierbar und können offline verwendet werden, sind leistungsstark und lassen sich ganz einfach über einen Link teilen. Sie entwickeln eine Webanwendung und sie funktioniert einfach überall.

Da das Web standardmäßig sicher sein soll, muss sein Sicherheitsmodell sehr konservativ sein. Alle neuen Funktionen müssen so gestaltet sein, dass sie für einen normalen Nutzer sicher sind, falls er versehentlich über eine URL darauf stößt. Wir nennen dieses Sicherheitsmodell Drive-by-Web. Das ist zwar für viele Anwendungen ideal und kann durch Content Security Policies und Cross-Origin Isolation sicherer gemacht werden, funktioniert aber nicht für jeden Anwendungsfall. Eine Reihe wichtiger und leistungsstarker APIs, die Entwickler benötigen, wie Direct Sockets und Controlled Frame, können nicht sicher genug für das Web sein.

Für diese Anwendungen gibt es derzeit keine Option für die Entwicklung im Web. Für andere ist das Sicherheitsmodell des Webs möglicherweise nicht konservativ genug. Sie gehen möglicherweise nicht davon aus, dass der Server vertrauenswürdig ist, und bevorzugen stattdessen diskret versionierte und signierte eigenständige Anwendungen. Es ist ein neues Sicherheitsmodell mit hohem Vertrauen erforderlich. Isolierte Web-Apps (IWAs) bieten ein isoliertes, gebündeltes, versioniertes, signiertes und vertrauenswürdiges Anwendungsmodell, das auf der bestehenden Webplattform basiert, um diese Entwickler zu unterstützen.

Vertrauensspektrum im Web

Sicherheit und Funktionen im Web lassen sich als Spektrum betrachten.

Das Drive-by-Web auf der linken Seite hat das niedrigste Sicherheitsmodell, da es am zugänglichsten sein muss und daher den geringsten Zugriff auf das System eines Nutzers hat. Web-Apps, die im Browser installiert werden, genießen etwas mehr Vertrauen und können etwas tiefer in das System eines Nutzers integriert werden. Nutzer können in der Regel problemlos zwischen Webversionen von Apps, auf die über den Browser zugegriffen wird, und im Browser installierten Versionen wechseln.

Dann gibt es noch isolierte Webanwendungen mit hohem Vertrauen.

Sie sehen aus wie native Apps und verhalten sich auch so. Außerdem können sie auf umfassende Systemintegrationen und leistungsstarke Funktionen zugreifen. Nutzer können nicht zwischen ihnen und dem Drive-by-Web wechseln. Wenn Sie dieses Sicherheitsniveau oder diese Funktionen benötigen, gibt es kein Zurück.

Wenn Sie sich entscheiden müssen, wo auf diesem Spektrum Sie sich bewegen sollten, wählen Sie das Sicherheitsmodell mit dem geringsten Vertrauen, das Sie verwenden können, z. B. eine Progressive Web-App. So erreichen Sie die meisten Nutzer, müssen sich selbst um die wenigsten Sicherheitsbedenken kümmern und sind für Ihre Entwickler und Nutzer am flexibelsten.

Von Grund auf sicher

Isolierte Web-Apps bieten ein Sicherheitsmodell mit hohem Vertrauen für Webanwendungen. Dazu müssen jedoch einige der Annahmen, die das Web über Vertrauen trifft, überdacht werden. Kernkomponenten des Webs wie Server und DNS können nicht mehr explizit vertraut werden. Angriffsvektoren, die für native Apps möglicherweise relevanter erscheinen, werden plötzlich wichtig. Um Zugriff auf das neue Sicherheitsmodell mit hohem Vertrauen zu erhalten, das von IWAs bereitgestellt wird, müssen Web-Apps verpackt, isoliert und gesperrt werden.

Verpackt

Seiten und Assets für isolierte Web-Apps können nicht von Live-Servern bereitgestellt oder über das Netzwerk abgerufen werden wie normale Webanwendungen. Stattdessen müssen Web-Apps alle Ressourcen, die zum Ausführen erforderlich sind, in einem signierten WebBundle verpacken, um Zugriff auf das neue Sicherheitsmodell mit hohem Vertrauen zu erhalten. Bei signierten Web-Bundles werden alle Ressourcen, die zum Ausführen einer Website erforderlich sind, in einer .swbn-Datei zusammengefasst und mit einem Integritätsblock verkettet. So kann die Web-App sicher und vollständig heruntergeladen und sogar offline geteilt oder installiert werden.

Dies stellt jedoch ein Problem für die Überprüfung der Authentizität des Codes einer Website dar: TLS-Schlüssel erfordern eine Internetverbindung. Statt mit TLS-Schlüsseln werden IWAs mit einem Schlüssel signiert, der sicher offline aufbewahrt werden kann. Wenn Sie alle Ihre Produktionsdateien in einem Ordner zusammenfassen können, können Sie daraus ohne große Änderungen eine IWA erstellen.

Signaturschlüssel generieren

Signaturschlüssel sind Ed25519- oder ECDSA P-256-Schlüsselpaare. Der private Schlüssel wird zum Signieren des Bundles und der öffentliche Schlüssel zum Überprüfen des Bundles verwendet. Sie können OpenSSL verwenden, um einen Ed25519- oder ECDSA P-256-Schlüssel zu generieren und zu verschlüsseln:

# Generate an unencrypted Ed25519 key
openssl genpkey -algorithm Ed25519 -out private_key.pem

# or generate an unencrypted ECDSA P-256 key
openssl ecparam -name prime256v1 -genkey -noout -out private_key.pem

# Encrypt the generated key. This will ask for a passphrase, make sure to use a strong one
openssl pkcs8 -in private_key.pem -topk8 -out encrypted_key.pem

# Delete the unencrypted key
rm private_key.pem

Signierschlüssel haben auch einen sekundären Zweck. Da eine Domain wie ein Server anfällig für Kontrollverlust sein kann, kann sie nicht verwendet werden, um die installierte IWA zu identifizieren. Stattdessen wird eine IWA über den öffentlichen Schlüssel des Bundles identifiziert, der Teil der Signatur ist und an den privaten Schlüssel gebunden ist. Das ist eine erhebliche Änderung der Funktionsweise des Drive-by-Web. Anstelle von HTTPS verwenden IWAs auch ein neues Schema: isolated-app://.

App bündeln

Nachdem Sie Ihren Signaturschlüssel haben, können Sie Ihre Web-App bündeln. Dazu können Sie die offiziellen NodeJS-Pakete verwenden, um Ihre IWAs zu bündeln und dann zu signieren. Go-Befehlszeilentools sind ebenfalls verfügbar. Verwenden Sie zuerst das Paket wbn und verweisen Sie auf den Ordner mit allen Produktionsdateien Ihrer IWA (hier „dist“), um sie in ein nicht signiertes Bundle zu packen:

npx wbn --dir dist

Dadurch wird ein unsigniertes Web-Bundle des Verzeichnisses in out.wbn. generiert. Verwenden Sie nach der Generierung den verschlüsselten Ed25519- oder ECDSA P-256-Schlüssel, den Sie zuvor erstellt haben, um das Web-Bundle mit wbn-sign zu signieren:

npx wbn-sign -i out.wbn -k encrypted_key.pem -o signed.swbn

Dadurch wird ein signiertes Web-Bundle aus dem unsignierten Web-Bundle mit dem Namen signed.swbn generiert. Nach der Signierung gibt das Tool auch die Web-Paket-ID und den Ursprung der isolierten Web-App aus. Der Ursprung der isolierten Web-App ist die Art und Weise, wie Ihre IWA im Browser identifiziert wird.

Web Bundle ID: ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic
Isolated Web App Origin: isolated-app://ggx2sheak3vpmm7vmjqnjwuzx3xwot3vdayrlgnvbkq2mp5lg4daaaic/

Wenn Sie Webpack, Rollup oder ein Tool verwenden, das ihre Plug-ins unterstützt (z. B. Vite), können Sie eines der Bundler-Plug-ins (Webpack, Rollup) verwenden, das diese Pakete umschließt, anstatt sie direkt aufzurufen. Dadurch wird ein signiertes Bundle als Ausgabe Ihres Builds generiert.

App testen

Sie haben zwei Möglichkeiten, Ihre IWA zu testen: entweder Sie führen Ihren Entwicklungsserver über den integrierten IWA-Entwicklerproxy von Chrome aus oder Sie installieren Ihre gebündelte IWA. Dazu benötigen Sie Chrome oder ChromeOS 120 oder höher, müssen die IWA-Flags aktivieren und Ihre App über die Web App Internals von Chrome installieren:

chrome://flags/#enable-isolated-web-app-dev-mode-Flag aktivieren
Testen Sie Ihre IWA, indem Sie in Chrome die Seite „Web App Internals“ unter chrome://web-app-internals aufrufen.

Auf der Seite „Web-App-Interna“ haben Sie zwei Möglichkeiten: Install IWA with Dev Mode Proxy oder Install IWA from Signed Web Bundle.

Wenn Sie die Installation über einen Dev Mode Proxy vornehmen, können Sie jede URL, einschließlich Websites, die von einem lokalen Entwicklungsserver ausgeführt werden, als IWA installieren, ohne sie zu bündeln, sofern sie die anderen IWA-Installationsanforderungen erfüllen. Nach der Installation wird Ihrem System eine IWA für diese URL mit den richtigen Sicherheitsrichtlinien und Einschränkungen sowie Zugriff auf APIs hinzugefügt, die nur für IWAs verfügbar sind. Ihr wird eine zufällige Kennung zugewiesen. Die Chrome-Entwicklertools sind in diesem Modus ebenfalls verfügbar, damit Sie Fehler in Ihrer Anwendung beheben können. Wenn Sie die Installation über ein signiertes Web-Bundle vornehmen, laden Sie Ihre signierte, gebündelte IWA hoch. Sie wird dann so installiert, als ob sie von einem Endnutzer heruntergeladen worden wäre.

Auf der Seite „Web App Internals“ können Sie auch Updateprüfungen für alle Anwendungen erzwingen, die über den Dev Mode Proxy oder aus einem signierten Web-Bundle installiert wurden, um den Updateprozess zu testen.

Isoliert

Vertrauen ist der Schlüssel zu isolierten Web-Apps. Das beginnt damit, wie sie ausgeführt werden. Nutzer haben unterschiedliche Vorstellungen davon, was eine App leisten kann und sollte, je nachdem, ob sie in einem Browser oder in einem eigenständigen Fenster ausgeführt wird. Im Allgemeinen gehen sie davon aus, dass eigenständige Apps mehr Zugriff haben und leistungsfähiger sind. Da IWAs Zugriff auf APIs mit hohem Vertrauen erhalten können, müssen sie in einem separaten Fenster ausgeführt werden, um diesem mentalen Modell zu entsprechen. Dadurch werden sie optisch vom Browser getrennt. Aber es geht um mehr als nur die visuelle Trennung.

Isolierte Web-Apps werden über ein separates Protokoll als In-Browser-Websites ausgeführt (isolated-app im Gegensatz zu http oder https). Das bedeutet, dass jede IWA vollständig von In-Browser-Websites getrennt ist, auch wenn sie vom selben Unternehmen entwickelt wurde. Dies ist der Same-Origin-Policy zu verdanken. Auch der IWA-Speicher ist voneinander getrennt. So wird sichergestellt, dass keine ursprungsübergreifenden Inhalte zwischen verschiedenen IWAs oder zwischen IWAs und dem normalen Browserkontext eines Nutzers übertragen werden können.

Weder die Isolation noch das Bündeln und Signieren des Codes einer Website sind jedoch nützlich, um Vertrauen aufzubauen, wenn eine IWA nach der Installation beliebigen Code herunterladen und ausführen kann. Damit das möglich ist und IWAs trotzdem eine Verbindung zu anderen Websites für Inhalte herstellen können, werden strenge Content Security Policies (CSP) erzwungen:

Es ist nur JavaScript aus dem Bundle zulässig. Wasm kann jedoch unabhängig von der Quelle ausgeführt werden. (script-src)
Ermöglicht es JavaScript, Daten von sicheren, nicht lokalen Cross-Origin-Domains abzurufen, WebSocket- und WebTransport-Endpunkte zu verbinden sowie blob- und Daten-URLs (connect-src)
Schutz vor DOM-Cross-Site-Scripting-Angriffen (XSS) durch Regulierung der Verwendung von DOM-Manipulationsfunktionen (require-trusted-types-for)
Erlaubt Frames, Bilder, Audio und Video von jeder HTTPS-Domain (frame-src, img-src, media-src)
Schriftarten aus dem Bundle und Blobs zulassen (font-src)
Inline-CSS oder CSS aus dem Bundle zulassen (style-src)
<object>-, <embed>- und <base>-Elemente können nicht verwendet werden (object-src und base-uri).
Es sind nur Ressourcen aus dem Bundle für alle anderen CSP-abgedeckten Anfragen (default-src) zulässig.

Content-Security-Policy: script-src 'self' 'wasm-unsafe-eval';
  connect-src 'self' https: wss: blob: data:;
  require-trusted-types-for 'script';
  frame-src 'self' https: blob: data:;
  img-src 'self' https: blob: data:;
  media-src 'self' https: blob: data:;
  font-src 'self' blob: data:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
  default-src 'self';

Diese CSPs reichen nicht aus, um vollständig vor potenziell schädlichem Drittanbietercode zu schützen. IWAs sind auch ursprungsübergreifend isoliert. Es werden Header festgelegt, um die Möglichkeit von Drittanbieterressourcen zu verringern, sie zu beeinflussen:

Lassen Sie nur Ressourcen aus dem Bundle oder Cross-Origin-Ressourcen zu, die explizit als CORS-kompatibel gekennzeichnet sind. Dies kann entweder durch einen CORP-Header (Cross-Origin Resource Policy) oder durch das Attribut crossorigin erfolgen. (Cross-Origin-Embedder-Policy)
Cross-Origin-Anfragen ohne CORS nicht zulassen (Cross-Origin-Resource-Policy)
Den Browserkontext von ursprungsübergreifenden Dokumenten prozessisolieren, um window.opener-Referenzen und den Zugriff auf globale Objekte zu verhindern (Cross-Origin-Opener-Policy)
Verhindern, dass die Website in einen Frame oder iFrame eingebettet wird (CSP, frame-ancestors)

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: frame-ancestors 'self'

Auch mit diesen Einschränkungen gibt es noch einen weiteren potenziellen Angriff, vor dem IWAs schützen: Angriffe, die die Reihenfolge der Aktionen ändern. Ein Angriff durch Unterbrechung der Sequenz erfolgt, wenn schädliche Inhalte von Drittanbietern versuchen, eine verwirrende und potenziell ausnutzbare Nutzererfahrung zu schaffen, indem sie auf unerwartete Weise zu einer Seite navigieren, z. B. direkt zu einer internen Einstellungsseite. IWAs verhindern dies, indem sie kein beliebiges Deeplinking von externen Websites zulassen. Anwendungen können nur geöffnet werden, wenn zu genau definierten Einstiegspunkten navigiert wird, z. B. zu einem start_url, einem Protokollhandler, einem Freigabe-Ziel oder über einen Launch-Handler.

Gesperrt

Verpackung und Isolation bieten eine Reihe von Garantien dafür, was ausgeführt werden darf und woher es stammt. Die dynamische Natur von Berechtigungen im Web bedeutet jedoch, dass sie allein nicht sicherstellen können, dass eine Webanwendung nur die Funktionen verwendet, die sie benötigt. Da für verschiedene Funktionen unterschiedliche Sicherheitsaspekte gelten, sollten Nutzer oder Administratoren prüfen, welche Berechtigungen eine IWA verwenden darf. Das ist genauso möglich wie bei anderen nativen Apps wie Android und iOS, bevor sie eine App installieren oder aktualisieren.

Um dies zu ermöglichen, blockieren isolierte Web-Apps standardmäßig alle Berechtigungsanfragen. Entwickler können die benötigte Berechtigung dann aktivieren, indem sie ihrem Web-App-Manifest das Feld permissions_policy hinzufügen. Dieses Feld enthält Schlüssel/Wert-Paare von Berechtigungsrichtlinien-Direktiven und Zulassungslisten für Berechtigungsrichtlinien für jede Berechtigung, die die IWA oder ein untergeordneter Frame wie ein Controlled Frame oder ein iFrame anfordern darf. Wenn Sie hier eine Berechtigung hinzufügen, wird sie nicht automatisch gewährt. Stattdessen wird sie verfügbar, wenn eine Anfrage für diese Funktion gestellt wird.

Angenommen, Sie entwickeln eine IWA zur Flottenverfolgung. Möglicherweise benötigen Sie Ihre IWA, um den Standort des Nutzers abfragen zu können. Das gilt auch für eingebettete Karten. Möglicherweise soll die eingebettete Website auch im Vollbildmodus angezeigt werden können, um dem Nutzer eine immersive Ansicht zu bieten. Dazu richten Sie die folgende Berechtigungsrichtlinie in Ihrem Web-App-Manifest ein:

"permissions_policy": {
   "geolocation": [ "self", "https://map.example.com" ],
   "fullscreen": [ "*" ]
}

Da in WebBundles auch Permissions-Policy-Header angegeben werden können, sind nur Berechtigungen zulässig, die in beiden deklariert sind. Außerdem sind nur Ursprünge in den Zulassungslisten zulässig, die in beiden enthalten sind.

Benannt und versioniert

Normale Web-Apps verwenden ihren Domainnamen, um sich Nutzern zu präsentieren. Sie können aktualisiert werden, indem der Code geändert wird, der in dieser Domain bereitgestellt wird. Aufgrund der Sicherheitsbeschränkungen für isolierte Web-Apps müssen Identität und Updates jedoch anders gehandhabt werden. Ähnlich wie bei progressiven Web-Apps benötigen isolierte Web-Apps eine Web-App-Manifestdatei, um sie für Ihre Nutzer zu identifizieren.

Web-App-Manifest

Isolierte Web-Apps haben dieselben wichtigen Manifest-Eigenschaften für ihr Web-App-Manifest wie PWAs, mit einigen geringfügigen Abweichungen. display funktioniert beispielsweise etwas anders: Sowohl browser als auch minimal-ui werden in einer minimal-ui-Darstellung erzwungen und fullscreen und standalone werden beide in einer standalone-Darstellung erzwungen. Zusätzliche display_override-Optionen funktionieren wie erwartet. Außerdem gibt es zwei weitere Felder, die enthalten sein sollten: version und update_manifest_url:

version: Erforderlich für isolierte Web-Apps. Ein String, der aus einer oder mehreren durch einen Punkt (.) getrennten Ganzzahlen besteht. Ihre Version kann einfach sein, z. B. 1, 2, 3 usw., oder komplex, z. B. SemVer (1.2.3). Die Versionsnummer muss dem regulären Ausdruck ^(\d+.?)*\d$ entsprechen.
update_manifest_url: Optionales, aber empfohlenes Feld, das auf eine HTTPS-URL (oder localhost für Tests) verweist, über die ein Web Application Update Manifest abgerufen werden kann.

Ein minimales Web-App-Manifest für eine isolierte Web-App könnte so aussehen:

{
  "name": "IWA Kitchen Sink",
  "version": "0.1.0",
  "update_manifest_url": "https://example.com/updates.json",
  "start_url": "/",
  "icons": [
    {
      "src": "/images/icon.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "any"
    },
    {
      "src": "/images/icon-mask.png",
      "type": "image/png",
      "sizes": "512x512",
      "purpose": "maskable"
    }
  ]
}

Manifest für Webanwendungsupdates

Ein Webanwendungs-Aktualisierungsmanifest ist eine JSON-Datei, in der jede Version einer bestimmten Webanwendung beschrieben wird. Das JSON-Objekt enthält ein Pflichtfeld, version, das eine Liste von Objekten mit version, src und channels ist:

version: Die Versionsnummer der Anwendung, die mit dem Feld version des Web-App-Manifests übereinstimmt.
src: Die HTTPS-URL (oder localhost für Tests), die auf das gehostete Bundle für diese Version (die .swbn-Datei) verweist. Relative URLs sind relativ zur Manifestdatei für Webanwendungsupdates.
channels: Eine Liste von Strings zur Identifizierung des Update-Channels, zu dem diese Version gehört. Ein spezieller default-Channel wird verwendet, um den primären Channel zu beschreiben, der verwendet wird, wenn kein anderer Channel ausgewählt ist.

Sie können auch das Feld channels einfügen, ein Objekt Ihrer Channel-IDs mit einer optionalen name-Property für jede ID, um einen für Menschen lesbaren Namen anzugeben (auch für den default-Channel). Bei einem Channel, der die Eigenschaft name nicht enthält oder nicht im Objekt channels enthalten ist, wird die ID als Name verwendet.

Ein minimales Aktualisierungsmanifest könnte so aussehen:

{
  "versions": [
    {
      "version": "5.2.17",
      "src": "https://cdn.example.com/app-package-5.2.17.swbn",
      "channels": ["next", "5-lts", "default"]
    },
    {
      "version": "5.3.0",
      "src": "v5.3.0/package.swbn",
      "channels": ["next", "default"]
    },
    {
      "version": "5.3.1",
      "src": "v5.3.1/package.swbn",
      "channels": ["next"]
    },
  ],
  "channels": {
    "default": {
      "name": "Stable"
    },
    "5-lts": {
      "name": "5.x Long-term Stable"
    }
  }
}

In diesem Beispiel gibt es drei Channels: default, der mit Stable gekennzeichnet wird, 5-lts, der mit 5.x Long-term Stable gekennzeichnet wird, und next, der mit next gekennzeichnet wird. Wenn ein Nutzer den Channel 5-lts verwendet, erhält er Version 5.2.17. Wenn er den Channel default verwendet, erhält er Version 5.3.0 und wenn er den Channel next verwendet, erhält er Version 5.3.1.

Update-Manifeste für Webanwendungen können auf jedem Server gehostet werden. Alle 4 bis 6 Stunden wird nach Updates gesucht.

Vom Administrator verwaltet

Bei der ersten Einführung können isolierte Web-Apps nur auf Chrome Enterprise-verwalteten Chromebooks von einem Administrator über das Admin-Panel installiert werden.

Rufen Sie im Admin-Bereich Geräte > Chrome > Apps und Erweiterungen > Nutzer und Browser auf. Auf diesem Tab können Sie Apps und Erweiterungen aus dem Chrome Web Store, Google Play und dem Web für Nutzer in Ihrer gesamten Organisation hinzufügen. Um Elemente hinzuzufügen, öffnen Sie die gelbe schwebende Schaltfläche „Hinzufügen“ (+) rechts unten auf dem Bildschirm und wählen Sie den Typ des hinzuzufügenden Elements aus.

Wenn Sie sie öffnen, sehen Sie ein Symbol mit einem Quadrat in einem Quadrat und der Beschriftung Isolierte Web-App hinzufügen. Wenn Sie darauf klicken, wird ein Modal geöffnet, in dem Sie eine IWA zu Ihrer Organisationseinheit hinzufügen können. Dazu benötigen Sie zwei Informationen: die Web-Bundle-ID der IWA (die aus dem öffentlichen Schlüssel Ihrer App generiert und nach dem Bündeln und Signieren der App angezeigt wird) und die URL zum Web-App-Update-Manifest für die IWA. Nach der Installation stehen Ihnen die Standardoptionen des Admin-Bereichs zur Verwaltung zur Verfügung:

Installationsrichtlinie: Gibt an, wie die IWA installiert werden soll. Sie kann entweder zwangsweise installiert, zwangsweise installiert und im ChromeOS-Ablagefach angepinnt oder die Installation kann verhindert werden.
Beim Anmelden starten: Hier legen Sie fest, wie die IWA gestartet werden soll. Sie können Nutzern erlauben, sie manuell zu starten, die IWA beim Anmelden des Nutzers automatisch starten, aber dem Nutzer erlauben, sie zu schließen, oder die IWA beim Anmelden des Nutzers automatisch starten und verhindern, dass sie geschlossen wird.

Nach dem Speichern wird die App bei der nächsten Richtlinienaktualisierung auf Chromebooks in dieser Organisationseinheit installiert. Nach der Installation sucht das Gerät eines Nutzers alle 4 bis 6 Stunden im Web-App-Aktualisierungsmanifest nach Updates.

Sie können IWAs nicht nur erzwingen, sondern auch einige Berechtigungen automatisch erteilen, ähnlich wie bei anderen Webanwendungen. Klicken Sie dazu auf Geräte > Chrome > Webfunktionen und dann auf die Schaltfläche Ursprung hinzufügen. Fügen Sie in Origin / site pattern field die Web-Bundle-ID der IWA ein. isolated-app:// wird automatisch als Protokoll hinzugefügt. Dort können Sie die Zugriffsebenen für verschiedene APIs festlegen (zulässig/blockiert/nicht festgelegt), darunter die APIs für die Fensterverwaltung, die Verwaltung lokaler Schriftarten und die Bildschirmüberwachung. Für APIs, für die möglicherweise eine zusätzliche Einwilligung eines Administrators erforderlich ist, z. B. die obligatorische API zur Bildschirmüberwachung, wird ein zusätzliches Dialogfeld angezeigt, in dem Sie Ihre Auswahl bestätigen müssen. Wenn Sie fertig sind, speichern Sie Ihre Änderungen. Ihre Nutzer können dann mit der Verwendung Ihrer IWA beginnen.

Mit Erweiterungen arbeiten

Isolierte Web-Apps funktionieren nicht sofort mit Erweiterungen, aber Sie können Erweiterungen, die Ihnen gehören, damit verknüpfen. Dazu müssen Sie die Manifestdatei der Erweiterung bearbeiten. Im externally_connectable-Abschnitt des Manifests wird definiert, mit welchen externen Webseiten oder anderen Chrome-Erweiterungen Ihre Erweiterung interagieren kann. Fügen Sie die Quelle Ihrer IWA im Feld matches in externally_connectable hinzu (achten Sie darauf, das isolated-app://-Schema einzufügen):

{
  "externally_connectable": {
    "matches": ["isolated-app://79990854-bc9f-4319-a6f3-47686e54ed29/*"]
  }
}

Dadurch kann Ihre Erweiterung zwar in der isolierten Web-App ausgeführt werden, aber es ist nicht möglich, Inhalte in sie einzufügen. Sie können nur Nachrichten zwischen der Erweiterung und Ihrer IWA übergeben.