w3c / miniapp-manifest Goto Github PK

#23 added two new members to the manifest. We should also update the explainer.

window
https://w3c.github.io/miniapp/specs/manifest/#window

The window attribute contains a number of sub-attributes, such a navigationBarTitleText. There doesn't appear to be a way to set the base direction of these text elements or the base direction of a given window. (Similarly the language cannot be separately set)

We need to answer the W3C Security and Privacy Questionnaire.

It would be great if we can follow the TAG guideline for casing: https://www.w3.org/TR/design-principles/#casing-rules

Developers can divide a MiniApp into a few sub-packages, and the user agent can load the sub-packages as needed when the MiniApp is used. Dividing a MiniApp into reasonable sub-packages according to business characteristics can increase the loading speed of MiniApp and optimize the user experience. Should we document this mechanism in the spec?

This may also affect the MiniApp Packaging spec.

While crawling MiniApp Manifest, the following links to other specifications were detected as pointing to non-existing anchors:

• https://www.w3.org/TR/i18n-glossary/#def_unicode_code_point

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

Similar to #43, MiniApp may want to align "req_permissions" with "permissions_policy". Technically, this is for Isolated Web Apps, not regular Web apps (or PWAs), but there is yet another proposal for "permissions" on the table in this Edge explainer

Manifest
https://w3c.github.io/miniapp/specs/manifest/#manifest

The manifest provides a number of "attributes". These start with dir and lang (which is great). But the subsequent natural language attributes don't appear to have their own dir/lang associated with them. It may not be possible to produce a manifest that is localized into more than one language or which has different language or base direction strings in it. The attributes in question are:

• appName
• shortName
• description
• (maybe??) versionName

Based on #56, @Sharonzd commented:

In the existing vendor implementations, if a user approves granting a requested permission from a MiniApp, the permission will remain until the user goes to the MiniApp setting page to cancel the authorization, just like the App authorization mechanism on an iPhone.

I think this is necessary because if the authorization information is only stored in the session, it means that users need to repeat the granting operation every time reopen the same MiniApp, which would reduce the user experience.

Web Applications Working Group is waiting for our feedback about the joint meeting on manifest during TPAC 2022. Any comments?

They meet Monday (12 September) and Tuesday (13 September) from 9 am (which is 08:00 UTC / 16:00 Beijing time) to 5 pm (which is 00:00 UTC / 08:00 Beijing time).

For reference, see also the World Clock Meeting Planner.

/cc @siusin @espinr

• "The MiniApp manifest's app_id member is a string that identifies the MiniApp univocally. This member is mainly used for package management, and it supports the update and release process of MiniApp versioning."—https://w3c.github.io/miniapp-manifest/#app_id-member
• "The manifest's id member is a string that represents the identity for the application. The identity takes the form of a URL, which is same origin as the start URL."—https://www.w3.org/TR/appmanifest/#id-member

Per w3c/miniapp#90 (comment) we should probably specify the algorithms for processing the manifest.

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.

• Technical Architecture Group
  • Review request: w3ctag/design-reviews#752
  • Feedback: w3ctag/design-reviews#752 (comment)
  • Resolution: satisfied
• Security
  • Review request: w3c/security-request#36
  • Feedback:
  • Resolution:
• Privacy
  • Review request: w3cping/privacy-request#97
  • Feedback: https://github.com/w3c/miniapp-manifest/issues?q=is%3Aissue+label%3Aprivacy-needs-resolution+
  • Resolution:
• Internationalization
  • Review request:
  • Feedback:
  • Resolution:
• Accessibility
  • Review request: w3c/a11y-request#28
  • Feedback: "Looks good to APA."
  • Resolution: N/A

This issue is being filed as part of of PING's horizontal review

The substance of the proposal and its intended use cases are similar to the Web Application Manifest proposal (describing a packaged web or web-like application). It would be ideal to combine these in some way, specify one as an extension to the other, or otherwise remove the complexity of two different nearly-but-not-identical proposals.

If thats not possible, it would be good to at least have some non-normative text in this proposal explaining the relationship of the two specs and (possibly) why they need to be mostly-identical-but-fully-independent specs

This is not a blocking privacy issue, but I'm mentioning it since it came up during the review

The Web App Manifest allows adding new proprietary manifest members using vendor prefixes: https://www.w3.org/TR/appmanifest/#proprietary-extensions

We probably need something similar.

https://w3c.github.io/miniapp-manifest/#pages-member

pages member
During the MiniApp development process, adding or deleting MiniApp pages is done by configuring the list of references. When configuring the page routes, the file name extension MAY be omitted (e.g., /component/mypage).

I have two questions about this.

1. Why is the example /component/mypage instead of something like pages/index? Per https://w3c.github.io/miniapp-packaging/#sec-pages-directory the directory seems to be named pages.
2. What should the developer write when the extension is NOT omitted?

#21 modified the version_code, version_name, and min_platform_version members. We should also update the explainer.

While crawling MiniApp Manifest, the following links to other specifications were detected as pointing to non-existing anchors, which should be fixed:

• https://www.w3.org/TR/appmanifest/#dfn-extension-point
• https://www.w3.org/TR/mediaqueries-4/#display-mode-minimal-ui

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

Only global configuration files are mentioned in the manifest spec currently. Should we mention page configuration files as well?

Docs:

• WeChat Mini Programs
• Alipay Mini Apps
• 360 Mini Programs
• Baidu Smart Programs

Privacy review is part of wide review.

Per https://github.com/w3cping/privacy-request/blob/main/.github/ISSUE_TEMPLATE/request-review-for-a-wd-that-is-moving-to-cr-soon.md , we need to have a Privacy Considerations section, separate from Security Considerations.

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.

As mentioned in w3c/miniapp-packaging#46 and #31, MiniApps user agents are vulnerable to XSS attacks. So we should define a mechanism to enable user agents to restrict the origin of the external resources (i.e., images, stylesheets, media, and other scripts).

About static resources

Most of the MiniApp implementations support external -they are not within the MiniApp package- media resources included in the user interaction components (e.g., Baidu, WeChat, QQ, Quick Apps...), also stylesheets and fonts. In these cases, I haven't found specific limitations in the sources, only constraints related to file formats.

About dynamic resources

Network operations from scripts are different, and some MiniApp versions limit dynamic fetches, downloads, and other networking communications. In most of the cases, they require a safelist of domains in advance (e.g., Baidu, ByteDance, QQ, Weixin). Through different means, developers have to communicate with the platform as a previous step, so this safelist is not included in the configuration manifests. I see a case of a flag in the MiniApp manifest to specify if the external URLs must be checked or not. "settings": { "urlCheck" : boolean }.

A CSP (Content Security Policy)

With these scenarios, we could consider configuring a CSP and restricting the external domains that could dynamically interact with the MiniApp.

Existing CSP directives would allow us to restrict the source of the HTTP resources default-src, connect-src, img-src, script-src, font-src, etc.). However, this solution is not valid for MiniApps because the manifest and components within the package don't have HTTP headers associated. So, one solution is to introduce another member in the manifest to control, at least, the safelist of domains for the network operations performed by the scrips.

Something like:

¨content-security-policy" : 
    {
        "default-src": [ "trusted1.example.org", "trusted2.example.org" ], 
    }

It should be optional, but we also should define a policy by default (something like none or self) to block/allow any external source.

This short review is for the following spec: MiniApp Manifest.

1. If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc), ensure that there’s metadata about and support for basic things such as language and text direction. Also check the detailed guidance for Language and Text direction.

The following members contains natural language text that will be read by a human, and there’s metadata about language and text direction.

• name
• short_name
• description
• MiniApp window resource's navigation_bar_title_text
• MiniApp widget resource's name

They currently share the same language/direction. This issue is tracked in #4

2. If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics. take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.) Also check the detailed guidance for Typographic support.

   • Not applicable

3. If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc. make allowances for the ways different scripts handle units of text. Also check the detailed guidance for Text-processing.

   • Not applicable

4. If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers understand the implications of normalisation, case folding, etc. Also check the detailed guidance for Text-processing.

   • Not applicable

5. If the spec (or its implementation) sorts text ensure that it does so in locally relevant ways. Also check the detailed guidance for Text-processing.

   • Not applicable

6. If the spec (or its implementation) captures user input ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods.

   • Not applicable

7. If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time. Also check the detailed guidance for Local dates, times and formats.

   • Not applicable

8. If the spec (or its implementation) allows any character encoding other than UTF-8. make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct. Also check the detailed guidance for Characters.

   • Not applicable

9. If the spec (or its implementation) defines markup ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements. Also check the detailed guidance for Markup & syntax.

   • Not applicable

10. If the spec (or its implementation) deals with names, addresses, time & date formats, etc ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc. Also check the detailed guidance for Local dates, times and formats.

    • Not applicable

11. If the spec (or its implementation) describes a format or data that is likely to need localization. ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc.

    • Not applicable

12. If the spec (or its implementation) makes any reference to or relies on any cultural norms ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc).

    • Not applicable

Short i18n review checklist is here

The description of window.orientation is currently:

Screen orientation settings, valid values: portrait and landscape.

