Isolated Web Apps

[reillyeon]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Isolated Web Apps
• Specification or proposal URL (if available):
• Explainer URL (if available): https://github.com/WICG/isolated-web-apps/blob/main/README.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

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.

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

This proposal will feel familiar to Mozillians who worked on the FirefoxOS project. There’s been good discussion on WICG/isolated-web-apps#10 about lessons learned from packaging apps for FirefoxOS.

I have requested a TAG review at w3ctag/design-reviews#842.

[robbiemc]

FYI, Chromium is rolling out an implementation of this proposal in a limited fashion (admin-controlled installation for managed users on ChromeOS devices). See https://groups.google.com/a/chromium.org/g/blink-dev/c/iMfYonTs414.

[martinthomson]

Hi Reilly, thanks for opening the discussion on this problem. Our view here more or less matches that of the TAG review (yep, I get to say the same thing with two different hats on). We don't think that this is the right approach to take overall.

The way that the Web has been most successful in delivering new capabilities is not by removing the safeguards, but by finding safe ways to achieve goals. To use one of your prime examples, if that means an end to direct use of TCP sockets, such that the server end has to adapt, that's something we've been willing to accept. Mozilla made a serious attempt to build that sort of API in the past, but we've come to appreciate that the hazards involved in that approach far exceed the benefits.

This approach basically says that asking for those concessions on a case-by-case basis is infeasible. That opens up a bunch of risks with no real prospects for targeted mitigation, only a very general one. Taking on those risks is unnecessary and potentially damaging.