Izolowane aplikacje internetowe

Internet to naprawdę wyjątkowa platforma aplikacji. Aplikacje oparte na tej platformie są od razu dostępne w każdym systemie operacyjnym bez konieczności wprowadzania zmian w kodzie ani kompilowania. Gdy użytkownik otworzy Twoją aplikację, zawsze będzie miał dostęp do jej najnowszej wersji. Są instalowalne i mogą działać offline, są bardzo funkcjonalne i łatwe do udostępniania za pomocą linku. Twórz aplikacje internetowe, które działają wszędzie.

Internet ma być bezpieczny i chroniony domyślnie, dlatego jego model bezpieczeństwa musi być bardzo konserwatywny. Wszystkie nowe funkcje muszą być bezpieczne dla zwykłego użytkownika, który może przypadkowo natrafić na nie za pomocą adresu URL. Ten model zabezpieczeń nazywamy przeglądaniem stron internetowych. Chociaż jest to świetne rozwiązanie w przypadku wielu aplikacji i można je dodatkowo zabezpieczyć za pomocą zasad bezpieczeństwa treści i izolacji między źródłami, nie sprawdza się ono w każdym przypadku. Wiele bardzo ważnych i zaawansowanych interfejsów API, takich jak Direct Sockets i Controlled Frame, których potrzebują programiści, nie można wystarczająco zabezpieczyć, aby można było ich używać w internecie.

W przypadku tych aplikacji nie ma obecnie możliwości tworzenia ich w internecie. Dla innych model zabezpieczeń internetowych może być niewystarczający. Mogą oni nie zakładać, że serwer jest godny zaufania, i zamiast tego preferować dyskretnie wersjonowane i podpisane aplikacje autonomiczne. Potrzebny jest nowy model zabezpieczeń o wysokim poziomie zaufania. Izolowane aplikacje internetowe (IWA) to odizolowany, spakowany, wersjonowany, podpisany i zaufany model aplikacji oparty na istniejącej platformie internetowej, który umożliwia programistom tworzenie takich aplikacji.

Spektrum zaufania w internecie

Bezpieczeństwo i możliwości w internecie można przedstawić w postaci spektrum.

Witryna internetowa typu drive-by po lewej stronie ma najniższy poziom zaufania w modelu zabezpieczeń, ponieważ musi być najbardziej dostępna, a tym samym ma najmniejszy dostęp do systemu użytkownika. Aplikacje internetowe instalowane w przeglądarce mają nieco większe zaufanie i mogą być bardziej zintegrowane z systemem użytkownika. Użytkownicy mogą zwykle bez problemu przełączać się między wersjami aplikacji uruchamianymi w przeglądarce a wersjami zainstalowanymi w przeglądarce.

Następnie są izolowane aplikacje internetowe o wysokim poziomie zaufania.

Działają i wyglądają bardziej jak aplikacje natywne, a także mają dostęp do głębokiej integracji z systemem i zaawansowanych funkcji. Użytkownicy nie mogą przełączać się między nimi a atakiem drive-by-web. Jeśli potrzebujesz takiego poziomu zabezpieczeń lub takich możliwości, nie będzie można cofnąć tej zmiany.

Decydując, do którego miejsca na tym spektrum chcesz dążyć, wybierz model bezpieczeństwa o najniższym poziomie zaufania, np. progresywną aplikację internetową. Zapewni Ci to największy zasięg, będzie wymagać od Ciebie zarządzania najmniejszą liczbą problemów związanych z bezpieczeństwem i będzie najbardziej elastyczne dla Twoich deweloperów i użytkowników.

Bezpieczeństwo przede wszystkim

Izolowane aplikacje internetowe zapewniają model zabezpieczeń o wysokim poziomie zaufania w przypadku aplikacji internetowych. Aby to umożliwić, należy jednak przemyśleć niektóre założenia, które funkcja „drive by web” przyjmuje w odniesieniu do zaufania. Podstawowe elementy składowe internetu, takie jak serwery i DNS, nie mogą już być traktowane jako w pełni zaufane. Nagle ważne stają się wektory ataku, które mogą wydawać się bardziej istotne w przypadku aplikacji natywnych. Aby uzyskać dostęp do nowego modelu zabezpieczeń o wysokim poziomie zaufania, który zapewniają izolowane aplikacje internetowe, aplikacje internetowe muszą być spakowane, odizolowane i zabezpieczone.

