FAQ about the proposed MiniApp standards work

[lianqi]

While we are moving the MiniApp standards work forward in W3C, especially the charter of the proposed MiniApp Working Group, some initial feedbacks have been received. Some of the feedbacks express questions and concerns about the possibility of MiniApp standards forking currently Web technologies. It would be very necessary for the MiniApp vendors to clarify the concerns and justify the work of current MiniApp specifications. So I would like to propose a FAQ document to explain the rationale behind the proposed MiniApps standards work. Here are some initial question list in the FAQ. More questions and answers are welcome.

1. Is MiniApp a part of Web Platform? What is the relationship between MiniApp and Web Platform?
2. If MiniApp uses certain parts of Web technologies, how come it runs without a browser engine?
3. How is MiniApp Manifest different from the Web App Manifest? Could MiniApp Manifest become a unique case for Web App Manifest? Could MiniApp Manifest be merged into the Web App Manifest?
4. Why there is need to create a new URI Scheme specification? How to use the new URI Scheme specification to handle origin? How to handle SecureContext without origin? How to handle CORS?
5. Is it possible to harmonize Page Lifecycle, Page Visibility, Service Worker Lifecycle, and MiniApp Lifecycle specifications? If so, how?
6. Is it possible for MiniApp packaging to leverage the existing discussions such as signed exchanges and Web Packaging?
7. What is the implementation expectations of MiniApp specifications in the globe? Are the implementations only expected from Chinese MiniApp vendors?
8. Does MiniApp have its own security model?

[xfq]

(I made some editorial fixes to the questions without changing the original meaning.)

[QingAn]

5. Is it possible to harmonize Page Lifecycle, PWA Lifecycle and MiniApp Lifecycle specifications? If so, how?

Not sure the status of PWA Lifecycle, since no link is provided

For Page Lifecycle, it may be possible to harmonize. But MiniApp Lifecycle has its unique requirements that cannot be fully supported by Page Lifecycle.

• Page Lifecycle is Page-level, but MiniApp Lifecycle is App-level, which is composed of multiple pages.

• If only look at MiniApp Page Lifecycle, the onLoad and onReady is not covered by Page Lifecycle.

If W3C community can find common use cases among Page, PWA and MiniApp, it is reasonable to define a harmonized lifecycle. For now, it is recommended to develop MiniApp Lifecycle.

[Ternence]

2. If MiniApp uses certain parts of Web technologies, how does it run without a browser engine?

In principle, any rendering engine, as long as it can correctly parse the structure of MiniApp package, dereference the resources and render UI components or UI APIs cross-platform with no difference. No matter what rendering engine is used, it is meet the MiniApp standard.

The implementation method depends on user agents. If a user agent does not use a browser engine, it needs to realize the runtime of converting front-end source code to native source code, render template in native, and realize the mechanism of communication between native and JS.

6. Is it possible for MiniApp packaging to leverage the existing discussions such as signed exchanges and Web Packaging?

Signed exchanges were designed to perform cross-origin trusted exchange through digital certificates. The current MiniApp Package specification is still a centralized design and has not yet designed a cross-origin miniapp packages sharing solution. Currently, we are designing the digital signature in the package proposal, if there is no better design than using a digital signature chain, we can refer to the signed exchanges.

8. Does MiniApp have its own security model?

MiniApp user agent has a security model, including the following:

• View: MiniApp can not access DOM and global object window, user agents provide high-level components and APIs to makes that feasible.
• Framework:
  • Use package digital signature checking when fetching and processing packages.
  • Perform permission management on some components and APIs.
• Network:
  • Using HTTPs to transmit miniapp packages
  • Using domain name whitelist to restrict the requests from miniapp
  • Restrict the use of cookies
• Storage:
  • the file access is isolated, only the user folder of the miniapp can be accessed
  • the storage path is limited, and the real physical address is hidden

[xfq]

Is it possible for MiniApp packaging to leverage the existing discussions such as signed exchanges and Web Packaging?

See also the explainer of the Packaging spec.

[Sharonzd]

4.1 Why there is a need to create a new URI Scheme specification?

Because other schemes may not satisfied with the status of MiniApp, mainly including the following reasons: The first and most important reason is that there is no centralized package service like "https://miniapp.com"; Second, We hope there is an easier way to judge miniapp uri in advance to preload runtime; What's more, Some manufacturers(user agents) want more flexibility, such as using other protocols to fetch package; See also this issue #34 .

4.2 How to use the new URI Scheme specification to handle origin?

The new URI Scheme used Host and port to identify the origin. And when we use https to download MiniApp packages, the origin conform to the rules in HTTP origin

4.3 How to handle SecureContext without origin?

If there isn't an origin, it may be a local debugging scenario. Since the miniapp package just used for debugging which will not spread across the web or across the platform, so strict security model is not required. User agents can verify it according to the actual situation. Usually, miniapp uri requires an origin. And, in fact, the current manufacturers still use the https protocol to download miniapp packages. The minapp uri is only used to identify that this is a miniapp(in advance), and where to download packages, and which miniapp need to download, and what page to open after downloading. So, in this case, the miniapp can be considered to be in a secure context.

4.4 How to handle CORS?

Now we use a built-in domain name whitelist to allow CORS and ensure security. Each miniapp would configure the domain name whitelist on the package management platform before it is released. The user agent only allows requests to the domain name in the whitelist. And a minapp developer server would also allow the request from the MiniApp origin.

[xfq]

Is MiniApp a part of Web Platform? What is the relationship between MiniApp and Web Platform?

If "web platform" means the browser environment, then the answer is no. MiniApp uses many web technologies like CSS and JavaScript, but its operating environment is far beyond the limit of the browser, and does not depend on the existence of the same-origin policy.

https://www.w3.org/TR/webarch/ is a document for the architecture of the Web. We should probably look into it to answer this question.

See also: https://www.w3.org/wiki/Open_Web_Platform and https://www.w3.org/2001/tag/doc/IAB_Prague_2011_slides.html

[zhangyongjing]

Is it possible for MiniApp packaging to leverage the existing discussions such as signed exchanges and Web Packaging?

It's not feasible to reuse Signed Exchanges/Web Packaging (WPACK) for MiniApp since the design purposes are quite different. MiniApp package is basically to pack the resources (e.g. page layouts, UI components, app logics) that comprise a mobile app (which happens to be JS-based), while WPACK is to pack HTTP exchanges (requrests and responses) which are not the building blocks of a MiniApp. Using web technologies doesn't change the nature of MiniApp as a mobile app rather than a web app. The HTTP-oriented design of WPACK is not suitable for MiniApp. The runtime envrionments are also different (App/OS-based vs. browser-based) hence the archiving and parsing requirements are different too.

See detailed analysis in the MiniApp Package Explainer

[xfq]

I committed an initial draft based on the comments above and yesterday's discussions: https://github.com/w3c/miniapp/blob/gh-pages/docs/FAQ.md

Pull requests are welcome.

[lianqi]

Q7. What is the implementation expectations of MiniApp specifications in the globe? Are the implementations only expected from Chinese MiniApp vendors? A: If MiniApp related specifications become W3C recommendations, the implementation expectation is the same with every other W3C Rec, meaning global implementation. And there is a good reason for it. MiniApp as a new type of application, has been gaining popularity in more counties other than China, such as in Japan and Korean. And very recent news shows that there have been similar efforts in the US market as well. There is a good possibility that MiniApp might eventually become a global phenomenon, and we do hope the MiniApp specifications that incubated and developed by the MiniApp CG (and later by the WG) would be embraced globally. And the MiniApp CG cordially invite the global community to cooperate on MiniApp specifications together.

[xfq]

Some parts of the FAQ need to be updated, but since we have a relatively complete FAQ now, I suggest that we close this issue and discuss the parts need updating in separate issues or PRs.

[zhangyongjing]

Some parts of the FAQ need to be updated, but since we have a relatively complete FAQ now, I suggest that we close this issue and discuss the parts need updating in separate issues or PRs.

I agree.