IWA-specific feature launch process

[Reilly Grant]

Blink API owners,

As most of you are hopefully aware, we have been working on a project called Isolated Web Apps, an extension to the web platform which uses signed packages as a way to provide greater trust in the integrity of web applications. One of the benefits of this work is that it provides an environment in which more dangerous APIs can be provided to developers. This is similar to Chrome Apps however we want to avoid forking the web platform the way that Chrome Apps did, leading to a platform that stagnated while the web moved forward.

While we've sought feedback from the TAG and other browser vendors for now Chrome is going to be the only browser that supports these apps. Because of this, I've created a guide for developers working on features which will be restricted to Isolated Web Apps explaining how to approach the Blink launch process and additional artifacts they should collect. This is also important because the IWA project team (CCed here) wants to maintain some control over the set of features that are launched this way.

You can see a preview of the new documentation here: https://chromium-website--cl5125864-ps1-ylzjru93.web.app/blink/launching-features/isolated-web-apps/

And comment on the changelist here: https://chromium-review.googlesource.com/c/website/+/5125864

I don't know if you all have an existing process for approving this kind of process change/addition. Maybe the traditional 3xLGTMs are appropriate and then +Mike Taylor or +Chris Harrelson can CR+1 the website update.

Happy holidays.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Chris Harrelson]

Hi Reilly,

The documentation and plan integration into the API owners process makes sense to me. Thanks in particular for the quality and clarity of the documentation.

I'll ask the other API owners at the meeting tomorrow if there are any concerns.

[Vladimir Levin]

For IWA features, is it worthwhile for the intent process to also include a brief justification for why the feature is limited to IWA? The table in the docs may be a good starting point: which of these categories applies and why. I'm not sure if it's always evident why this may be the case for features

Thanks,

Vlad

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZu%2B74s9a%2B27yGZ-EGHCOnM0uvD9W76bSkGDztYkME6g9w%40mail.gmail.com.

[Chris Harrelson]

On Wed, Dec 20, 2023 at 8:26 AM Vladimir Levin <vmp...@chromium.org> wrote:

For IWA features, is it worthwhile for the intent process to also include a brief justification for why the feature is limited to IWA? The table in the docs may be a good starting point: which of these categories applies and why. I'm not sure if it's always evident why this may be the case for features

+1, this is a great suggestion and important to add.

[Mike Taylor]

In general, LGTM, including Vlad's suggestion.

The one bit which is slightly ambiguous to me follows:

> Depending on the outcome of those requests requesting feedback on particular IWA-specific APIs from other browser vendors and/or the TAG may or may not be productive.

It sounds like the guidance is "it depends for now", but may change to "not useful, the other vendors and/or TAG are opposed". How should API OWNERs evaluate that until official positions have been given? Should we ask folks to explain why they haven't requested a position/review until we have more concrete guidance?

[Reilly Grant]

Updated preview with vmpstr@'s comment addressed: https://chromium-website--cl5125864-ps2-e47rfvox.web.app/blink/launching-features/isolated-web-apps/

On Wed, Dec 20, 2023 at 10:32 AM Mike Taylor <mike...@chromium.org> wrote:

In general, LGTM, including Vlad's suggestion.

The one bit which is slightly ambiguous to me follows:

> Depending on the outcome of those requests requesting feedback on particular IWA-specific APIs from other browser vendors and/or the TAG may or may not be productive.

It sounds like the guidance is "it depends for now", but may change to "not useful, the other vendors and/or TAG are opposed". How should API OWNERs evaluate that until official positions have been given? Should we ask folks to explain why they haven't requested a position/review until we have more concrete guidance?

My main interest is avoiding both aggravating other implementers with requests they feel are a waste of their time and forcing Chromium contributors to ask for feedback we know will be negative. In the case of extensions to APIs with existing negative positions we already allow simply referencing the old position rather than filing a new one unless we think the change might change that position. This case is slightly different because we currently have no position, but we also know that the reasons why an API would be restricted to IWAs mean the position would be negative if it were considered a normal web platform feature. Therefore, unless there is a position on the concept of IWAs in general, I don't think any of these reviewers are ready to consider any of these dependent launches.

A compromise could be that rather than filing individual requests we could ask feature owners to comment on the existing requests with a pointer to their explainer to provide whoever eventually reviews these requests with more context on how the IWA infrastructure will be used. The template could be something like, "Reviewer, [link to explainer] is proposed as an IWA-specific feature. Unless you request we file a separate request for this feature now, we will wait until this request is resolved."

Otherwise we could continue to ask feature owners to ask for reviews but provide guidance to link directly to the outstanding requests to make sure reviewers don't miss the context that this is an IWA-specific feature.

On 12/20/23 12:17 PM, Chris Harrelson wrote:

