Re: [w3ctag/design-reviews] Isolated Web Apps (Issue #842)

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](https://w3ctag.github.io/design-principles/#consent) is sufficient to enable them [safely](https://w3ctag.github.io/design-principles/#safe-to-browse).

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.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/842#issuecomment-1989631915
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/842/1989631915@github.com>