Zapakowane

Strony i zasoby izolowanych aplikacji internetowych nie mogą być udostępniane z serwerów na żywo ani pobierane przez sieć jak w przypadku zwykłych aplikacji internetowych. Aby uzyskać dostęp do nowego modelu zabezpieczeń o wysokim poziomie zaufania, aplikacje internetowe muszą spakować wszystkie zasoby potrzebne do działania w podpisany pakiet internetowy. Podpisane pakiety internetowe zawierają wszystkie zasoby potrzebne do działania witryny, które są spakowane w .swbn i połączone z blokiem integralności. Dzięki temu aplikację internetową można bezpiecznie pobrać w całości, a nawet udostępnić lub zainstalować w trybie offline.

Stanowi to jednak problem w przypadku weryfikacji autentyczności kodu witryny: klucze TLS wymagają połączenia z internetem. Zamiast kluczy TLS są one podpisywane kluczem, który można bezpiecznie przechowywać offline. Dobra wiadomość jest taka, że jeśli zgromadzisz wszystkie pliki produkcyjne w jednym folderze, możesz przekształcić go w IWA bez większych modyfikacji.

Generowanie kluczy podpisywania

Klucze podpisywania to pary kluczy Ed25519 lub ECDSA P-256, przy czym klucz prywatny służy do podpisywania pakietu, a klucz publiczny do jego weryfikacji. Klucz Ed25519 lub ECDSA P-256 możesz wygenerować i zaszyfrować za pomocą OpenSSL:

# 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

Klucze podpisywania mają też drugie zastosowanie. Domena może być podatna na utratę kontroli, podobnie jak serwer, dlatego nie można jej używać do identyfikowania zainstalowanej aplikacji internetowej. Zamiast tego aplikacja IWA jest identyfikowana przez klucz publiczny pakietu, który jest częścią jego podpisu i jest powiązany z kluczem prywatnym. To znacząca zmiana w sposobie działania ataków typu drive-by. Zamiast HTTPS interaktywne aplikacje internetowe używają też nowego schematu: isolated-app://.

Pakowanie aplikacji

Gdy masz już klucz podpisywania, możesz utworzyć pakiet aplikacji internetowej. W tym celu możesz użyć oficjalnych pakietów NodeJS, aby utworzyć pakiet, a następnie podpisać aplikacje IWA (dostępne są też narzędzia wiersza poleceń Go). Najpierw użyj pakietu wbn, wskazując folder zawierający wszystkie pliki produkcyjne IWA (w tym przypadku dist), aby spakować je w niepodpisany pakiet:

npx wbn --dir dist

Spowoduje to wygenerowanie niepodpisanego pakietu internetowego tego katalogu w out.wbn.. Po wygenerowaniu użyj zaszyfrowanego klucza Ed25519 lub ECDSA P-256 utworzonego wcześniej do podpisania go za pomocą polecenia wbn-sign:

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

Spowoduje to wygenerowanie podpisanego pakietu internetowego z niepodpisanego pakietu internetowego o nazwie signed.swbn. Po podpisaniu narzędzie wygeneruje też identyfikator pakietu internetowego i źródło izolowanej aplikacji internetowej. Pochodzenie izolowanej aplikacji internetowej to sposób, w jaki jest ona identyfikowana w przeglądarce.

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

Jeśli używasz Webpacka, Rollupa lub narzędzia obsługującego ich wtyczki (np. Vite), możesz użyć jednej z wtyczek do tworzenia pakietów (Webpack, Rollup), która opakowuje te pakiety, zamiast wywoływać je bezpośrednio. Spowoduje to wygenerowanie podpisanego pakietu jako wyniku kompilacji.

Testowanie aplikacji

Izolowaną aplikację internetową możesz przetestować na 2 sposoby: uruchamiając serwer deweloperski za pomocą wbudowanego w Chrome serwera proxy dla deweloperów izolowanych aplikacji internetowych lub instalując spakowaną izolowaną aplikację internetową. Aby to zrobić, musisz mieć Chrome lub ChromeOS w wersji 120 lub nowszej, włączyć flagi IWA i zainstalować aplikację za pomocą narzędzia wewnętrznego aplikacji internetowych w Chrome:

