TAG feedback

[xfq]

The TAG wrote a feedback document on MiniApps: https://github.com/w3ctag/design-reviews/blob/main/reviews/miniapp_packaging_feedback.md

We need to discuss it, and possibly organise teleconferences with the TAG and/or Web Bundles folks.

---

Chinese translation

[espinr]

Thank you, @xfq and TAG members, for the in-depth review.

I agree. We need to synchronize and have conversations with these groups. As we discussed in the November WG meeting, we can start collecting input from the MiniApp vendors for a more fruitful discussion. So, we will compile the options and identify the best approach to handle these recommendations.

Early analysis of Web Packaging

The current specification derives from the incubation CG work that researched the different options and possibilities to choose the best solution for a packaging mechanism. At that time, the group analyzed the existing technologies, considering other options, such as WICG's Web Package. Of course, the specification evolved, so this may fit better now.

The conclusion of the Web Package analysis was that this method is too oriented to Web resources, focused on HTTP exchanges (i.e., HTTP requests, responses, signatures, and other metadata), and establishing HTTP-specific signature mechanisms, which was not suitable for MiniApp. Note that MiniApps do not always rely on HTTP exchanges since they can be distributed in different ways (e.g., directly installed from the local filesystem).

Also, this solution (now under the denomination of Web Bundles) is based on CBOR instead of ZIP, which was used by all the MiniApps analyzed (e.g., Baidu Mini Program, Quick App, Alibaba Mini Program) and very common in the industry (e.g., Chrome Apps and Extensions, Firefox OS apps, APK,...). The analysis spotted the ZIP's potential lack of efficiency on the Web (suggested in TAG's document), but valuable for MiniApp implementations due to its versatility and wide range of tools in the market.

TAG's recommendations and insights

I'll extract the relevant points for discussion and recommendations provided by the TAG.

Miniapp community should examine making use of a packaging solution that preserves the origin model. [...] Bundling & signed exchanges provide a promising path towards this outcome. There may be other solutions in the market which can also play this role.

I agree, we need to preserve the origin model and secure context. One of the main use cases is to guarantee the integrity of the package (i.e., has the app been tampered with?), and we need to establish mechanisms for protecting the security of the apps.

• The current solution solves this through the package's digital signature(s) -none, one, or more. The spec does not recommend cryptographic algorithms or methods, leaving this to the implementations. This solution offers flexibility for any use case (e.g., verify authorship, publisher, marketplace, or third-party certification authority).

• Using this method, we can always verify the package's integrity. We don't need to rely only on HTTP for the exchanges. This is important because MiniApps may be distributed through different means and protocols.

• In the case of using HTTP to distribute the apps, we need to guarantee the certificate authority chain (i.e., should I trust example.org and its content?). Wouldn't the HTTP(Secure) transmission and the in-ZIP digital signature(s) enable us to guarantee this? (please, security experts, help :)

• So far, we haven't collected a use case that needs to implement security aspects based on HTTP headers. Due to the flexibility of the distribution means, we are discussing how to implement content security policies in MiniApps. Since we cannot always rely on HTTP, we solve this through a member in the manifest (still under discussion).

There are also other options out there to solve this. For instance, JAR uses the META-INF to host extra metadata beyond the resource's body. Still, we already have the manifest as a mandatory file to host this type of information.

Furthermore the TAG has concerns regarding the efficiency of the zip format for this use.

• This issue was previously mentioned; the ZIP container is probably less efficient when managing HTTP exchanges than other formats (the package must be fully fetched to check the integrity and security aspects), but one of the essential characteristics of MiniApps is the reduced size.

• The ZIP-based proposal considers that ZIP is a widespread standard, with a vast range of processing tools in the market, familiar to developers and potential MiniApps vendors. It is a solid format commonly used in mobile platforms (e.g., Android, iOS), and also in W3C (e.g., Lightweight Packaging Format (LPF), EPUB).

---

As an additional note for those unfamiliar with this WG's activities: this proposal strives to maintain and maximize compatibility with the popular existing MiniApp implementations, helping developers reuse the existing MiniApps with minimum effort across platforms and maximizing the alignment with the Web standards. Also, MiniApp packaging should not be considered a recommended model for other web-based applications.

[KenjiBaheux]

I'm part of the team working on Web Bundles in Chrome.
There's been a lot of changes since the early inception of this project.

