This document provides essential information regarding the Isolated Web App (IWA) allowlist, including what it is, why it's necessary, the requirements for developers, and the allowlisting process.
What is the IWA allowlist?
The IWA allowlist is a mechanism that controls which Isolated Web Apps can be installed and updated on user devices. From Chrome 143 on ChromeOS only applications present on this allowlist will be installable or updatable through the Admin Panel. This restriction applies to other operating systems starting from their initial support for Isolated Web Apps. To learn how to add an app to the allowlist read the rest of this document.
How does the allowlist affect app installation and use?
From Chrome 143, you can expect the following behavior.
Apps on the allowlist
Apps on the allowlist remain fully functional, allowing for installation, updates, and continued use without impact from the feature launch.
Existing app installations not on the allowlist
Existing app installations will remain installed and can continue to be launched, but they will no longer receive updates after the allowlist rollout. If an app is later added to the allowlist, both existing installations and new instances will follow the behavior described in Apps on the allowlist.
Apps not installed and not on the allowlist
Apps not in the allowlist cannot be installed through the Admin Panel by policy,
but can be installed and tested in Developer Mode using
chrome://web-app-internals. This requires enabling the Chrome flag:
chrome://flags#enable-isolated-web-app-dev-mode.
Additional considerations
- Adding an application to the allowlist automatically approves all its versions.
- The allowlist impacts the following underlying policies:
- For managed user and managed guest sessions: IsolatedWebAppInstallForceList
- For Kiosk: DeviceLocalAccounts
Why is the allowlist needed?
The allowlist has three primary goals.
- Ensure stability and quality: IWA is currently restricted to a small audience of developers because it is in an early product state. Google is working with a select group of developers to ensure the product meets a high stability and quality bar before wider release. The allowlist will make sure that the IWA only comes from these developers.
- Establish trusted contact channels: Create a direct communication line with developers, which is crucial for processes like key rotation.
- Adherence to terms and conditions: Ensure developers comprehend and adhere to Google's acceptable usage terms for deploying Isolated Web App (IWA) applications through Chrome browser.
Developer requirements
To add your Isolated Web App to the allowlist, you should establish contact with Google through your known Google partner contact. Provide them with specific information about the application, adhere to IWA security principles, and accept the acceptable use policy.
If you don't have a Google partner contact, it's likely that you are not part of the early IWA program.
Criteria for allowlisting
The core prerequisite for requesting allowlisting of an app is that the developer's use case must not be achievable through existing open web solutions, including open web APIs and browser extensions. Additionally, the currently launched Isolated Web App (IWA) APIs must adequately meet their requirements and the developer must be part of the IWA early adopter program.
Allowlisting process
The process for allowlisting an IWA involves the following steps:
| Step | Action | Details | Responsible |
|---|---|---|---|
| 1 | Request allowlisting | Developer/partner reaches out to their Google contact (Partner Engineering or other point of contact). | Developer / Partner |
| 2 | Response to requestor | Google contact provides instructions to the requestor, including a link to the request form and any additional instructions by email. | Google Contact |
| 3 | Provide data | Developer/partner registers IWA using the provided form. Google contact can be consulted for assistance. | Developer / Partner |
| 4 | Request processing and providing feedback |
Google reviews the allowlisting request and responds within two business weeks, either approving or denying it, or contacting the developer with further questions. Upon approval, the bundle ID is added to the allowlist, and the partner is informed of the date the change becomes effective. | Google Contact |
Key rotation
The allowlisting process is integral to establishing trusted contact channels with partners, which simplifies key rotation. Key rotation is a mechanism that allows private keys used to sign applications to be replaced in case of leak or loss while maintaining a stable bundle ID. This trusted connection established during the allowlisting phase is essential for enabling seamless key rotation.