On Wed, Dec 20, 2023 at 8:26 AM Vladimir Levin <vmp...@chromium.org> wrote:

For IWA features, is it worthwhile for the intent process to also include a brief justification for why the feature is limited to IWA? The table in the docs may be a good starting point: which of these categories applies and why. I'm not sure if it's always evident why this may be the case for features

+1, this is a great suggestion and important to add.

 In "Step 1" I ask for this justification to be put into the explainer, but I'll add something to "Step 6" about summarizing this in the "Intent to Ship" email as well.

[Mike Taylor]

On 12/20/23 5:45 PM, Reilly Grant wrote:

Updated preview with vmpstr@'s comment addressed: https://chromium-website--cl5125864-ps2-e47rfvox.web.app/blink/launching-features/isolated-web-apps/

Cool, thanks! In the interest of not blocking you forever, if there are no further objections on list I'll +1 your CL at some point tomorrow (maybe you want to update the patch based on our convo below...). In case there is late feedback from other owners who might be OOO, we can always discuss and modify the docs after the fact.

On Wed, Dec 20, 2023 at 10:32 AM Mike Taylor <mike...@chromium.org> wrote:

In general, LGTM, including Vlad's suggestion.

The one bit which is slightly ambiguous to me follows:

> Depending on the outcome of those requests requesting feedback on particular IWA-specific APIs from other browser vendors and/or the TAG may or may not be productive.

It sounds like the guidance is "it depends for now", but may change to "not useful, the other vendors and/or TAG are opposed". How should API OWNERs evaluate that until official positions have been given? Should we ask folks to explain why they haven't requested a position/review until we have more concrete guidance?

My main interest is avoiding both aggravating other implementers with requests they feel are a waste of their time and forcing Chromium contributors to ask for feedback we know will be negative. In the case of extensions to APIs with existing negative positions we already allow simply referencing the old position rather than filing a new one unless we think the change might change that position. This case is slightly different because we currently have no position, but we also know that the reasons why an API would be restricted to IWAs mean the position would be negative if it were considered a normal web platform feature. Therefore, unless there is a position on the concept of IWAs in general, I don't think any of these reviewers are ready to consider any of these dependent launches.

A compromise could be that rather than filing individual requests we could ask feature owners to comment on the existing requests with a pointer to their explainer to provide whoever eventually reviews these requests with more context on how the IWA infrastructure will be used. The template could be something like, "Reviewer, [link to explainer] is proposed as an IWA-specific feature. Unless you request we file a separate request for this feature now, we will wait until this request is resolved."

Otherwise we could continue to ask feature owners to ask for reviews but provide guidance to link directly to the outstanding requests to make sure reviewers don't miss the context that this is an IWA-specific feature.

I'm fine with this last one, or the compromise option. I don't have any concerns (and share you desire to minimize churn on requesting positions), just hope to make it more clear what feature owners should be doing in this interim state.

[Alex Russell]

I'm not entirely convinced that we win much by not requesting positions here. It's valuable to the developer community to know that we're working in the open with the full intent of multi-vendor standardisation of these APIs. I don't think we should wait long to hear back in these instances, but it does feel valuable to send every signal we can that we're interested in collaboration.

Otherwise, everything here sounds good to me.

Best,

Alex

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/b3b622df-dbc5-47f9-951e-a81a73c6f760%40chromium.org.

[Reilly Grant]

Thank you Mike for adding CR+1. I've amended my note to explicitly ask for reviews to reference the pending IWA reviews (the last option from my last message). The new documentation is now live: https://www.chromium.org/blink/launching-features/isolated-web-apps/

Thank you to everyone who provided input. I am OOO until next year and will be able to integrate any feedback from folks who have been out during this discussion then.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Chris Harrelson]

On Thu, Dec 21, 2023 at 5:13 PM Reilly Grant <rei...@chromium.org> wrote:

Thank you Mike for adding CR+1. I've amended my note to explicitly ask for reviews to reference the pending IWA reviews (the last option from my last message). The new documentation is now live: https://www.chromium.org/blink/launching-features/isolated-web-apps/

Thank you to everyone who provided input. I am OOO until next year and will be able to integrate any feedback from folks who have been out during this discussion then.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

On Wed, Dec 20, 2023 at 4:49 PM Alex Russell <sligh...@chromium.org> wrote:

I'm not entirely convinced that we win much by not requesting positions here. It's valuable to the developer community to know that we're working in the open with the full intent of multi-vendor standardisation of these APIs. I don't think we should wait long to hear back in these instances, but it does feel valuable to send every signal we can that we're interested in collaboration.

+1 to what Alex said here. I also hope other vendors and interested parties can give us non-security-related design and use-case feedback on API proposals, even if they are unable to ship them in their browsers or have concerns about the security model. These requests can potentially help to solicit such feedback.