Re: [w3ctag/design-reviews] MiniApp Lifecycle (#523)

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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/523#issuecomment-1427697804
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/523/1427697804@github.com>