Isolated Web Apps: Will the web app gap be closed once and for all?
The web has become significantly more powerful in recent years: Last but not least, the application model of Progressive Web Apps (PWA) and the Chromium initiative Project Fugu have contributed to the fact that an increasing number of applications can be written directly for the web and made executable in the browser. such as Photoshop or Visual Studio Code.
Advertisement
Christian Liebel (@christianliebel) is a software developer at Thinktecture in Karlsruhe. He supports his customers with digitalization projects and the modernization of business applications. His hobbyhorse is cross-platform applications based on modern web technologies such as Angular, Progressive Web Apps, Project Fugu and Web Components. He has been recognized as a Microsoft MVP and Google GDE for his community contributions.
However, due to the security architecture of the web, the web app gap, i.e. the gap between the possibilities of platform-specific applications and web apps, will never be completely closed.
Lack of socket access sparked the discussion
One interface that cannot be exposed directly on the web is the Direct Sockets API, which should give developers the ability to target any server port – beyond HTTPS, WebSockets and WebRTC.
Since this would bypass the Web’s Same Origin Policy (SOP), and thus a key security barrier on the Web, the W3C’s Technical Architecture Group (TAG) expressed clear concerns. This elected body within the W3C is intended to ensure that new interfaces fit sensibly into the World Wide Web.
The web should become more powerful
At the same time, however, software developers want to be able to take advantage of these skills. Some completely basic interfaces are not available on the web, or at least not in all browsers.
In September 2023, at this year’s W3C annual conference TPAC in Seville, TAG announced the establishment of a task force to be able to bring such interfaces to the web.
The aim is to investigate a possible “powerful context” in which the user could explicitly consent to the installation of an application in order to unlock further capabilities such as access to sockets.
Isolated web apps as a possible way out
Google has already provided a possible suggestion for such a powerful context in the past: the so-called Isolated Web Apps (IWA). This application model also involves web applications, but this time they are distributed in the form of a signed bundle, via the classic distribution channels such as app stores, installation packages or enterprise deployments. Sideloading by directly installing the bundle would also be possible.
In return, this additional trust anchor gives the web applications access to a larger range of interfaces. These would still be executed by a browser.
Code signing meets the web
The signature makes man-in-the-middle attacks or manipulation of the source code on the application server much more difficult. Due to such concerns, the Messenger Signal is only released as an Electron app, but not as a progressive web app.
All subsequent versions must be signed with the same key. To avoid downgrading attacks, updates may only be made to a higher version number. Loading source code outside the application context is prevented, which is where the name Isolated Web App comes from. A separate URI scheme would be introduced for this: isolated-app://signed-web-bundle-id/path/foo.js?query#fragment
The signed-web-bundle-id corresponds to the Base32-encoded public key.
Advantages of the IWA model
In the case of IWAs, applications are delivered via the classic distribution channels that are familiar to the user. Application developers can take their existing web knowledge with them, but access even more powerful interfaces thanks to the additional trust anchor. These would continue to be openly standardized by the W3C.
The applications are still based on web technologies and could also share code with a PWA, for example. And all of this without the additional burden of classic wrapper approaches such as Electron, Tauri, Cordova or Capacitor.
Smartcard demo demonstrates the application model
The Chrome team’s Web Smart Card API Demo is intended to demonstrate the IWA application model by giving the packaged web application access to smart cards to identify people. However, this requires a ChromeOS device and multiple feature flags to be enabled. Support for the Web Smart Card API is scheduled to be added to Chromium for Windows, macOS, and Linux later in 2024.
Conclusion
In summary, isolated web apps could actually significantly reduce the web app gap again and shake up the cross-platform field. However, the entire effort is still in its early stages. The task force announced in September has not yet been set up. And there is currently no commitment from Mozilla or Apple.
(rme)
To home page