MiniApp Lifecycle

[QingAn]

Hello TAG!

I'm requesting a TAG review of MiniApp Lifecycle.

This is the first proposal from the MiniApps Ecosystem Community Group. This is a proposal for a new Web API for MiniApp lifecycle to manage the lifecycle events of both global MiniApp application lifecycle and each MiniApp page’s lifecycle. MiniApp is composed of two layers, app layer and page layer. Therefore, MiniApp lifecycle contains application lifecycle and page lifecycle.

• Explainer¹ (minimally containing user needs and example code): https://github.com/w3c/miniapp/blob/gh-pages/specs/lifecycle/docs/explainer.md
• Security and Privacy self-review²: https://w3c.github.io/miniapp/specs/lifecycle/#privacy-and-security
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/miniapp/
• Primary contacts (and their relationship to the specification):
  • Qing An (@QingAn), Alibaba
• Organization/project driving the design: Alibaba
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):

Further details:

• [*] I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): MiniApps Ecosystem Community Group
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design:
• This work is being funded by:

You should also know that...
We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[cynthia]

Have you folks https://wicg.github.io/page-lifecycle/ seen this? It feels like there might be duplicate work happening.

Putting that aside, I'm not quite sure about the utility of being able to access the fragments from the URI - shouldn't that be available through location?

(Our position regarding miniapp specific URIs still stands.)

[QingAn]

Have you folks https://wicg.github.io/page-lifecycle/ seen this? It feels like there might be duplicate work happening.

Yes, we have looked at this doc. Since this doc only applies for page lifecycle, not at app-level. Therefore, we think it is necessary to define both app-level and page-level lifecycle.

[cynthia]

What is the "worker" in this lifecycle? It doesn't seem like it's a service worker, nor a web worker. Is this a new kind of worker?

[torgo]

Can you please give us an update on this one and let us know current status?

[xfq]

For the relationship between MiniApp Lifecycle and related work in W3C, you can see a simple comparison here. I have also filed a few issues asking for clarification.

For the definition of worker, I think it means the "logic layer" in https://xfq.github.io/miniapp-comparison/#overview (it's my personal notes about some of the technical differences between MiniApps and web apps).

For the current status, the CG (and/or proposed WG) plans to provide a mapping to existing Web specifications such as Service Workers and Page Visibility whenever possible. It is mentioned in the draft WG charter: https://w3c.github.io/miniapp/charters/wg-2020.html#rec-track

[xfq]

FYI - the MiniApps Working Group has been chartered and this spec has been published (as a Working Draft on /TR).

[torgo]

Hi @xfq – We're just reviewing in the TAG virtual f2f today. A few things we noted:

1. The mapping of Miniapp states to other w3c specs may be innacurate - in particular the mapping to service worker states.

2. The lifecycle document doesn't reference Manifest at all. It was our understanding that Miniapps would use the manifest file with the Miniapp extensions and that doesn't seem to be referenced in the document.

3. It doesn't look like you're referencing ServiceWorker either - is there a Miniapp state which makes use of ServiceWorker?

4. When a Miniapp is launched what origin can it be said to have, with regard to the web's security model? That would seem to be important from a lifecycle point of view.

We also note that the Page Lifecycle document that you point to as comparison is out of date and itself needs to be updated (in particular to reflect installation via Manifest, which is missing).

We think it's worth considering whether these lifecycle efforts (MiniApps, web pages, PWA) could be consolidated or brought together in some way.

[QingAn]

Thanks for the feedback. I have one question about the comment 1, hope some further clarification.

1. The mapping of Miniapp states to other w3c specs may be innacurate - in particular the mapping to service worker states.

Actually, in the current draft version, the mapping has not been defined yet. So I am not sure why the mapping "may be inaccurate". Or is the intention to add the mapping content?

[cynthia]

We were referring to this part of the explainer: https://github.com/w3c/miniapp-lifecycle/blob/main/docs/explainer.md#comparison-with-some-related-work-in-w3c-such-as-service-worker-page-visibility-and-page-lifecycle

[ylafon]

Hi, we reviewed Lifecycle again during our last F2F meeting.

For clarity, we'd like to separate the concerns we have in terms of priority.