Włącz flagę chrome://flags/#enable-isolated-web-app-dev-mode
Aby przetestować IWA, otwórz stronę wewnętrzną aplikacji internetowej w Chrome:chrome://web-app-internals

Na stronie Wewnętrzne działanie aplikacji internetowej masz 2 możliwości: Install IWA with Dev Mode Proxy lub Install IWA from Signed Web Bundle.

Jeśli instalujesz aplikację za pomocą serwera proxy w trybie deweloperskim, możesz zainstalować dowolny adres URL, w tym witryny działające na lokalnym serwerze deweloperskim, jako IWA bez ich łączenia, pod warunkiem że spełniają one inne wymagania dotyczące instalacji IWA. Po zainstalowaniu w systemie zostanie dodana IWA dla tego adresu URL z odpowiednimi zasadami bezpieczeństwa i ograniczeniami oraz dostępem do interfejsów API tylko dla IWA. Zostanie mu przypisany losowy identyfikator. W tym trybie dostępne są też Narzędzia deweloperskie w Chrome, które pomagają debugować aplikację. Jeśli instalujesz z podpisanego pakietu internetowego, przesyłasz podpisany, spakowany IWA, który zostanie zainstalowany tak, jakby został pobrany przez użytkownika.

Na stronie Wewnętrzne działanie aplikacji internetowej możesz też wymusić sprawdzanie aktualizacji w przypadku wszystkich aplikacji zainstalowanych za pomocą serwera proxy trybu deweloperskiego lub z podpisanego pakietu internetowego, aby przetestować proces aktualizacji.

Odizolowany

Zaufanie jest kluczowe w przypadku izolowanych aplikacji internetowych. Zaczyna się od tego, jak działają. Użytkownicy mają różne wyobrażenia o tym, co aplikacja może i powinna robić, w zależności od tego, czy jest uruchomiona w przeglądarce, czy w samodzielnym oknie. Zazwyczaj uważają, że samodzielne aplikacje mają większy dostęp i są bardziej wydajne. Ponieważ aplikacje IWA mogą uzyskiwać dostęp do interfejsów API o wysokim poziomie zaufania, muszą działać w samodzielnym oknie, aby zachować zgodność z tym modelem. W ten sposób wizualnie oddzielisz je od przeglądarki. To jednak coś więcej niż tylko wizualne rozdzielenie.

Izolowane aplikacje internetowe działają w innym protokole niż witryny w przeglądarce (isolated-app w porównaniu z http lub https). Oznacza to, że każda izolowana aplikacja internetowa jest całkowicie oddzielona od witryn działających w przeglądarce, nawet jeśli zostały utworzone przez tę samą firmę. Jest to możliwe dzięki zasadzie dotyczącej tego samego pochodzenia. Pamięć IWA jest też od siebie odseparowana. Dzięki temu treści z różnych domen nie mogą wyciekać między różnymi aplikacjami IWA ani między aplikacjami IWA a normalnym kontekstem przeglądania użytkownika.

Jednak ani izolacja, ani pakowanie i podpisywanie kodu witryny nie są przydatne do budowania zaufania, jeśli zainstalowana IWA może pobierać i uruchamiać dowolny kod. Aby to zapewnić, a jednocześnie umożliwić IWAs łączenie się z innymi witrynami w celu uzyskania treści, IWAs egzekwują rygorystyczny zestaw zasad bezpieczeństwa treści:

Zezwala tylko na JavaScript z pakietu, ale umożliwia uruchamianie kodu Wasm niezależnie od jego źródła. (script-src)
Zezwala JavaScriptowi na pobieranie danych z bezpiecznych domen innych niż localhost, łączenie się z punktami końcowymi WebSocket i WebTransport oraz adresami URL blob i data (connect-src).
Chroni przed atakami polegającymi na wstrzykiwaniu skryptów między witrynami (XSS) do modelu DOM, regulując sposób używania funkcji manipulacji DOM (require-trusted-types-for).
Zezwala na ramki, obrazy, dźwięk i wideo z dowolnej domeny HTTPS (frame-src, img-src, media-src)
Umożliwia korzystanie z czcionek z pakietu i obiektów blob.font-src
Zezwalaj na wbudowany kod CSS lub kod CSS z pakietu.style-src
Elementów <object>, <embed> i <base> nie można używać (object-src i base-uri).
Zezwala tylko na zasoby z pakietu w przypadku innych żądań objętych zasadami CSP (default-src).

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';

