- From: Reilly Grant <notifications@github.com>
- Date: Sun, 10 Sep 2023 11:03:14 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/842/1712898653@github.com>
My apologies for taking so long to put together this response. If folks on the TAG who reviewed this proposal would like to discuss these or any other questions we are having a session in the WICG on Tuesday at 17:00. > We are unclear on how this compares to some of the related work on this topic (a lot of which is also listed in the explainer). Given that the use cases presented are all different brands of the same use case (end-to-end encryption for instant messaging) we are a bit concerned about the solution being overfitted to very specific use cases, and having to be redesigned later, as more diverse use cases emerge. > > Given that this presents an app installation mechanism, we think it's important for it more broadly take the use cases for app installation into account (e.g. installation as a more explicit indication that certain very powerful APIs should be available, where a permissions prompt or user activation is not a sufficient signal). We don't want the Web Platform to end up with several _different_ installation mechanisms. Since the explainer was originally published I added an explicit callout to the potential for certain very powerful APIs to only be available in an IWA. The justification being that either the app developer threat model (in the E2E messaging case) requires stronger integrity or the browser's threat model for the powerful API does. Either way the same underlying mechanism would be used. > 2. The explainer mentions signed web bundles, but there is no reference to how signed web bundles would work. Is that in scope for this work? Is it defined somewhere else? How do developers sign these? The explainer for this is in the Web Packaging org: https://github.com/WICG/webpackage/blob/main/explainers/integrity-signature.md I've updated the explainer to link to this more clearly. > 3. We are unclear on what the user experience looks like from the end-user’s point of view. You mention that this is not a desirable model for most web applications, which implies that the user experience is impacted in some way that makes the trade-off only worth it in security-sensitive applications, but there is no description of what this user experience looks like. Chrome is still exploring what the user experience will look like but the prototype we are currently building will require the user to explicitly download a Signed Web Bundle and double-click on it to trigger the install process, similar to the experience of installing native desktop apps on most platforms. This means that IWAs aren't the deep-linkable and ephemeral experiences that a normal web app is, which is an unfortunate but I believe necessary tradeoff. > 4. What’s the upgrade path from a PWA of today into an Isolated Web App? We aren't planning on building one as part of our prototype but I could imagine a way that an HTTPS origin could do a one-time transfer of state to the isolated-app origin. There's a similar issue in user agents such as Safari which create separate storage shed for each installed web app. If a solution to that problem is standardized it could be applied here as well. For now the upgrade path from a PWA to an IWA is similar to upgrading from a PWA to a native app. > 5. We are concerned about the lack of multistakeholder support. Looking at the [Chrome Status](https://chromestatus.com/feature/5146307550248960) entry, there are no signals from any other stakeholder, not even web developers. If this is going to be a thing we think it's really important to get other stakeholders involved. A W3C workshop or a TAG task force might be an appropriate mechanism to achieve multistakeholder support and to bring in existing related work. I have requested feedback from WebKit and Mozilla on this proposal but have yet to hear back. Since this proposal was published we have seen interest from developers who want access to the very powerful APIs that are proposed to require this infrastructure. Google also has developer partners who have motivated this work but aren't ready to announce their interest publicly. > 6. We want to note that [Borderless mode](https://github.com/w3ctag/design-reviews/issues/852) has a dependency on this work. We are concerned about going ahead with that before these packaged and signed apps are consensus-based and more stable. It looks like there are a number of sessions at TPAC where there will be opportunities to understand how interested other implementations are in this concept. I would of course love this idea to develop into a standard but I can't commit to holding back other work until that happens. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/842#issuecomment-1712898653 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/842/1712898653@github.com>
Received on Sunday, 10 September 2023 18:03:21 UTC