It is not clear to me if this is just a default orientation when the user opens a MiniApp (the user can change it when using the MiniApp), or a locked orientation (the user can't change it).

This issue is being filed as part of of PING's horizontal review

The proposal says MiniApps can be installed using UI Dialogs, and that the user SHOULD be informed what app they're about to install by presenting the user with the app_id (and other information). Since the app_id (and other fields) are being relied on by the user to make a high-importance trust decision (whether to install the app or not), how should spec implementors validate that the app_id is correct, and not one application impersonating another?

This issue is being filed as part of of PING's horizontal review

The Privacy Considerations section states:

The user agent SHOULD implement mechanisms to remember their preferences, and the end-user SHALL explicitly decide if this information is stored across sessions. No other information related to the manifest should persist across sessions.

What a session is, how long it lasts, etc is not defined in the spec. This is critical to define since "session" is being used as a privacy boundary here (things that stay in one session shouldn't, by default, be available in other sessions). The spec should either define what a session is for MiniApps, or if its defined in another spec, link to where a session is defined

https://w3c.github.io/miniapp/specs/manifest/#widgets

Widgets are a part of a MiniApp. Specifically, a MiniApp package can include MiniApp Pages and Widgets concurrently. As a part of the MiniApp application, widgets share some of the Manifest fields with the MiniApp main program, e.g. dir, lang, appID, appName, shortName, icons, versionName and versionCode. However, a widget also has its private fields, as shown in the following table:

Widget has a name field in the table that follows. What is the character set, length limit/content limits (if any) for this field? Can base direction be set for the widget?

Similarly there is a path field. Should this be understood to be a URL path?

As recommended in #57 , the manifest should align with other proposals under incubation.
I propose using common values to identify the req_permissions, recommending the identifiers of the Permissions Registry.

For instance:

   {
      "name": "geolocation",
      "reason": "To show user's position on the map"
    },

Comments?

https://w3c.github.io/apa/fast/checklist.html

If technology allows visual rendering of content

[✔️] There is a defined way for a non-visual rendering to be created.

It is possible to create a string representing the accessible name of every image resource (icons' label attribute).

[ ] Content can be resized.

The icons can not be resized, but the icons member specifies an array of objects representing image files that can serve as application icons for different contexts. These icons may have different sizes associated (e.g., sizes: "16x16 32x32 64x64")

[ ] Luminosity and hue contrast can adapt to user requirements.

There is currently no way to do this via the manifest. MiniApp developers/authors can develop this feature themselves.

[ ] Text presentation attributes can be changed.

There is currently no way to customize the string representing the accessible name of image resources.

[✔️] Changing content presentation does not render it unreadable.

[✔️] Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.

[✔️] It is possible to make navigation order correspond to the visual presentation.

It seems not to be applicable to the MiniApp Manifest.

If technology provides author control over color

[ ] There is a mechanism for users to override colors of text and user interface components.

User agents may provide such mechanism, but this is outside the scope of this spec.

[✔️] There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually.

[✔️] There is a feature for users to choose color schemata that work for them.

[✔️] The foreground and background color of an object can be reported to the user via AT.

I'm not familiar with AT, but from what I understand it's technically possible.

[✔️] There are ways to set foreground and background colors separately for all objects.

[✔️] Compositing rules for foreground and background colors are well defined.

If technology provides features to accept user input

This specification does not provide features to accept user input.

If technology provides user interaction features

This specification does not provide user interaction features.

If technology defines document semantics

This specification does not define document semantics.

If technology provides time-based visual media

This specification does not provide time-based visual media.

If technology provides audio

This specification does not provide audio.

If technology allows time limits

This specification does not allow time limits.

If technology creates objects that don't have an inherent text representation

This specification does not create objects that don't have an inherent text representation.

If technology provides content fallback mechanisms, whether text or other formats

This specification does not provide content fallback mechanisms, whether text or other formats.

If technology provides visual graphics

This specification itself does not provide visual graphics.

If technology provides internationalization support

[✔️] Accessibility features can be internationalized to the same degree as other features.

If technology defines accessible alternative features

[ ] Accessible alternatives themselves meet the same bar of accessibility.

Text alternatives to image resources do not allow rich content, but it is defined in a separate spec.

If technology provides content directly for end-users

[✔️] Content can be encoded in a manner that allows machine transformation into accessible output.

If technology defines an API

This specification does not define an API.

If technology defines a transmission protocol

This specification does not define a transmission protocol.

appId
https://w3c.github.io/miniapp/specs/manifest/#appid

appID is the ID of MiniApp and is mainly used for the package management. It supports the update and release of MiniApp versions. The naming convention of appID adopts the reverse domain naming rule and uses all lowercases, e.g. com.company.miniapp.

The character set of the appId appears to be limited to Basic Latin (aka "ASCII"), but this is not clear. Domain names do support non-ASCII characters via IDNA, so it isn't clear if this is what is intended.

Note that "all lowercase" is not clear by itself. If the character set is limited to ASCII, this should says "ASCII lowercase".

Is there a reason to limit the appId to ASCII?

In the MiniApp Manifest, the versionCode member represents the version iteration process of a mini app. It is required and it has a value (1) by default.

Should we keep it as it is?