-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Isolated Web Apps #842
Comments
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:
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.
Thank you for working with us, and we look forward to your thoughts. |
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.
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.
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.
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.
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.
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.
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. |
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! |
Meeting tomorrow is probably too short notice so how about Tuesday, February 20th at 20:00 UTC? |
Sorry I wasn't clear, I meant either next week or the week after. We already have a fairly full agenda for this week. |
Does Tuesday the 20th (next week) work then? |
That's fine. We'll send you a calendar invite. Thanks. |
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. |
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:
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. |
こんにちは 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?
Further details:
You should also know that...
The explainer for this proposal is divided into 4 documents:
We'd prefer the TAG provide feedback as:
☂️ open a single issue in our GitHub repo for the entire review
The text was updated successfully, but these errors were encountered: