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

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

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

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.

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

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.

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]

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.

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

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?

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.

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

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

Yves: feedback we already gave still stands...

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