1. BLOCKER: Origin model

Looking at https://github.com/w3c/miniapp-lifecycle/blob/main/docs/explainer.md#miniapp-origin the definition of Origin is crucial for following the same-origin policy, to ensure that the page is in a secure context to enable APIs that are only available in such context.

On the Web, it is done cryptographically via TLS and OCSP. In app stores, native applications are using validation done by the app store (like universal link), but this is not a first-hand verification (see the point below about responsabilities of the intermediary).

Note that files contained in the package act as a local cache for content relative to the origin, and as such should be verifiable to ensure that the origin-model is applicable here, even if no HTTP request will ever reach the network but would always be dereferenced to the content of the mini app package.

2. BLOCKER: Package can be modified by the intermediary

As there is no end-to-end cryptographically guaranteed scheme for validating the integrity of the package compared to what the content distributor originally shipped, the current proposal puts the users at the mercy of the app store to guarantee package integrity. We think this goes against the fundamental principles of the web and is a risk. A zero-trust model, such as what was introduced in signed exchanges would mitigate this.

There are notions about digital signatures in the response, but without knowing exactly when the signing happens by who, there isn't a guarantee that the content is as it came from the origin. If there is strong enforcement to guarantee that the signing is done at the point where it leaves the origin (or an equivalent first-party), this would be a way forward.

3. ZIP

Just to be clear on this, this is more of an issue with regards to random traversal of the underlying content of a given payload. For smaller payloads, the codec used for packaging is not as critical, but for something as content-heavy as a game (which can easily grow up to hundreds of megabytes), requiring full download (due to the layout of a ZIP file) would result in a less-than-optimal user experience.

We are empathetic to the choice made here, but if there is a possibility for swapping this out to something that is friendlier to low-bandwidth environments (e.g. following the game example - you don't need stage 2 content of a game unless you actually reach stage 2, and there are no guarantees that the user will play that long) as saving on transmission is beneficial to the user. (It also allows for faster loading, even for users on performant networks.)

An alternative design would be to use Service Workers as a delivery mechanism, and keep the packages light - but this comes at a cost of complicating the developer experience. Alternatively one could argue this is doable with fetch(), but these are high-level alternative approaches one could take to move away from a monolithic package which is suboptimal with ZIP.

[QingAn]

@ylafon I notice that the concerns are mostly related to the MiniApp Packaging specs or maybe MiniApp specs as a whole.

1. BLOCKER: Origin model

Looking at https://github.com/w3c/miniapp-lifecycle/blob/main/docs/explainer.md#miniapp-origin the definition of Origin is crucial for following the same-origin policy, to ensure that the page is in a secure context to enable APIs that are only available in such context.

MiniApp Lifecycle explainer introduces one practice MiniApp platform vendors manage MiniApps. But it's not within scope of MiniApp Lifecycle. It's more like a broader topic which will be discussed in MiniApp WG.

2. BLOCKER: Package can be modified by the intermediary

3. ZIP

These two are related to MiniApp Packaging spec. I will deliver to spec editors to address.

[torgo]

Hi @QingAn - thanks for this. Please let us know if you need any input on w3c/miniapp#195 and we look forward to reviewing any outcomes.

[QingAn]

@torgo We had an internal discussion this month and had some thinking and several possible proposals regarding TAG comment, especially the same origin issue. Now we are trying to solicit enough input from MiniApp vendors and document the converged proposal in GitHub issue.

With that said, MiniApp WG are still working on it. In this week WG call, we also are going to discuss this topic.

[xfq]

Several rounds of discussions have been held among MiniApp vendors in the WG, and a solution to the above three concerns has been proposed: w3c/miniapp#195 (comment)

Any comment on this proposal?

[torgo]

Hi @xfq ! Thanks for this. We spent some time on our call today reviewing the proposal. It's clear this is going in the right direction and we very much appreciate the group addressing the TAG's concerns. We need to do a more thorough review and we will get back to you with a list of questions.

[torgo]

Just adding a note of correction here – we think at this point that we're waiting for a new proposal from the miniapp community regarding the packaging and security model. Please let us know if you need any feedback from TAG at this point.