Request for review: ChromeOS Blink Extensions for IWAs

[Edman Anjos]

Hello Blink API Owners,
I'm writing on behalf of the Isolated Web Apps (IWAs) team to request your review of the proposal at:

https://docs.google.com/document/d/1AP9RIE-VIHI5u7oTrYRoXUca1Cq-bWilGYzzDjMLfV4

TL;DR: We have several VDI use cases involving desktop environment integration that only make sense for IWAs in ChromeOS. We propose implementing them as Blink extensions for IWAs in ChromeOS, rather than following the regular Web Platform and blink launch process. Access to these capabilities can be limited to select VDI partners in ChromeOS.

We look forward to your feedback.

Best regards,

Edman Anjos

[Rick Byers]

I haven't had time to dig into all the impl details, but at a high level this makes perfect sense to me and is IMHO the sort of thing blink extensions were designed for. @Chris Harrelson has the most context on that I believe.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAGE49ariKvaBXe%2Bpz8mD2y7h%3DqZdoQjKQ%2BJvqpSzCK_8cceyZg%40mail.gmail.com.

[Dominic Farolino]

Not an API OWNER, but chiming in since I helped review many of the IWA specs. I was skeptical at first, but I think I'm in agreement with Rick and the rationale laid out in the docs, especially given the narrow audience for these APIs, and very targeted partner focus. Thanks for spelling it all out clearly. (I did leave one comment on the linked doc though).

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFUtAY9FcPm%3DQg7G0PEB-P7pc9uC5Nr1s-vkT--ZKXf1j9oTuw%40mail.gmail.com.

[Chris Harrelson]

Using the Blink extensions code approach is fine, but I am not convinced we should allow shipping any new such APIs for IWAs without following the BlInk intent process. There are only 3 small proposed APIs listed in the linked document: chromeos.iwa.setWindowIcon, chromeos.iwa.setWildcardFileHandler and chromeos.iwa.setShape, all of which sound simple enough to specify in the IWA spec?

[Edman Anjos]

Thank you for reviewing the proposal Chris.

I had a meeting with rbyers@ today that greatly clarified how he thinks about this topic, but we have remaining questions that I hope you can help answer.

One of the things we discussed that might be important here is that IWAs are not regular websites. All IWA resources must be pre-bundled and signed, and the bundle must be installed. Currently the only way to install an IWA is for an admin to force install it via enterprise policy in a managed environment; we're working on enabling non-managed installs via users manually downloading and double-clicking the bundle file. Once you launch an IWA, it opens in its own window, likely in standalone display mode (the regular "browser" mode is disallowed). IWAs don't open in a browser tab, you can't type a URL and navigate to it in the same window.

Avoiding the Blink intent process for these IWA APIs was one of our objectives when considering the Blink extension solution, mainly because of the time and effort we've seen this process take in previous web platform features our team has worked on. Our rationale for that is twofold: (1) the APIs have an extremely narrow usage scope, proposed to be allowlisted to 2 partner IWAs in ChromeOS. And (2) there is no audience to the artifacts we'd produce as a result of the Blink process, therefore making it an unnecessary overhead. Can you clarify in what ways you expect the Blink intent process to be valuable?

With this clarification I'm confident we can agree in a plan forward. I further suggest the two plans below (details to be discussed, but here's what I have so far):

Plan A:

* We agree the Blink intent process is not required given these APIs have 2 IWA users in ChromeOS. Doing the Blink process is unnecessary overhead for us and for Blink.

Plan B:

* Once we understand the objectives of the Blink intent process for these APIs more clearly, we can follow it with a focus on those desired outcomes.

* (hypothetically speaking) For example, if the value lies in having an intent to ship for the APIs, then surrounding aspects of the Blink process can be simplified or removed:

    * (points below continue the assumption that an intent to ship is the important artifact of the Blink process for these APIs)

    1. Explainers can be simplified, as in a ~one paragraph document.

    2. Specs can be simplified, as in a ~one paragraph document.

    3. Specs don't need to be reviewed.

    4. Blink security/privacy reviews can defer to the ChromeOS launch reviews (i.e. be a rubber stamp).

    5. Conformance tests are not required, given that the functionality is ChromeOS specific.

    6. Public documentation is not required, given that we're in touch with all users of these APIs.

Please let us know what you think.

[Chris Harrelson]

Hi Edman,

Previous features shipped (examples) for IWAs still went through the Blink process, and so should these. For some, such as Controlled Frame, it was acceptable to have a spec with less rigor than is usually assumed for web platform features, but there was still a spec (reviewed by a spec mentor also), tests, XFN and so on. (For the features you're proposing along the lines of the examples in my previous email, I agree that it's likely not necessary to have other browser signals or a TAG review.)

On Thu, Jan 29, 2026 at 3:05 PM Edman Anjos <edm...@google.com> wrote:

    1. Explainers can be simplified, as in a ~one paragraph document.

If the API is simple and has a simple explanation (which may/probably is the case for the APIs you want to ship), then yes it can be short.

 

    2. Specs can be simplified, as in a ~one paragraph document.

