Mini Apps

[xfq]

MiniApps are small, install-free, fast-loading programs which typically are run inside other, larger native applications. They use a mixture of native and Web capabilities. Currently, these are mostly used in China. Examples:

• 360 Mini Programs
• Alipay Mini Apps
• Baidu Smart Programs
• ByteDance Mini Programs
• Cube
• HarmonyOS JavaScript Feature Ability (FA)
• JD Mini Apps
• QQ Mini Programs
• Quick Apps (English)
• Weixin/WeChat Mini Programs

Draft WG charter: https://w3c.github.io/miniapp/charters/wg-2020.html

[xfq]

Related discussions:

• TPAC 2018
• Chinese IG report during AC 2019
• Chinese IG F2F on 11 May 2019
• TPAC 2019 breakout session
• TPAC 2019 Advisory Committee meeting
• TPAC 2019 Chinese IG F2F
• TPAC 2020 breakout session 1
• TPAC 2020 breakout session 2
• Discussions about the English name

Related documents:

• Specs
• MiniApp Standardization White Paper

[xfq]

We should also figure out the security story for Mini Programs & Quick Apps.

[xfq]

360 Mini Programs is the first implementation that supports desktop.

[tidoust]

The MiniApps Ecosystem Community Group was created following discussions at TPAC, to incubate work on MiniApps and serve as a base for analysis and proposals of specific work items.

[xfq]

There are discussions about creating a working group for MiniApps.

Here's the draft WG charter: https://w3c.github.io/miniapp/charters/wg-2020.html

Issues can be filed in https://github.com/w3c/miniapp/issues

[svgeesus]

Te mention of mapping makes me wonder whether the work of the Maps For HTML Community Group should be examined.

The different requirements for mas in browsers and for maps in MiniApp could also be stressed in the charter (if there are any).

[xfq]

Agreed. Filed an issue here: w3c/miniapp#74

[xfq]

Related standardization effort in IEEE SA: https://standards.ieee.org/project/2858.html

[samuelweiler]

Discussed in Strategy meeting 26 May 2020: https://www.w3.org/2020/05/26-strat-minutes.html#item01

Some follow-up in these issues:
w3c/miniapp#75
w3c/miniapp#76
w3c/miniapp#77
w3c/miniapp#79

[samuelweiler]

On the security side, I'm concerned that miniapp environments (superapps) will (and do) bypass many of the protections we've already build in browsers. Merely attesting to the origin of code packages is not enough - I'm interested in how they handle isolation and injection protection - and I'm leery of reinventing something that has already had so much effort put into it. In summary, there needs to be a stronger security story here, particularly to justify the bypassing of browser protections.

Similarly, I'm concerned that duplicating APIs (e.g. device and sensor APIs) in these environments will bypass protections - particularly for fingerprinting - that we have worked hard to get into the our web APIs. Is there a way to start with the baseline of the web APIs, with the protections we've already specified for those?

See also the open issue re: operational considerations: w3c/miniapp#76

[xfq]

Merely attesting to the origin of code packages is not enough - I'm interested in how they handle isolation and injection protection - and I'm leery of reinventing something that has already had so much effort put into it. In summary, there needs to be a stronger security story here, particularly to justify the bypassing of browser protections.

I am no security expert, but here's my preliminary analysis on isolation and injection protection:

• Since most MiniApp implementations disallow dynamic code loading like eval and new Function, XSS is very difficult;
• MiniApps usually have a domain name safelist, to permit scripts contained in a MiniApp to access data from a URL only when the domain name is in the safelist;
• Since MiniApps restrict the use of cookies, CSRF attacks is harder in MiniApps than normal web apps.

I think we should open a separate issue in https://github.com/w3c/miniapp/issues to discuss this issue.

Similarly, I'm concerned that duplicating APIs (e.g. device and sensor APIs) in these environments will bypass protections - particularly for fingerprinting - that we have worked hard to get into the our web APIs. Is there a way to start with the baseline of the web APIs, with the protections we've already specified for those?

This is tracked in w3c/miniapp#79

See also the open issue re: operational considerations: w3c/miniapp#76

Thanks for opening this issue. I'll discuss it with the CG.

[himorin]

no comment/suggestion pointed from i18n.

[michael-n-cooper]

APA asks @ruoxiran to help review this for accessibility considerations.

[chaals]

Isn't this in the chartering phase per https://www.w3.org/mid/8323ed3a-7f77-d6dc-b779-4f2404addc6e@w3.org (in the "funnel")

[xfq]

I agree. I've moved it to "Chartering".

[brewerj]

Accessibility comment is here: w3c/miniapp#139 (comment)

[wseltzer]

Charter under AC review: https://lists.w3.org/Archives/Public/public-new-work/2020Nov/0007.html

[samuelweiler]

Results (limited visibility): https://www.w3.org/2002/09/wbs/33280/miniapps-charter-2020/results

[xfq]

WG formed: https://www.w3.org/blog/2021/01/w3c-launches-the-miniapps-working-group/

[svgeesus]

I see that Apple iMessage (a native application) allows Apps to be hosted inside it, and wonder if that would count as Mini Apps?

https://developer.apple.com/design/human-interface-guidelines/ios/extensions/messaging/

[xfq]

@svgeesus iMessage can host other applications indeed, but it uses the Messages framework instead of Web technologies, so I think it depends on how we define MiniApps.

The current definition in the MiniApps WG is in the white paper and the MiniApp Packaging spec.