Isolated Web Apps

[reillyeon]

こんにちは TAG-さん!

I'm requesting a TAG review of Isolated Web Apps.

This proposal provides a way to build applications using web technologies that will have useful security properties unavailable to normal web pages. To enable stronger security these applications are packaged into Web Bundles, signed by their developer, and distributed to end-users through one or more of the potential methods described in the explainer.

There are two main questions I am looking for answers to from the TAG:

First, is this proposal architecturally sound on its own?

Second, given the context provided by this proposal, is the TAG interested in reviewing proposals that depend on it? For example, an earlier TAG review of the Direct Sockets API failed because it was missing effective mitigations for the security concerns. Does the TAG agree that this proposal could provide such mitigations?

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/isolated-web-apps
• User research: None
• Security and Privacy self-review²: https://github.com/WICG/isolated-web-apps/blob/main/SecurityPrivacyQuestionnaire.md
• GitHub repo: https://github.com/WICG/isolated-web-apps
• Primary contacts:
  • Reilly Grant (@reillyeon), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature: https://chromestatus.com/feature/5146307550248960

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Web Incubator Community Group
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: None yet
• Major unresolved issues with or opposition to this design: None yet
• This work is being funded by: Google

You should also know that...

The explainer for this proposal is divided into 4 documents:

• The main explainer covers the overall goals of the proposal.
• The scheme explainer covers the design of the proposed isolated-app:// scheme.
• The permissions explainer covers an addition to the Web Application Manifest which allows a minimum Permissions Policy to be applied to the entire application.
• The updates explainer covers how applications will be updated.

We'd prefer the TAG provide feedback as:

☂️ open a single issue in our GitHub repo for the entire review

[LeaVerou]

Hi @reillyeon,

We looked at this today during our plenary call. First, we do agree that the use cases should be possible to address within the Web Platform itself, but do have some concerns:

1. 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.

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?

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.

4. What’s the upgrade path from a PWA of today into an Isolated Web App?

5. We are concerned about the lack of multistakeholder support. Looking at the Chrome Status 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.

6. We want to note that Borderless mode 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.

Thank you for working with us, and we look forward to your thoughts.

[reillyeon]

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 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 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.

[plinss]

Hi @reillyeon we discussed this during a breakout session today and have more questions about the intention of this proposal. This might benefit more from a direct conversation than a bunch of back-and-forth in the issue. Are you able to join us for a session in the next few weeks?

We have a number of regular breakout slots to choose from: Mondays at 17:00 UTC, Mondays at 21:00 UTC, or Tuesdays at 20:00 UTC. Let us know which slot works best for you an don which date, thanks!

[reillyeon]

Meeting tomorrow is probably too short notice so how about Tuesday, February 20th at 20:00 UTC?

[plinss]

Sorry I wasn't clear, I meant either next week or the week after. We already have a fairly full agenda for this week.

[reillyeon]

Does Tuesday the 20th (next week) work then?

[plinss]

That's fine. We'll send you a calendar invite. Thanks.

[reillyeon]

Thank you @plinss and @martinthomson for the discussion last week. I think where we landed in the discussion is that the particular problem Google is trying to solve with this proposal is having an environment where APIs like Direct Sockets could be enabled. Another example I gave was remote desktop support in WebAuthn. We believe that IWAs solve this problem by providing a way to reason about the content of an application which then enables auditing and other controls which are not possible for sites loaded from live servers. I think this is also relevant for other apps with high security requirements, such as end-to-end messaging. Martin expressed some particular concerns with the signature mechanism which I think we can resolve once we have agreement on the high-level goals.

[martinthomson]

Hi @reillyeon, thanks again for coming to talk with us. @plinss, @hober, @LeaVerou, and I discussed this a little more and we have some high-level feedback on the proposal.

There are two parts to this feedback. The first is about goals, the second about mechanisms.

The stated goal of this work is to find a way to enable the use of capabilities that are not natively provided by the Web. The idea is to enable these generically, but in our discussions two concrete examples were given:

• raw TCP or UDP socket access
• generic passkey usage for remote desktop web apps

These are clearly examples of very dangerous things to enable for regular websites. Past discussions of these capabilities have generally concluded that no amount of notice and consent is sufficient to enable them safely.

There are lots of worked examples where the web has supported use cases, even if the capabilities originally seemed very risky if they were implemented following the example of native platforms.

If a concrete reason for requesting TCP access is access to email, then we have webmail. We also have a web-friendly alternative to IMAP in JMAP, even if it requires server support. Similarly, servers can provide a gateway that can provide email access. For the passkey example, an extension to WebAuthn seems technically very challenging, even if it were narrowly scoped, but that narrow scope might make it easier to manage safety risks.

Having a generic privilege escalation mechanism is inherently more risky than building a narrowly-targeted means of addressing a use case. We encourage you to both look at use cases rather than capabilities and to seek narrowly-scoped solutions for those use cases.

Turning to the mechanisms proposed in this explainer, there are multiple applications for a system that ensures that many website users receive the same content. We are aware of several active efforts in this area, some of which are cited from the explainer.

The signature mechanism proposed does not really address the most difficult parts of the problem space. The explainer describes a bundling and signing mechanism, but the difficult component to the design is not tying content to a particular origin. TLS does that, after all. The challenging components relate to consistency, auditing, and revocation.

At first glance, it would seem like the goal is consistency: the idea that everyone gets the same content. However, after discussing the motivation with the proponents, that no longer seems to be the central argument. The idea that capabilities might be auditable is definitely aided by having consistency. If a site is granted a capability and only abuses it for a select few, detecting that is difficult if the offending code can be narrowly and surreptitiously targeted.

Consistency is a concept that is very important in some settings, such as in the implementation of end-to-end encryption protections in web apps. However, that does not seem to be the primary mechanism involved in this design.

This design relies more heavily on revocation. The idea appears to be to employ revocation methods similar to those used in web extension or app stores. There, an authority is given the ability to detect and revoke the rights granted to bad actors. App stores use a mix of up-front review and revocation in the event that bad behaviour is detected to help manage the risk of abuse. We understand that the proposal would not involve sites asking permission of anyone other than their users, so only detection and revocation would be involved. We do not know who has this responsibility/right; is it the browser maker?

In such a system, establishing who can obtain this authority -- and under what terms they are permitted to exercise it -- is very hard. It is especially hard on the web because the web does not naturally recognize the sort of centralized authorities that are used in the extension/app store concept that this is modelled on. The explainer does not include enough detail on this aspect of the design to make any real judgment.

This governance issue is perhaps the best reason to recommend against a plan that relies on the existence of this sort of authority. Building a system that relies on governance, particularly governance that might end up being centralized, requires extraordinary justification.

We advise that the proponents not seek to build a generic privilege escalation mechanism. That is particularly difficult. We suggest instead that they seek to find narrowly targeted solutions for use cases -- not capabilities -- which has proven to be a more productive line of investigation on the web to date.