#523: MiniApp Lifecycle

Visit on Github.

Opened Jun 10, 2020

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.

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

Discussions

Discussed Jun 1, 2020 (See Github)

Sangwhan: I looked at this - their lifecycle is effectively defining a PWA. It's petty much the same as the PWA lifecycle. [goes over how many things in the explainer can be mapped to PWA life-cycle]. Foreground and background mode... background not well defined. Some API differences.

Yves: media types, parameters - they want to be able to figure out its a mini app before they open the URL.

Sangwhan: a miniapp URL is a miniapp:// a miniapp url has a dereferencing process... can be re-written into a HTTPS url so becomes a web URL. Effectively a https url in a different format.

Dan: could we encourage them to merge this with a general web app lifecycle document (so encompassing both PWAs and miniapps).

Sangwhan: web app lifecycle doc exists...

Dan: looks like it hasn't been touched since Sept 2019.

Dan: we need to ensure the coherence of the web platform.

Dan: [we decided to author a miniapps feedback document to encompass feedback on miniapps URL, miniapps lifecycle and miniapps manifest]

Dan: we could try to ship them some feedback next week

Comment by @cynthia Jun 16, 2020 (See Github)

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.)

Comment by @QingAn Jul 3, 2020 (See Github)

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.

Comment by @cynthia Sep 24, 2020 (See Github)

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?

Comment by @torgo Sep 24, 2020 (See Github)

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

Comment by @xfq Nov 16, 2020 (See Github)

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

Discussed Jan 1, 2021 (See Github)

Ask at plenary if we leave this open or can close it as well

Yves: I think it's better to have proposed close on both

Sangwhan: lifecycle has not changed, maybe we should leave that open

Comment by @xfq Aug 23, 2021 (See Github)

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

Discussed Sep 1, 2021 (See Github)

Dan: 5 days ago we left feedback. They've opened an issue looks like they will discuss...

Discussed Sep 1, 2021 (See Github)

Dan: recent comment about mapping to w3c specs, I don't understand

Sangwhan: [responds] I think it's a misunderstanding. No comments about other parts. Also see their issue 15

Dan: needs to be more docs about web page / web app lifecycle and that this work needs to happen in that context.

Sangwhan: message should be - yes miniapp lifecycle is important, but it's implicitly also a page lifecycle. We don't want two separate specs saying different things in different formats, we want consolidated spec

Dan: I can see the need for if there are additional things in miniapps it should be pointing to a accurate page lifecycle spec and saying in addition miniapps register this kind of service worker or are using these other kinds of technologies, these are the additional steps in a miniapp lifecycle. But it should be using a page life cycle as a core. But the problem is there is no accurate maintained page lifecycle spec.

Sangwhan: and because that work has been abandoned it would be great if they could pick it up. Doesn't make sense to have a miniapp lifecycle which doesn't have a page lifecycle defined in it.

Dan: that would be great

Sangwhan: maybe they should know they can supercede an abandoned WICG spec... Page Lifecycle has not be touched for the last 3 years...

Yves: the best way would be for me to discuss directly with them. If the TAG feedback is it is important that the work on the page lifecycle is continuing, then it should be enough, the WG can drive the work in that area

Ken: lots of history already to that

Sangwhan:

I think you can either 1) take on Page Lifecycle or 2) absorb Page Lifecycle into a singular lifecycle spec, and officially deprecate it. Ideally, we think work should happen on both specs - we'll follow up on this.

Dan: TAG can host a special call with miniapps and PWA community? Be great to have one place where we talk about lifecycles.

Sangwhan: I think the people working on page lifecycle have moved on to other things

Dan: maybe just needs a bit of energy. Miniapps could be a way to help channel that.

Discussed Sep 1, 2021 (See Github)

Sangwhan: my question is .. we don't have a lifecycle document for pwas and we don't have a good document for pages, but now we have one for osmething that is very specific and do we want that?

Dan: maybe we should have a lifecycle document for web applications that includes things like .. I don't think we should have it for pwas, not a concept we should canonicalize, but we should have a lifecycle document for web applications that includes the mechanisms used by pwas such as installation via a manifest and we could use this document as a template.

Sangwhan: I'm looking at their explainer.. i'm not so sure if i agree with their service worker to application launch mapping.. those are largely different concepts. Why they need a new spec?

