MiniApp Packaging
Home Page: https://w3c.github.io/miniapp-packaging/
License: Other
This repository is the home of the MiniApp Packaging specification being worked on by the MiniApps Working Group.
https://w3c.github.io/miniapp-packaging/#file-names
File Names MUST NOT exceed 255 bytes.
What if the file name is more than 255 bytes? Will the file name be truncated? The i18n WG has related guidelines here: https://w3c.github.io/bp-i18n-specdev/#char_truncation
Hi guys, I have been reading this spec recently and I think the mini app is an amazing idea (Yes I am user of some of the Wechat MiniApp as well).
Beside the whole concept of miniapp, I found this section very interesting to me https://www.w3.org/TR/mini-app-white-paper/#constructor
A MiniApp package is a compressed format (e.g. zip) archive, including:
I wonder if could consider epub as a container? or if you have explored already?
I am very interested in the possibility of using epub package since I am also co-chairing the publishing cg. If you would like to share the idea of mini app can we have some joint meeting to introduce mini-app to publishing cg?
This issue is being filed as part of PING wide review.
Section 1.1. seems to require the runtime load all mini-app resources at once, instead of loading them as needed.
After retrieving the MiniApp ZIP container, the MiniApp user agent loads the static page templates, stylesheets, JavaScript files, and other resources into the cache, following a dereference and processing algorithm. These MiniApp resources will remain available in the cache until the next update, avoiding unnecessary network fetches.
This seems like it would be a very expensive choice, especially if the miniapp contains a lot of code or subpages that the user might never use. Is this needed? Are runtimes prohibited from loading resources on demand / lazing loading? If so, it might be worth reconsidering, since this seems an expensive option. If not, i suggest clarifying Section 1.1.
This is not a blocking privacy issue, but I'm mentioning it since it came up during the review
Don't need to worry about it now, but the application/miniapp-pkg+zip media type should be registered with IANA "one to two months prior to Candidate Recommendation" (https://www.w3.org/2020/01/registering-mediatypes).
Raising issue per action 01 of CG meeting on Jun 17, where we discussed the issue w3c/miniapp-lifecycle#8 (Update mechanism of MiniApps).
Apart from the possible effects in terms of lifecycle (i.e., trigger events, change status) we commented that the update mechanisms of MiniApps might affect mainly the Packaging and Manifest specs.
The MiniApp Packaging spec includes an algorithm for fetching and processing the package. So, the update mechanism may affect this algorithm. So far, the user agent fetches the package and process it once. Should we include additional metadata (in the Manifest?) to indicate how/when to update the package?
The current package processing algorithm would finish when the MiniApp reaches the launched status, so we could extend the algorithm to update the package once the MiniApp is launched.
Comments?
I'm not a security expert, here are just a few security and privacy related considerations I can think of for the WG to discuss. We can split them into separate issues if needed.
Per Privacy Reviews Guidelines, we need to have a Privacy Considerations section, separate from Security Considerations.
Some things we may want to add about security and privacy include:
We can add some recommendations for MiniApp implementers, such as:
User agents should examine all vectors of attack from a MiniApp package and protect against them, such as attack of one MiniApp against another in the same user agent, or pretending to be another MiniApp or website in order to steal user information.
MiniApp user agents should also check the package for malicious scripts, links, remote resources, and so on.
User agents should isolate MiniApps from each other. On the same device, user A must not be able to read user B's data in the local storage; and different MiniApps must not read and write data in the local storage to each other.
Some MiniApp user agents may collect user data. We should recommend user agents to be clear about the data being collected and how it is used.
In addition, many MiniApp implementations (like 1 2 3 4) disallow dynamic code loading like eval and new Function as a defense mechanism to stop XSS attacks. Currently, it is not mentioned in the Scripting Resources section. Should we consider standardizing this?
Should we write some security and privacy recommendations related to the developer of MiniApps, such as using HTTPS when requesting resources?
This issue is being filed as part of PING wide review.
A fair amount of this spec defines what characters can be used in filenames (Section 2.1.5.). This text seems highly redundant with existing text in other W3C notes and documents (for example, https://www.w3.org/TR/international-specs/#file_naming). If possible i suggest your spec not have its own rules for deciding which filenames are legal, and instead refer to other existing documents / specs
This is not a blocking privacy issue, but I'm mentioning it since it came up during the review
From the perspective of different browser usage scenarios and requirements, We should consider the scalability of the MiniApp packaging method.
Such as, the Chrome Browser needs the security of cross-domain resource access. The package specification of Web-Packaging is recommended, which makes more reliable signatures checking for offline resource access and sub-package loading (Fetch). WICG/webpackage
I suggest that the package structure specification of the MiniApp should consider the requirements of different packaging formats. Write a chapter to provide an extensible packaging mechanism. Through different packaging algorithms and format standards, packaging the development code into different formats, which can support the expansion of different file formats.
Using this way. the MiniApp Package will widely be distributed internationally and compatible with browsers.
https://w3c.github.io/miniapp-packaging/#file-names
Non characters in Arabic Presentation Forms-A (U+FDDO … U+FDEF)
U+FDDO should be U+FDD0 (zero instead of oh) here.
MiniApp Packaging, section 1.4 ‘i18n’
https://w3c.github.io/miniapp/specs/packaging/#i18n
The I18N WG reviewed the editors' draft a first time and noticed that section 1.4, ‘i18n’, probably needs additional review. But the section isn't sufficiently written yet. What are the plans for that section?
In the Packaging spec we are specifying the algorithms for processing a MiniApp. So far, the specification includes the first step for retrieving the package, the setup based on the manifest, and the initialization of the platform, before launching the MiniApp.
The Lifecycle specification defines MiniApp Initialization, and the event related to this status, launched. So, the processing algorithm should include this change in the global status. This global status means that the MiniApp initialization is completed, so we should indicate how this initialization is complete.
So far, the algorithm has a step the platform runtime preparation that contains:
Do we need other specific intermediate steps (or change the existing ones) to configure both the logic and the rendering engines before changing the global status to launched?
Per MiniApps WG charter:
Each specification must contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximizing accessibility in implementations.
https://github.com/w3c/miniapp-packaging/blob/main/docs/explainer.md#the-package-content says the page-specific configuration is under discussion, but in #3 we decided it's optional. We should reflect that in the explainer.
We may not need such a file (page.json) for mini app packages.
While crawling MiniApp Packaging, the following links to other specifications were detected as pointing to non-existing anchors, which should be fixed:
This issue was detected and reported semi-automatically by Strudy based on data collected in webref.
https://w3c.github.io/miniapp-packaging/#sec-accessibility
The Accessibility Considerations section is non-normative, but contains many RFC 2119 key words. I think the best practice is to avoid using these key words in non-normative sections (and use them carefully in normative sections). We could consider changing this section to normative or changing the wording. I have bolded the relevant key words:
The MiniApp Packaging specification requires user agents to process the MiniApp container and its content to generate a user interface and a concrete behavior based on the internal resources (i.e., HTML, stylesheets, scripting, and others) and the configuration (i.e., manifest, app.ux). User agents must ensure that the user interface and rendered content after the package processing and load are perceivable and operable under all circumstances and in every potential scenario. User agents must enable the configuration of different stylesheets to adapt the appearance to the user’s requirements, also offer the possibility to configure and control the display and the orientation of windows and viewports, as required by some members of the
manifest.json(MiniApp Manifest).
Although not specified in this document, it is recommended that user agents guarantee the accessibility aspects in the user interaction, like offering full keyboard access or support alternative input devices (if feasible) and enabling users to store the preference settings to facilitate interaction. MiniApp user agents and platforms should provide mechanisms for rendering and interacting with the application, facilitating the integration of assistive technology, and complying with applicable specifications and conventions, particularly the User Agent Accessibility Guidelines (UAAG) 2.0.
https://w3c.github.io/miniapp-packaging/#file-names
All File Names within the same directory MUST be unique following case normalization as described in section 3.13 of [Unicode].
This sentence does not seem to be very clear. Please refer to Case Mapping and Case Folding and Additional Considerations for Case Folding in charmod-norm.
See https://w3c.github.io/epub-specs/epub33/core/#sec-container-filenames (and related PRs w3c/epub-specs#1648 and w3c/epub-specs#1692 ) for an example.
The spec uses the term "file name" in the same way as the term has been used in english for decades. I suggest removing it from the glossary.
https://w3c.github.io/miniapp/specs/packaging/
If the package is within a ZIP archive, we should write that in the document and add a reference to ZIP. We also need to specify whether features in ZIP like encryption are allowed.
The TAG wrote a feedback document on MiniApps: https://github.com/w3ctag/design-reviews/blob/main/reviews/miniapp_packaging_feedback.md
We need to discuss it, and possibly organise teleconferences with the TAG and/or Web Bundles folks.
The "is launched" link in https://w3c.github.io/miniapp-packaging/#sec-miniapp-platform-start-page-identification is 404.
/cc @espinr
https://w3c.github.io/miniapp-packaging/#sec-miniapp-processing-retrieval
Let resource be a MiniApp ZIP container as a result of fetching a URL [HTML5], passing miniapp_uri.
It links to a very old version of HTML5. We should probably change it to https://fetch.spec.whatwg.org/#concept-fetch
We need to answer the W3C Security and Privacy Questionnaire.
Some implementations use a streaming format to download and load packages to optimize the MiniApp load time. Is it worth specifying?
As an example, ByteDance Mini Programs use their own ttpkg package format instead of a zip package, so they don’t need to wait for the complete package to be downloaded before they can load it.
(Sub-packaging is another feature that reduces loading time, and a MiniApp platform can implement both of them.)
As a requirement for transitioning to Candidate Recommendation the group:
MUST show that the specification has received wide review
To satisfy this requirement, we can use this tracker issue as evidence that wide review from horizontal groups has been received.
The group is still discussing about the formats, document definition and manipulation (see issue #2)... In my opinion, the specification of the content (templating/binding/DOM manipulation) should be outside the Packaging spec (as its name indicates, it's just about the "envelope" and the processing of it). In any case, we should indicate the type of files and resources.
So, my question is if we should propose a new deliverable that complements the UI Components spec to describe the content of a MiniApp. So the packaging can be described in a generic way (structure and ZIP format), and the "MiniApp Content" specification may define how a MiniApp page is created in terms of:
This is something similar to the approach followed by the EPUB group. Since it is not part of the charter, I suppose we need to start it from the CG.
Opinions?
Line 741 in a5ab18f
Because there is no h7 in HTML, we should use another method to write this markup.
https://w3c.github.io/miniapp-packaging/#sec-miniapp-i18n
The link to and name of BCP 47 was created specifically so that there is an unchanging reference to the definition of language tags. RFC4646 and RFC4647 are not the recommended method to refer to IETF language tags.
BCP 47 contains one RFC dedicated to the syntax and subtags of language tags, and another dedicated to specify items in a user's list of language preferences.
This issue is being filed as part of PING wide review.
The privacy considerations section seems to prohibit implementations from deleting or clearing user storage.
End-users MUST decide whether to remove the information stored by the user agent, corresponding to any MiniApp instance.
Since this information can include user identifiers and other sensitive information (depending on the purpose of the MiniApp), this seems to prevent implementors from taking steps to limit the lifetime of these stored identifiers (or take other steps on behalf of users to improve user privacy). Requiring users, and only users, to manage what data is stored on their device seems to place a significant responsibility on users to understand the risks and usefulness of long term (and possibly rarely accessed data) which seems to invite possible harm. It seems equivalent to preventing browsers, for example, from clearing long-lived cookies or other similar interventions.
More broadly, I urge the group to revise this text, so that privacy-focused implementations can take steps on behalf of users to protect user privacy, especially in cases where users may be poorly equipped to manage (or even understand) the data themselves.
If the above is not possible, it would be useful to understand why
https://w3c.github.io/miniapp/specs/packaging/
It would be useful to specify which files/directories are mandatory and which are optional.
Per https://www.w3.org/2020/01/registering-mediatypes , media type registration should be a normative part of a specification, but our Media Type Registration section is non-normative.
Case 1： Including multiple root nodes, the page with template reference does not fit xml specs.
Reference：
https://developers.weixin.qq.com/miniprogram/dev/reference/wxml/import.html
https://smartprogram.baidu.com/docs/develop/framework/view_quote/
https://w3c.github.io/miniapp-packaging/#sec-media-type-registration
Applications that use this media type:
This media type is used for the distribution of MiniApps. The list, non exhaustive, of applications and software platforms that support this media type are:
- Alibaba MiniPrograms
- Quick Apps
- Baidu
- ...
"Alibaba" should probably be "Alipay" here.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