Te zasady CSP nie wystarczą, aby w pełni chronić przed potencjalnie złośliwym kodem pochodzącym od firm zewnętrznych. IWAs są też izolowane od innych domen, a nagłówki są ustawione tak, aby ograniczyć wpływ zasobów innych firm:

Zezwalaj tylko na zasoby z pakietu lub zasoby z innych domen, które są wyraźnie oznaczone jako obsługujące CORS za pomocą ustawionego nagłówka zasady dotyczącej zasobów z innych domen (CORP) lub atrybutu crossorigin. (Cross-Origin-Embedder-Policy)
Blokowanie żądań z różnych domen bez CORSCross-Origin-Resource-Policy
Izolowanie kontekstu przeglądania od dokumentów z innych domen, co uniemożliwia odwoływanie się do window.opener i dostęp do obiektów globalnych (Cross-Origin-Opener-Policy).
Zapobieganie osadzaniu witryny w ramce lub elemencie iframe (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'

Nawet przy tych ograniczeniach istnieje jeszcze jeden potencjalny atak, przed którym chronią IWAs: ataki polegające na przerwaniu sekwencji. Atak polegający na przerwaniu sekwencji występuje, gdy złośliwe treści pochodzące od innej firmy próbują stworzyć dla użytkownika mylące i potencjalnie podatne na wykorzystanie środowisko, przechodząc do strony w nieoczekiwany sposób, np. bezpośrednio do wewnętrznej strony ustawień. IWAs zapobiegają temu, uniemożliwiając dowolne linkowanie bezpośrednie z witryn zewnętrznych i zezwalając na otwieranie aplikacji tylko przez przechodzenie do dobrze zdefiniowanych punktów wejścia, takich jak start_url, obsługa protokołu, miejsce docelowe udostępniania lub obsługa uruchamiania.

Zablokowany

Pakowanie i izolacja zapewniają pewne gwarancje dotyczące tego, co może być uruchamiane i skąd pochodzi, ale dynamiczny charakter uprawnień w internecie oznacza, że same w sobie nie mogą zagwarantować, że aplikacja internetowa korzysta tylko z potrzebnych jej funkcji. Różne funkcje mają różne aspekty związane z bezpieczeństwem, dlatego użytkownik lub administrator może chcieć sprawdzić, z jakich uprawnień może korzystać zainstalowana aplikacja internetowa, tak jak w przypadku innych aplikacji natywnych, np. na Androida i iOS, przed zainstalowaniem lub zaktualizowaniem aplikacji.

Aby to ułatwić, izolowane aplikacje internetowe domyślnie blokują wszystkie żądania uprawnień. Deweloperzy mogą następnie włączyć potrzebne uprawnienia, dodając pole permissions_policy do pliku manifestu aplikacji internetowej. To pole zawiera pary klucz/wartość dyrektyw zasad uprawnień i list dozwolonych zasad uprawnień dla każdego uprawnienia, o które może poprosić IWA lub dowolna ramka podrzędna, np. ramka kontrolowana lub ramka iframe. Dodanie tutaj uprawnienia nie powoduje jego automatycznego przyznania. Zamiast tego sprawia, że jest ono dostępne do żądania, gdy zostanie wysłana prośba o daną funkcję.

Załóżmy, że tworzysz IWA do śledzenia floty. Aby móc poprosić użytkownika o podanie lokalizacji, musisz mieć IWA. Osadzona mapa również musi mieć możliwość wysyłania takich próśb. Możesz też chcieć, aby każda osadzona witryna mogła przejść w tryb pełnoekranowy, aby zapewnić użytkownikowi wciągający widok. Aby to zrobić, w manifeście aplikacji internetowej skonfiguruj te zasady dotyczące uprawnień:

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

Ponieważ pakiety internetowe mogą też określać nagłówki Permissions-Policy, dozwolone będą tylko uprawnienia zadeklarowane w obu tych miejscach, a następnie tylko źródła z list dozwolonych, które znajdują się w obu tych miejscach.

Nazwane i wersjonowane

Zwykłe aplikacje internetowe polegają na nazwie domeny, aby identyfikować się przed użytkownikami. Można je aktualizować, zmieniając kod, który jest udostępniany w tej domenie. Ze względu na ograniczenia bezpieczeństwa związane z izolowanymi aplikacjami internetowymi tożsamość i aktualizacje muszą być obsługiwane w inny sposób. Podobnie jak w przypadku progresywnych aplikacji internetowych, izolowane aplikacje internetowe wymagają pliku manifestu aplikacji internetowej, aby identyfikować je przed użytkownikami.

Manifest aplikacji internetowej

Izolowane aplikacje internetowe mają takie same kluczowe właściwości pliku manifestu jak progresywne aplikacje internetowe, ale z kilkoma niewielkimi różnicami. Na przykład display działa nieco inaczej: zarówno browser, jak i minimal-ui są wyświetlane jako minimal-ui, a fullscreen i standalone są wyświetlane jako standalone (dodatkowe opcje display_override działają zgodnie z oczekiwaniami). Dodatkowo należy uwzględnić jeszcze 2 pola: version i update_manifest_url:

version: Wymagany w przypadku izolowanych aplikacji internetowych. Ciąg znaków składający się z co najmniej jednej liczby całkowitej oddzielonej kropką (.). Wersja może być prosta, np. 1, 2, 3 itd., lub złożona, np. SemVer (1.2.3). Numer wersji powinien być zgodny z wyrażeniem regularnym ^(\d+.?)*\d$.
update_manifest_url: Opcjonalne, ale zalecane pole, które wskazuje adres URL HTTPS (lub localhost na potrzeby testowania), z którego można pobrać plik manifestu aktualizacji aplikacji internetowej.

Minimalny plik manifestu aplikacji internetowej dla izolowanej aplikacji internetowej może wyglądać tak:

{
  "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"
    }
  ]
}