Dan: you mean in the comparison with related work in w3c? Page lifecycle is something in WICG

Sangwhan: page lifecycle hasn't been updated for a while. They said it doesn't do what they need to do and i agree because it's not maintained. Last update Sept 2019.

Dan: I don't think service worker install is the same as application launch. and service worker activate doesn't have anything to do with application shown

Sangwhan: service worker is not an application, it's a data source

Dan: we could leave that feedback

Sangwhan: you don't think pwa lifecycle should be defined?

Dan: I think web application lifecycle should be defined. Part of web application is the optional installation. Part of the install is service worker activation etc.

Sangwhan: that's part of the page lifecycle draft

Dan: the whole thing with a 'pwa' is that it's optional if the user decides to install it or use it within the browser context. Gives the person the choice of if you think this is useful then you can choose to install it on your device and activate it and it takes advantage of the things in the manifest file, but youc an also continue to use it within the browser and either way it might be using a service worker. It doesn't make sense ot have a separate lifecycle document that only covers when you choose ot install something on your device because that's only one user flow

Sangwhan: right

Dan: so maybe we should be updating this page lifecycle document.

Sangwhan: they also want to define their own set of api events. I think miniapp doesn't actually have installs.. it says "miniapp is install-free"

Dan: ...download miniapp resource... hosted native app... you could say the same thing about pwas. The installation of pwa is simply you coudl have it installed but the browser has chosen to de-register the service worker and cleared the cache but all of that stuff can be reestablished from the server when needed. It's the same lifecycle. You could say pwas are install-free as well, the only sense in which they're installed is that there's an icon on your screen

Sangwhan: I'm pretty sure they had installation through non-web delivery mechanisms in one of their documents but I can't find it

Dan: this document should be webapp lifecycle and should include things like service worker registration, manifest file. Tis document doesn't have anything about manifest file

Sangwhan: they have a separate manifest spec... that's a good point. I don't know the installation process for this thing

Dan: separately we could be prompting and say someone shoudl be taking this lifecycle work on.. but we've got to focus on giving feedback to miniapps. The comparison or mapping of different things to service worker and other types of .. what's this page visibility level thing?

Sangwhan: for when you have multiple tabs and one thing is in focus and others aren't in focus

Dan: in the miniapp lifecycle they're not referencing service workers at all

Yves: they don't rely on service workers

Dan: neither manifests. Part of our feedbackto them has been make use of manifest

Yves: they are working on manifest file

Dan: why isn't that called out in the lifecycle?

Sangwhan: good question. Can ask.

Dan: they are not using service worker?

Sangwhan: no. I think you can but it's not a mandate

Dan: why not?

Yves: probably dn't need to cache things that are already in your.. from external interactions for example

Sangwhan: I don't think miniapps were designed with offline in mind

Dan: [writes comment]

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.

Sangwhan: I'm not sure why they want this extra event system for this. Seems like they're modelling around the android apis, but I don't know.

Dan: I'm not sure I agree its worth consolidating all of the lifecycel efforts into a single spec. Worth considering if they could be brought together, but I don't envision that there could be a document that pwa people are referencing and updating that also has all of this optional stuff that only relates o miniapps.

Sangwhan: okay

Comment by @torgo Sep 16, 2021 (See Github)

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.

Comment by @QingAn Sep 22, 2021 (See Github)

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?

Comment by @cynthia Sep 28, 2021 (See Github)

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

Comment by @QingAn Sep 28, 2021 (See Github)

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

Thanks for the clarification. MiniApp WG is working on updating the explainer.

Discussed Dec 1, 2021 (See Github)

Dan: is origin the same as we think about origin?

Sangwhan: no it's not the same.

Dan: Well from an arch perspective we could ask them to clarify how their concept of origin fits together with the web security model's version of origin.

Sangwhan: concerns with this [general] approach - redefefining a lifecycle... miniapp will be cached in the hosted native app for some duration. It's packaging to some extent. There's an analog to page lifecycle except for putting things in the foreground or background...

Sangwhan: are they still using their own URI scheme? (as referenced in the explainer)

privacy & security