That's very likely not enough to describe how the API works. See other examples I linked to for the approximate level of detail needed. Spec mentors are available to help make it easy to achieve the boilerplate of a "spec draft".

 

    3. Specs don't need to be reviewed.

Just like code, it does need to be reviewed by somebody (doesn't need to be a non-Googler) at a reasonable level of detail.

 

    4. Blink security/privacy reviews can defer to the ChromeOS launch reviews (i.e. be a rubber stamp).

That's up to those teams. Feel free to mention the ChromeOS launch review in your security and privacy filings; likely they will agree with you and just rubber stamp.

 

    5. Conformance tests are not required, given that the functionality is ChromeOS specific.

Tests are required for any feature code in Chromium. I agree they don't necessarily need to be public WPT tests if that is not easy to do.

 

    6. Public documentation is not required, given that we're in touch with all users of these APIs.

Public documentation somewhere like MDN is not a requirement for shipping in Chromium regardless, so I agree with you on this one.

[Swetha Sivaram]

Hi Chris

Thank you for taking the time to review the proposal and for providing detailed feedback on the proposal and subsequent points. I'd like to take a couple of steps back to reiterate the reason why we reached out.

The features and APIs proposed for Seamless App streaming are tightly coupled to the OS as they relate to desktop and windowing management. These features and their implementation details make sense specifically for ChromeOS and are not intended for implementation on other platforms. We propose moving these out of the web platform and exposing them as blink extensions is primarily because we believe exposing these on the web platform offers little use to anyone besides the 2 VDI partners who we are working with. We previously reached out to a 3rd VDI partner, Xtralogic, to check their interest in Seamless apps and they confirmed they do not expect to adopt this feature.

Since the ChromeOS team proposed and pre-reviewed the original blink extension approach in 2024, to remove the tight coupling of ChromeOS-specific APIs with the browser and reduce stringent web API reviews and requirements, we realized this framework could benefit us in this specific scenario.

Could you help us understand the intent behind adopting the web API launch process for non-web ChromeOS only features that are tightly coupled with the OS's dektop and windowing management capabilities? 

Regards

Swetha Sivaram

[Mike Taylor]

On 1/30/26 4:59 a.m., 'Swetha Sivaram' via blink-api-owners-discuss wrote:

Hi Chris

Thank you for taking the time to review the proposal and for providing detailed feedback on the proposal and subsequent points. I'd like to take a couple of steps back to reiterate the reason why we reached out.

The features and APIs proposed for Seamless App streaming are tightly coupled to the OS as they relate to desktop and windowing management. These features and their implementation details make sense specifically for ChromeOS and are not intended for implementation on other platforms. We propose moving these out of the web platform and exposing them as blink extensions is primarily because we believe exposing these on the web platform offers little use to anyone besides the 2 VDI partners who we are working with. We previously reached out to a 3rd VDI partner, Xtralogic, to check their interest in Seamless apps and they confirmed they do not expect to adopt this feature.

Since the ChromeOS team proposed and pre-reviewed the original blink extension approach in 2024, to remove the tight coupling of ChromeOS-specific APIs with the browser and reduce stringent web API reviews and requirements, we realized this framework could benefit us in this specific scenario.

Could you help us understand the intent behind adopting the web API launch process for non-web ChromeOS only features that are tightly coupled with the OS's dektop and windowing management capabilities? 

Here "non-web ChromeOS only features" just means IWA, right? Or are IWAs supported/shipping on other platforms?

It would be helpful to understand the argument in terms of the principles the IWA team laid out in https://www.chromium.org/blink/launching-features/isolated-web-apps/. You're asserting they don't apply specifically because it has to do with OS window management?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFFqJ4%3DLsZ8fGmC0V8GQvd5ZvgyGX%3DJ184t72RjO2yz35-2kYA%40mail.gmail.com.

[Swetha Sivaram]

IWAs exist only on ChromeOS. By "non-web ChromeOS only features" I was referring to the OS window management features that we're proposing to ship as blink extensions, gated by IWA security controls.

Maybe jointly defining a browser's limits on managing and controlling OS features would help in this case. We believe that window management on the OS and desktop control should remain outside the limits of browser capability. Is it fair to say that any capability exposed through the browser must go through the Blink process, and those outside its boundaries should be exempt? This seems to have been the initial aim of the ChromeOS Blink extensions.

The principles you linked to point to IWAs being "safer" web apps with enhanced capabilities and this still applies to the broad set of capabilities we have launched thus far and are still working on more features that will be follow this process like Web Printing API, etc. The "seamless app streaming" use case, lies beyond the boundaries of such web app behavior and hence a more tailored and limited process should reflect the scope within which these capabilities will be offered. 

 

Regards

Swetha Sivaram

[Chris Harrelson]

Hi,

I discussed this thread offline with Swetha and Edman, and I think the APIs in question are simple enough that the "Plan B" Edman proposed is fine. I'll review the proposed spec/explainer and help Edman through the I2S process.

Thanks,

Chris

[Edman Anjos]

Thanks, Chris. I will send CLs your way shortly.

--

Edman Anjos

Software Engineer

edm...@google.com
+49 172 6604231

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.