Offline packaged applications

Bubuche87 · 2023-02-16

Hello everybody. I am not a native English speaker.

Some time ago, I wrote this document. I then tried to contact the w3c and after a bunch of dead ends, I gave up.

I just now find this forum. Hopefully it will work this time.

The document I wrote is a pdf. Instead of copy-pasting it here, I’ll give a link.

https://drive.google.com/file/d/1J3PC3PgHNecGF0syrvWmZiwkg0MLhTUp/view

Now, it would be rude to end the message like that, so I’ll try to paraphrase the document, to summarize the idea

The idea is to bring back packaged applications. We used to have “file://” but for security reasons it became almost useless. We used to have java applets, but the proprietary aspect of everything lead to unfixable security issues. We used to have flash, but it followed the same path.

Now, I think that those things did not disappear because of a lack of popularity. They did because we had to to protect the user. And each time the problem did not come from the offline dimension, but from other aspects ( the blurred boundaries of the application for “file://” ).

There is still an market ( for a lack of a better term to say “there is both producers and consumers that want this option”) for such offline application. We must avoid security issues, that’s granted. But I think that with offline applications we can increase the security. After all, I don’t need an image editor to be able to mess with all my files.

The sandbox and highly controlled model we have for web applications could be extended to offline applications. With the rise of wasm, the possibilities of the canvas tag and the long term storage ( yet controlled) with indexeddb, we have all we need to create amazing offline applications.

All we need ? Not exactly: some parts of the API (like the gamepad) are hidden behind http/https. You can make an offline game, but you won’t have access to gamepads. You are also presently forced to pack all your data in a html-compatible encoding. And you cannot sign anything.

Well, I think it’s enough. The rest is in the document. Of course it’s nowhere near finalized.

Bubuche87 · 2023-02-18

This post is a quick brush of the extensions we could add to this. The reason why they are just “extensions” and not part of the core proposition is that they create security issues. Nothing serious, but it was enough for me to put them aside.

The first is about webservices and webrtc. Webservices first: the general idea that has been pushed for years is that a website can retain some functionalities and interactivity while being offline. One way to do that is to embed a webservice “fake-server” in your application, that will intercept the requests that would have fail ( because they try to contact a server unreachable because of the offline) and respond to them with previously cached results. It’s a kind of an advanced cache system, under the control of the page itself ( as opposed to "under the control of the browser’s heuristics).

The web RTC now. Here the idea is to allow a direct (P2P) connection between two browsers. I will not talk more about it.

How are those two things related to my proposition ? Well, is such a packaged application could have access to the internet [danger security flag here] it could embed a server. Accepting incoming connections and responding to them is a well know mechanism. It’s something we are used to. The two API I mentioned ( webservices and web RTC) could be replaced by ( or actually, used as the backend of ) this embedded server. A request coming from the page (webservices) or a request coming from the web (web RTC) is a request and could be treated the same. A flag could be added to distinguish them, if needed ( maybe we want to treat request from the page itself differently).

Nothing special would have to be done by the browser ( except granting the right to access internet ): it could be implemented as an embedded library.

Such an application would have a very clean distinction between the view (html) the controller (JavaScript) and the model (the embedded server). It would let many website to go offline, as neither the server nor the client would have to be significantly modified. The session system you have in PHP could have a backend in indexeddb for example.

It’s a system that reuses the good old client-server architecture. It could also have an impact on the P2P, by bringing comprehensive technologies to make servers client side, while increasing the overall security ( now your server is sandboxed ). Here again there is a lot of low-hanging fruits to grab. ( This message is long enough. I’ll go on with a second extension tomorrow )

DanielHerr · 2023-02-18

You may want to take a look at Isolated Web Apps.

https://chromestatus.com/feature/5146307550248960

github.com

WICG/isolated-web-apps/blob/main/README.md

# Isolated Web Apps Explainer

## Introduction

This document proposes a way of building applications using web standard technologies that will have useful security properties unavailable to normal web pages. They are tentatively called Isolated Web Apps (IWAs). Rather than being hosted on live web servers and fetched over HTTPS, these applications are packaged into [Web Bundles](https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html), signed by their developer, and distributed to end-users through one or more of the potential methods described below.

## Motivating Use Cases

Content Security Policy (CSP) provides strong protection against cross-site scripting (XSS) vulnerabilities. Transport Layer Security (TLS) and Subresource Integrity (SRI) provide protection against resources being tampered with in transit or when hosted on third-party servers. However, the threat model for some particularly security sensitive applications includes the main application server itself being compromised and serving malicious content. This goes beyond the protections that current policies can provide. An environment stricter than [[SECURE-CONTEXT]](https://w3c.github.io/webappsec-secure-contexts/) is therefore required.

For example, developers of the private messaging application Signal [concluded](https://github.com/signalapp/Signal-Desktop/issues/871) that it was more secure to distribute their application as a versioned and signed package through an application store. They were concerned that self-hosting a web app would put their users at risk if their servers were compromised to serve malicious code. When Chrome Apps were deprecated, they chose to move their application to the Electron framework and accept the increase the download size and complexity of their application rather than put their users at risk. The developers of WhatsApp, another secure messaging application, have similar concerns and have produced a [browser extension](https://chrome.google.com/webstore/detail/code-verify/llohflklppcaghdpehpbklhlfebooeog) to perform out-of-band validation of the code served to users' browsers. A comparison between that work and this proposal is included at the end of this document.

A user agent may also force an application to adopt this threat model if the developer needs access to APIs which would make the application an appealing target for XSS or server-side attacks. For example, the [Direct Sockets API](https://wicg.github.io/direct-sockets/) allows a site to make arbitrary network connections. The Fetch Standard defines the [CORS protocol](https://fetch.spec.whatwg.org/#cors-protocol) to carefully control the network requests that sites can make as users browse the web and execute potentially untrustworthy Javascript. Nevertheless, some applications have legitimate needs to make connections that would violate CORS and use protocols other than HTTP. The tradeoff the application developer can make in order to get access to this capability is to accept that user agents need to establish a higher standard for the trustworthiness of the application code and better protection against its compromise by malware.

## Non-goals

This proposal should _not_ be considered a desirable model for most web-based applications. Developers who choose the additional security provided by this proposal give up a number of desirable properties that come from building a web app. An example is the ability for users to discover their application by following a link that drops them into a complete experience rather than having to first install the application. They also lose the ability to quickly deploy updates from their own servers. Most applications do not need the enhanced security that this model offers. Existing methods can protect against many types of attacks without the additional burden of bundling and signing their resources.

## Proposed Solution

This file has been truncated. show original

Bubuche87 · 2023-02-18

EDIT: it seems this idea has already been visited several times. Btw, in the link you mention they don’t mention flash, java applets and “file://”. It’s not a critic, I just want to say by that that if we were to include all the attempts to make browser-based offline applications, there would be even more occurrences than what they listed.

Now, I am not sure that what they propose is exactly what I propose. It’s close, definitely, and I can say that we have similar concerns and conclusions, for what I saw.

The question is: is there a chance to have a version of that standardized someday ? What is the position of the W3C about that, do they have a group working on the question, is there a suggestion officially studied ? If this forum’s goal is to simplify those procedures … I am not absolutely off topic, am I ? What is the next logical step ?

Bubuche87 · 2023-02-22

I’ll present the second extension of what I mentioned. Once again, I excluded it from the original proposition because it has security issues. It can also increase security if used correctly.

If the original proposition is ever accepted, it will become obvious that a huge part of a lot of those offline applications comes from embedded librairies. It’s like distributing statically linked programs.

The solution to that is already known: dynamic linking. Linking to previously installed libraries, instead of including the kitchen sink in every single application.

How would that be achieved? There is several ways to do it, but because we are on the web, one of them seems more natural than the others. We have been including external scripts for quite a long time, we could as well keep doing it.

The idea is to organize applications in a graph. What I have in mind is precisely the kind of graph describing the local networks of a company, where you isolate the public server from the internal server on two different networks. The passages between the different networks can enforce rules on what can and cannot go through.

Each application would have an address ( I guess we can skip the IP part and directly go to dns-like names ), and an application could establish a connection with another application with that address ( if it has the rights to do so ).

This is not incompatible with the previous extension: some applications could have an internet access and “share” it with other applications if they desire to do so. You would be able to distribute a module that is in charge of the communications with you, and other applications that would want to communicate with you would be able to do so through your module. The policy could be that a module is allowed to connect a website only if it has the certificates for this website and a certificate signed by this website certifying this very module. When offline, the module could provide a default service, even if it never had been online ( in the same way you can “commit” offline then later “push” online )