Plik manifestu aktualizacji aplikacji internetowej

Plik manifestu aktualizacji aplikacji internetowej to plik JSON, który opisuje każdą wersję danej aplikacji internetowej. Obiekt JSON zawiera 1 pole wymagane, version, które jest listą obiektów zawierających version, src i channels:

version – numer wersji aplikacji, taki sam jak w polu version pliku manifestu aplikacji internetowej.
src – adres URL HTTPS (lub localhost w przypadku testowania) wskazujący hostowany pakiet dla tej wersji (plik .swbn). Adresy URL względne są względne względem pliku manifestu aktualizacji aplikacji internetowej.
channels – lista ciągów znaków identyfikujących kanał aktualizacji, do którego należy ta wersja. Specjalny kanał default służy do opisywania głównego kanału, który będzie używany, jeśli nie zostanie wybrany żaden inny kanał.

Możesz też dodać pole channels, czyli obiekt identyfikatorów kanałów z opcjonalną właściwością name dla każdego identyfikatora, aby podać nazwę czytelną dla człowieka (w tym dla kanału default). Kanał, który nie zawiera właściwości name lub nie jest uwzględniony w obiekcie channels, używa swojego identyfikatora jako nazwy.

Minimalny manifest aktualizacji może wyglądać tak:

{
  "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"
    }
  }
}

W tym przykładzie są 3 kanały: default, który zostanie oznaczony etykietą Stable, 5-lts, który zostanie oznaczony etykietą 5.x Long-term Stable, i next, który zostanie oznaczony etykietą next. Jeśli użytkownik korzysta z kanału 5-lts, otrzyma wersję 5.2.17, jeśli korzysta z kanału default, otrzyma wersję 5.3.0, a jeśli korzysta z kanału next, otrzyma wersję 5.3.1.

Pliki manifestu aktualizacji aplikacji internetowych mogą być hostowane na dowolnym serwerze. Aktualizacje są sprawdzane co 4–6 godzin.

Zarządzane przez administratora