Of note:

1. Web Bundles supports relative URLs for the bundled resources. This removes the need for specifying a Primary URL (origin). This allows the creation of bundles with origin-less resources.

- ./foo/foo.js
- ./bar/foo.css

instead of:

- https://example.com/foo/foo.js
- https://example.com/bar/foo.css

2. One advantage of the Web Bundle format over a ZIP format is that it features an index section at the very beginning of the file. This enables UA to load resources progressively without fetching all bytes, and possibly show something to the user much earlier than it would be possible with a "download the whole thing first" approach.
3. Regarding the need to specify various headers for the individual resources, this is also optional (i.e. the headers bit can be empty.
4. Isolated Web Apps might be of interest as well. Those are built on top of Web Bundles, features integrity signatures, etc. This is primarily meant for apps that are highly sensitive in nature but perhaps there are relevant parts that could be reused.

On the topic of Origin
There are clear user benefits to maintaining a connection with an Origin which is at the source of the mini-app. For instance, users wouldn't need to worry about the context in which they are currently using the mini-app. Their credentials, data would be attached to the origin as opposed to many {mini-App ACME x super App ZEBRA} independent contexts. Maybe this isn't appealing in some markets but in places where the web is used by lots of users this would definitely make a difference (e.g. login once, be logged in across all contexts).

I'd be more than happy to discuss in more details, and hear about your use cases or constraints.

[espinr]

After the discussion at the TPAC meeting we decided to keep the conversations with the TAG, clarifying and refining the current specs to cover all the security concerns pointed. The group is looking for concrete solutions that complement the existing proposals, minimizing the impact of the agreed contents and architecture. So, I would like to have the feedback from the WG participants about this:

Security aspects of the current specifications

Most MiniApp implementations analyzed (i.e., Quick Apps, Alipay, and Baidu Mini Programs) consider a centralized origin. The release of apps is continuously verified by a central authority that checks and verifies their specific quality standards. Later, the MiniApps are published in marketplaces linked to each platform.

Some MiniApps are not bound to an origin, as can happen with native apps. Some environments, like Quick Apps, enable debugging the applications from the local system and signing them like Android APKs. The solution to mitigate security risks is hashing and signing the MiniApp packages. This process guarantees the integrity of the package and enables the validation of the developer and the publisher (some cases are like in Android, allowing self-signed certificates). However, in these cases, we cannot keep the origin principle.

How can we preserve the original principle of MiniApps on the Web?

First, the user agent must require SSL/TSL over TCP connection. Second, the MiniApp package may include explicit information about the origin (i.e., where the package was fetched from). After the (secure) fetch, the user agent may check that the origin domain is the same as the one specified in the manifest. This origin metadata might be redundant because the user agent should keep this information internally, but this may enable an explicit reference to the origin within the package.

Cross-Origin Resources

MiniApps are usually designed to use only local resources. However, there are cases where MiniApps can fetch external resources (e.g., media resources and stylesheets). Moreover, they may include webView elements to embed HTML documents.

The different MiniApp platforms implement various methods to prevent unwanted cross-origin calls, most based on allow lists with trusted SSL/TSL domains. Web sources in both Alipay and Baidu MiniApp platforms are limited to an explicit list of authorized domains. This list is defined within the developer's platform. In the case of the Quick App, there is a manifest member called trustedSslDomains to describe this allow list and inform user agents of these restrictions.

Concrete proposal to increase security and mitigate risks in MiniApps, based on the current packaging specification:

1. Recommend using SSL/TSL over TCP.
   • This way, we don't limit MiniApps to HTTP.
   • We solve the challenge of integrity and trusted origin.
2. Include a new CSP member in the manifest to preserve information about the origin (hostname where the MiniApp was found).
   • The origin domain is stored within the package for further validation.
   • To include an expiration date?
3. Include a new CSP member in the manifest to implement the allowed list of trusted domains that will serve the user agent to control access to external resources.
   • We mitigate CORS risks.
4. Recommend hashing the content of the package before distribution.
   • We can guarantee the integrity of the MiniApp resources (including the CSP policies in the manifest)
5. Recommend inclusion of digital signatures without imposing specific encryption methods.

The definition of the new manifest CSP member should be based on the standard Content Security Policy Directives. I already proposed this time ago (w3c/miniapp-manifest#42).