Sangwhan: they have the concept of running in the background - this is different from the mode we usually operate on. A user thinks they dismissed a miniapp and gave geolocation access - it's running in the background and user doesn't know it. That's a privacy risk.

Dan: isn't that why when web apps want to do this kind of thing they use serviceworker ...

Sangwhan: there's a reason why you can't do certain things in serviceworker - this kind of breaks that model. If you switch between two geolocation apps - when you give geo info to a background miniapp it will look like your current foreground app is the one using it... It will be telling you that the geo info is being used by the superapp shell.

Dan: shouldn't we be guiding them to make use of serviceworker instead of having this separate notion of foreground and background miniapps?

Sangwhan: Serviceworker doesn't provide what they need. it just keeps local cache proxy data up to date... their use case is more subtle than that.

Dan: when I launch twitter and launch pinafore (PWAs) I can switch between them seamlessly no problem... what is the difference?

Sangwhan: you would definitely not want to grant a miniapp in the background a permission... for a PWA on Android when a webapp is using a permission you're switching between origins so it's clear where the permission is. With miniapps you have app nesting. We should probably bring that up.

Dan: [can't they just use service worker?]

Sangwhan: I think background is entirely for lanuch performance. I can see why they are thinking in this way. The urge to make the launch faster. PWA launches are time consuming.

Dan: Outlines the lifecycle of walking into a Starbucks and paying with Alipay - in both PWA and miniapp world - would both involve a starbucks origin and a web payment "application" using Alipay.

Sangwhan: this could be made to work in conjunction with the web and PWAs - but they are re-inventing because they have existing implementations. It doesn't follow the common principles of the web.

Dan: I think there are 2 levels: 1st level is using the common principles of the web ; 2nd level is maybe making more use of PWA stuff.... right now we have neither.

Dan: could we push on web security model - origin...

Sangwhan: yes - and the privacy & security section of the spec doesn't really discuss privacy & security. General concerns: a lot of reinventing the wheel happening. The reason why the web is the way it is - is that we have iterated over multiple decades to have the right security model to protect users. This reinvention repeats the same mistakes and has to reiterate. For that reason we can't be supportive of this isolated ecosystem and would prefer to build towards a convergerd web.

Dan: back to serviceworker - if it doesn't work for them because it doesn't provide the functionality they need for miniapp then bring those requirements to the table in webapps wg so we can work on that.

Dan: they did talk about building extensions to webapp manifest... so why not extensions or similar to service worker, or others... right now we're on a path towards greater divergence.. We need a meeting of the minds between PWA and miniapp people... Both are inventing new things and these things are nor compatible.

Discussed Feb 1, 2022 (See Github)

Sangwhan: updated explainer but fundamentals have not changed

Max: updated but not addressed all the comments from the TAG review

Sangwhan: we brought up the idea of trying to merge it with page lifecycle, not sure what else we can do

Dan: they say page lifecycle is a wicg work item and they're not sure if there's interest from other groups to develop it. Maybe we can say thank you to Qing An for the updated explainer but can they further address the issues that we've raised

Sangwhan: [leaves comment]

Comment by @QingAn Feb 8, 2022 (See Github)

The explainer has been updated: 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

Comment by @cynthia Feb 8, 2022 (See Github)

Thank you for making these changes. We would also appreciate it if you could consider our previous review comments as well, as it would be great if someone could steward the page lifecycle work while lifecycle is being worked on.

Comment by @QingAn Mar 24, 2022 (See Github)
  1. The mapping of Miniapp states to other w3c specs may be innacurate - in particular the mapping to service worker states.

The explainer has been updated to reflect the mapping: 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

  1. 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.

This has been addressed by this merged PR: https://github.com/w3c/miniapp-lifecycle/pull/21

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

This has been addressed by this merged PR: https://github.com/w3c/miniapp-lifecycle/pull/18

  1. 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.

The explainer has been updated to describe the MiniApp origin: https://github.com/w3c/miniapp-lifecycle/blob/main/docs/explainer.md#miniapp-origin

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.

MiniApp WG thinks it is a good idea to discuss whether these lifecycle efforts (MiniApps, web pages, PWA) could be consolidated. To make this work, the participants from Web App and PWA are necessary. Otherwise, it seems infeasible.

Discussed Apr 1, 2022 (See Github)

Yves: ... would be good if the mini app people would look at ...

Sangwhan: how do you 'check the origin of the miniapp'?

Dan: a good indicator..

Sangwhan: [leaves comment]

Yves: about the webapp launch handler. In the discussion we talked about miniapp lifecycle and that they should look at it.. point them in that direction

Amy: did Max say he was going to talk to them about that?

Dan: we need to come up with what role the TAG can and should play in bringing together the miniapp community and the web app and pwa people. Appears to be something the TAG should do, but need to think about how

Sangwhan: I think the people who are working on page lifecycle are still around in chrome, I can ask

Dan: feels like there needs to be a mini workshop that focuses on lifecycle where we bring together pwa enthusiasts, webapp people and the miniapp folks. Let's bump until Max is back.

Discussed Apr 1, 2022 (See Github)

Max: authors have replied, regarding authentication mechanism. We can discuss whether it's clear enough..

Amy: do you know if they connected with the Web App Lifecycle people?

Max: had these discussions before, authors left comments to make sure they're aligned, that's the idea

Sangwhan: not good... checks the origin through an intermediary. A developer can claim an origin, and it's entirely up to the mini app platform to determine whether or not the developer is worthy of claiming that origin. That sounds scary. The problem is the verification depends on - it's not a chain of trust - it's giving the inermeidary unlimited powers on whether or not a certain developer can claim an origin or not. Let's say for example, example.com - I claim it's mine, and I claim my mini app is from that origin. The app store will say I trust Sangwhan, I'll just give him access to example.com,e ven if I shouldn't be example.com. That destroys the origin model because the mini app is effectively operating as if it is on example.com, and al the cors validation is going to be on the assumption that is example.com

Max: in the .. for example one mini app is going to apply to register itself onto the app platform, the platform should do some authentication about the authenticitiy of the claimed origin. Does that solve the concern?

Sangwhan: how does the platform do the authentication?

Max: maybe should be done by.. what we do in application store is the same problem..

Sangwhan: no it's not. If the mini app claims to be example.com and makes a request to example.com on the web it will be treated in same origin. In a native app you don't have the cors model, so it's not an issue. If you disregard cors and consider mini app non-web it's fine, but if it has to account for cors this is not good. This is why it took so much time to get bundled exchanges and signed exchanges out, it's a very hard problem to solve. Signed exchanges somehwat lets you do that, it's how it should work, but signed exchanges are ephemeral so you can't use it for a mini app. Bundled exchange you might be able to pul it off but have to talk to packaging folks. If it's delivered in that way then the authenticity of the orgin claim can be guarnateed, unless you're under a dns attack.

Max: that is probably one way.. just thinking about what if .. as one example, for the application store, the platform also needs to check the authenticity of any backend server of the application, so maybe they can use similar mechanism to do that?

Sangwhan: authenticity of the backend application?

Max: for many mobile applications they need a backend.. so when the app developer uploads their app onto the store, eg. google store or iOS store, in their applications they need to talk with their backend server. Similar in this case.

Sangwhan: there's no CORS there. It's native applications, there's no origin model. If you want to treat a mini app as not aprt of the web.. if you lift CORs and the origin model you don't have to care about it. It's a fundamental question of if the origin model exists, in which case it should follow web platform security conventions. Letting the mini app claim an origin when it's offline is in this kind of way is very risky.

Max: former case.. more like application model, not like web model

Sangwhan: then I don't know why we should be reviewing this. Is it part of the web or not?

Max: that will depend on definition of part of the web..

Sangwhan: miniapps run in a browser runtime, therefore the origin model is in there. I'm trying to understand is it going to operate in conjunction with the web's origin model or not. It seems like they're saying they're checking the origin, so presumably there's an origin model, I just don't understand how it's going to work, in confjunction when the paplication is considered online. I't snot an offline application right? It makes reuests to some api service to get data and return it back? What is the origin here, is the main question. example.com makes a mini app and example.com has an api. example.com's api with cors rules only allows access from example.com. Will the mini app have access to this? Should it have access to this? if so how? If it has access is it by disregarding the cors model, or because it claims to be example.com, as with bundled exchanges for example?

Max: my understanding is the mechanism when the mini app registers onto the platform the platform will bind the mini app to certain domains they claim, and the platform will check authenticity of the domain, whether it's owned by the mini app developer or not. When this binding happens the mini app platform can follow the same origin principle to only allow the correct mini app to access the certain domain.

Sangwhan: can this be done in the same mechanism as we do exchanges? Bundled exchanges, signed exchanges?

Max: I'm not sure if they use bundled exchange mechanism or not

Sangwhan: don't need to use it, use the signing mechanism to verify authenticity.

Max: Maybe that can improve the security. Probably useful.

Sangwhan: right now it's up to the app store to decide, and that's a scary model. it depends on whether the app store is prudent and trustworthy.

Max: yes. That happens for other application stores also.

Sangwhan: but it's not the case for the web. That's where I'm concerned. If you disregard entire security model of the web then this is fine. Also any link you visit in the mini appp will operate under the same scary security model

Max: mini app itself follows the same origin principle, but for the authenticity check part this is done by the mini app platform. But for the application it will follow the same origin principle

Sangwhan: I don't think having the app store / platform signing off on it is a good idea

Max: maybe that part does not belong to the web standard, but for the mini app itself still follows same origin, only the mini app application can access the backend server, no other mini app can

Sangwhan: if you change the model like that, the same origin principle doesn't hold the same kind of guarantees or safety that we have in the past. That's the part where I'm concerned. Having an origin backed model like how we do signed exchanges is probably better solution than having an intermeidary. There are ways to do it.

Max: leave a comment?

Amy: is this a centralisation issue?

Sangwhan: worse - the intermeidary can act as a man in the middle to.. we have to .. mini app model puts a lot of trust on the app store. It can issue any number of apps claiming any number of domains. Has the power to issue an app claiming the origin is google.com

Max: as a developer if you have your own dns server you can also do that. This is not the problem web standards can solve.. a regulation problem. If I buy a DNS server I can put google.com..

Sangwhan: that's man in the middle. But you can't get a cert issued by a cert authority

Max: for the mini app case it will not get a certificate either. Technology cannot prevent that. That is what happens

Sangwhan: this is solveable, it's been solved. Signed exchanges and bundled exchanges is that exact mechanism. At the origin the package is signed, and it's passed through non trustworthy cdns and validated by the client.

Max: just saying for the dns examples you mentioned, that is a different case. I agree that we can suggest to the authors to consider the packaging security mechanism..

Sangwhan: I'm very concerned that this gives too much control to the app stores. I don't think

Max: I don't understand.. app store model works in the real world. App store is not part of the standard.

Sagnwhan: origin alidation must be part of the standard.

Max: mini app does the authentication with the origin

Sangwhan: the end to end validation needing an intermeidary, that's the part that's..

Max: only the registration process. That is not in the mini app spec itself, that is an operational thing or business model thing. Jus tlike what application store does today.

Sangwhan: i disagree. This security model is not something that works or that we should be promoting.

Max: need to discuss concrete problems

Sangwhan: there are technical solutions to this that are not being evaluated

Max: concrete uestion first. We can ask the authors to consider the packaging security mechanism. But the whole packaging mechanism... google and ios..

Sangwhan: there's no same origin in native apps.. I'll leave a comment and we can discuss in plenary

Amy: Anything with a centralised point of deciding which apps do and don't get to exist.. raises red flags for me. And we see that in practice with native app stores today, too.

Sangwhan: and on top of that we're breaking the security model on a web browser based runtime

Comment by @cynthia Apr 5, 2022 (See Github)

In the updated explainer, I see this: "When a MiniApp is launched, its hosted Super App or OS will check the origin of the MiniApp, to guarantee the MiniApp's security."

How does it check the origin?

Comment by @QingAn Apr 11, 2022 (See Github)

In the updated explainer, I see this: "When a MiniApp is launched, its hosted Super App or OS will check the origin of the MiniApp, to guarantee the MiniApp's security."

How does it check the origin?

MiniApp developer can submit its MiniApp domain to the backend MiniApp platform, which is provided by the hosted Super App or OS vendors. The MiniApp platform will check and determine whether the MiniApp domain can be permitted, and register the MiniApp domain if permitted.

Then, after a MiniApp is launched, when the MiniApp sends a request, its hosted Super App or OS will check with the backend MiniApp platform, on whether the domain of request has been registered in the MiniApp platform, so to guarantee the MiniApp's security.

Comment by @cynthia Apr 19, 2022 (See Github)

The MiniApp platform will check and determine whether the MiniApp domain can be permitted, and register the MiniApp domain if permitted.

Does this mean that an intermediary (the MiniApp platform) gets to sign off on the MiniApp's origin? I have some grave concerns about that approach. Have you considered adapting a model where the intermediary is only a delivery mechanism, such as what was done in exchanges?

Comment by @QingAn Apr 19, 2022 (See Github)

Does this mean that an intermediary (the MiniApp platform) gets to sign off on the MiniApp's origin? I have some grave concerns about that approach. Have you considered adapting a model where the intermediary is only a delivery mechanism, such as what was done in exchanges?

I guess we have different understanding of origin in the context of MiniApp.

"its hosted Super App or OS will check the origin of the MiniApp". Here, I think the "origin" might cause some confusion. The more suitable description is "hosted Super App or OS will check the validity of the MiniApp's request URL domain".

In detail, in the first step, MiniApp developer need to submit its MiniApp domain along with the MiniApp package to the backend MiniApp platform, which is provided by the hosted Super App or OS vendors. The MiniApp platform will check and determine whether the MiniApp domain can be permitted. If permitted, the MiniApp domain can be registered. This part is more like a business policy, which is out scope of MiniApp standard.

Then, when a MiniApp is firstly launched, its hosted Super App or OS will download the MiniApp package from the backend MiniApp platform. And the MiniApp runtime is responsible for checking the validity of MiniApp's request URI domain. If the domain has been registered in the MiniApp platform, then a WebView will be called to open and render the new page identified by the request URI. Same-origin Policy is handled by WebView.

Discussed May 1, 2022 (See Github)

Dan: comment in April to Sangwhan's feedback.

Max: from previous discussions sangwhan wants to try to look at the detail of the implementation.. any progress?

Sangwhan: not yet. If my interpretation is correct I disagree with this being a safety mechanism. Does this group have regular calls?

Max: yes

Sangwhan: I don't understand, the mini app platform - the app store - gets to decide if a certain publisher has claims over a certain origin. They claim this is a business policy outside the scope of the standard. I don't think it's a safe mechanism

Dan: i thought we determined that the mini apps were being served from the actual origin

Sangwhan: that's what I was told but there's conflicting message here.. let me get to the bottom of this.

Dan: you could imagine a straightforward approach to this. It's about server configuration and DNS configuration. You could have a centralised store that is serving these mini apps but have a CNAME assigned from starbucks or whatever so that it's actually served from the domain of the app. At any rate I thought that's what we were told earlier in the discussion

Sangwhan: that's what I was told but when I read the spec there seems to be packaging and origin involved and that's the part I don't understand. Who gets to decide whether this app is worthy of this origin because there's no origin associated with the app package once it goes into the app store. Comment suggests the app store signs off on that. Say Dan submits an app claiming this is from torgo.com.. this thing exchanges prevents you from signing off... certificate validation changes..

Dan: there's no way to see the URL or certificate validity or anything like that but the root question remains is it using the web security mechanisms even so?

Discussed Jul 1, 2022 (See Github)

Max: Sangwhan wanted to have more exploration of this - we can ask his opinion when he's back.

Dan: issue of concept or origin

Max: answer regarding it breaks the same origin principle or not... from the explanation from their answers they believe that it will not break the same origin principle. What it says in the spec - the miniapp platform

Dan: the miniapp UA .. the miniapp comes from the origin (e.g. starbucks.com) and operates under that origin - so operates under the web security mdoel.

Max: yes that's what the authors explained.

Discussed Aug 1, 2022 (See Github)

Dan: we closed manifest?

Sangwhan: yeah that one is satisfactory. There's package as well..

Dan: we discussed at f2f. The question was is the origin of the miniapp.. is the miniapp retreived from the origin, or from an intermediary that tells the client that it is the origin in some way? If that is the case, is that a strong enough indication? But the indication we got from the miniapp group is that it is actually retreived from the origin.

Sangwhan: there is also a packaging proposal that just hit us..

Sangwhan: I still disagree with the fact that this is about the last comment in lifecycle... there's a fundamental flaw in the security model. Seems like we're talking past each other.

Dan: we can close it with unsatisfied or satisfied with concerns. Security model seems like a fundamental thing. If we can't square that it doesn't make sense to close satisfied. Other approach would be to try to have a more high bandwidth discussion with the mini apps folks. Maybe we should try to facilitate that, maybe Yves could help bring in some w3t who are working on this to help bridge the gap? I think some of it is a communications issue.

Max: that would be better than just closing unsatisfied

Dan: I'll take the action to talk to Yves to set something up

Comment by @torgo Aug 9, 2022 (See Github)

Just noting here that we discussed in today's TAG breakout and we agreed we need to have some more high bandwidth discussion both on this and on #762.

Comment by @QingAn Aug 30, 2022 (See Github)

Does this mean that an intermediary (the MiniApp platform) gets to sign off on the MiniApp's origin? I have some grave concerns about that approach. Have you considered adapting a model where the intermediary is only a delivery mechanism, such as what was done in exchanges?

I guess we have different understanding of origin in the context of MiniApp.

"its hosted Super App or OS will check the origin of the MiniApp". Here, I think the "origin" might cause some confusion. The more suitable description is "hosted Super App or OS will check the validity of the MiniApp's request URL domain".

In detail, in the first step, MiniApp developer need to submit its MiniApp domain along with the MiniApp package to the backend MiniApp platform, which is provided by the hosted Super App or OS vendors. The MiniApp platform will check and determine whether the MiniApp domain can be permitted. If permitted, the MiniApp domain can be registered. This part is more like a business policy, which is out scope of MiniApp standard.

Then, when a MiniApp is firstly launched, its hosted Super App or OS will download the MiniApp package from the backend MiniApp platform. And the MiniApp runtime is responsible for checking the validity of MiniApp's request URI domain. If the domain has been registered in the MiniApp platform, then a WebView will be called to open and render the new page identified by the request URI. Same-origin Policy is handled by WebView.

FYI, some update has been made to MiniApp Lifecycle explainer, trying to describe MiniApp origin

Comment by @ylafon Feb 13, 2023 (See Github)

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.

  1. 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.

  1. 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.

Comment by @QingAn Feb 22, 2023 (See Github)

@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.

  1. BLOCKER: Package can be modified by the intermediary
  1. ZIP

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

Comment by @torgo Mar 21, 2023 (See Github)

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

Comment by @QingAn Mar 21, 2023 (See Github)

@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.

Discussed Aug 1, 2023 (See Github)

Max: they have made some progress... comment yesterday - they have a proposal for our concerns...

https://github.com/w3c/miniapp/issues/195#issuecomment-1525435423

  1. Origin Model - they proposed a detailed solution there...

  2. package can be modified ...

  3. Zip format ...

Dan:... talking about using something parallel to TLS...

Sangwhan: they can't use TLS out of the box so ... i'm sympathetic. It's an improvement! Need to take a look at this [more deeply].

Dan: i think it's positive and they are addressing our concerns... so deservers strong positive response.

Sangwhan: other question - does it provide the same level of security guarantees? I will digest this myself...

Dan: concerned it allows another party to get in the middle of the train of trust...

Sangwhan: delegation to a trusted party -- could be same as the mechanism of trusting a CDN - could look at it from that angle. Or "end to end guarantees" as with traditional TLS... Taking the CDN architecture into the picture ... "Signed exchanges" is an example of "we don't trust CDNs".

Max: They are trying to do this end-to-end - we can ask them to clarify ... that would be helpful...

Dan: leaves comment

Comment by @xfq Aug 28, 2023 (See Github)

Several rounds of discussions have been held among MiniApp vendors in the WG, and a solution to the above three concerns has been proposed: https://github.com/w3c/miniapp/issues/195#issuecomment-1525435423

Any comment on this proposal?

Comment by @torgo Aug 29, 2023 (See Github)

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.

Discussed Feb 1, 2024 (See Github)

Yves: feedback we already gave still stands...

Discussed Feb 1, 2024 (See Github)

Max: progress is happening - We can ask XFQ to give us and update...

Dan: it would be good to know what the current state is with the proposed code signing solution... sends XFQ a note

Comment by @torgo Feb 12, 2024 (See Github)

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.