Na początku izolowane aplikacje internetowe będzie można instalować tylko na Chromebookach zarządzanych przez Chrome Enterprise. Będzie to możliwe dla administratorów za pomocą panelu administracyjnego.

Aby rozpocząć, w panelu administracyjnym kliknij Urządzenia > Chrome > Aplikacje i rozszerzenia > Użytkownicy i przeglądarki. Na tej karcie możesz dodawać aplikacje i rozszerzenia z Chrome Web Store, Google Play i internetu dla użytkowników w całej organizacji. Aby dodać elementy, otwórz żółty pływający przycisk dodawania + w prawym dolnym rogu ekranu i wybierz typ elementu, który chcesz dodać.

Po otwarciu pojawi się ikona kwadratu w kwadracie z etykietą Dodaj izolowaną aplikację internetową. Kliknięcie jej spowoduje otwarcie okna modalnego, w którym możesz dodać izolowaną aplikację internetową do jednostki organizacyjnej. Aby to zrobić, potrzebujesz 2 informacji: identyfikatora pakietu internetowego izolowanej aplikacji internetowej (generowanego na podstawie klucza publicznego aplikacji i wyświetlanego po spakowaniu i podpisaniu aplikacji) oraz adresu URL pliku manifestu aktualizacji aplikacji internetowej dla izolowanej aplikacji internetowej. Po zainstalowaniu będziesz mieć standardowy zestaw opcji panelu administracyjnego do zarządzania nim:

Zasady instalacji: sposób instalacji IWA – wymuszona instalacja, wymuszona instalacja i przypięcie do półki ChromeOS lub uniemożliwienie instalacji.
Uruchamianie po zalogowaniu: sposób uruchamiania IWA. Możesz zezwolić użytkownikowi na ręczne uruchamianie, wymusić uruchamianie IWA po zalogowaniu użytkownika, ale zezwolić na zamknięcie, lub wymusić uruchamianie po zalogowaniu użytkownika i uniemożliwić zamknięcie.

Po zapisaniu aplikacja zostanie zainstalowana przy następnym zastosowaniu aktualizacji zasad na Chromebookach w tej jednostce organizacyjnej. Po zainstalowaniu urządzenie użytkownika będzie sprawdzać dostępność aktualizacji z pliku manifestu aktualizacji aplikacji internetowej co 4–6 godzin.

Oprócz wymuszania instalacji IWA możesz też automatycznie przyznawać im niektóre uprawnienia w podobny sposób jak w przypadku innych aplikacji internetowych. Aby to zrobić, kliknij Urządzenia > Chrome > Funkcje internetowe i przycisk Dodaj pochodzenie. W Origin / site pattern field wklej identyfikator pakietu internetowego aplikacji IWA (isolated-app:// zostanie automatycznie dodany jako protokół). Możesz tam ustawić poziomy dostępu do różnych interfejsów API (dozwolony, zablokowany, nieustawiony), w tym do zarządzania oknami, zarządzania lokalnymi czcionkami i interfejsu monitorowania ekranu. W przypadku interfejsów API, które mogą wymagać dodatkowej zgody administratora na włączenie, np. obowiązkowego interfejsu API monitorowania ekranu, pojawi się dodatkowe okno dialogowe z prośbą o potwierdzenie wyboru. Gdy skończysz, zapisz zmiany i użytkownicy będą mogli zacząć korzystać z Twojej IWA.

Praca z rozszerzeniami

Izolowane aplikacje internetowe nie działają z rozszerzeniami od razu po zainstalowaniu, ale możesz połączyć z nimi rozszerzenia, których jesteś właścicielem. Aby to zrobić, musisz edytować plik manifestu rozszerzenia. Sekcja externally_connectable w pliku manifestu określa, z którymi zewnętrznymi stronami internetowymi lub innymi rozszerzeniami do Chrome może wchodzić w interakcje Twoje rozszerzenie. Dodaj źródło IWA w polu matches w sekcji externally_connectable (pamiętaj, aby uwzględnić schemat isolated-app://):

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

Umożliwi to uruchomienie rozszerzenia w izolowanej aplikacji internetowej, ale nie pozwoli na wstrzykiwanie do niej treści. Możesz tylko przekazywać wiadomości między rozszerzeniem a izolowaną aplikacją internetową.