search

w3c / strategy

team-strat, on GitHub, working in public. Current state: DRAFT
158 stars 46 forks source link

Mini Apps #183

Closed xfq closed 3 years ago

xfq commented 5 years ago

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:

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

xfq commented 5 years ago

Related discussions:

Related documents:

xfq commented 5 years ago

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

xfq commented 5 years ago

360 Mini Programs is the first implementation that supports desktop.

tidoust commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Agreed. Filed an issue here: https://github.com/w3c/miniapp/issues/74

xfq commented 4 years ago

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

samuelweiler commented 4 years ago

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

Some follow-up in these issues: https://github.com/w3c/miniapp/issues/75 https://github.com/w3c/miniapp/issues/76 https://github.com/w3c/miniapp/issues/77 https://github.com/w3c/miniapp/issues/79

samuelweiler commented 3 years ago

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: https://github.com/w3c/miniapp/issues/76

xfq commented 3 years ago

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:

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 https://github.com/w3c/miniapp/issues/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 commented 3 years ago

no comment/suggestion pointed from i18n.

michael-n-cooper commented 3 years ago

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

chaals commented 3 years ago

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

xfq commented 3 years ago

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

brewerj commented 3 years ago

Accessibility comment is here: https://github.com/w3c/miniapp/issues/139#issue-735831543

wseltzer commented 3 years ago

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

samuelweiler commented 3 years ago

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

xfq commented 3 years ago

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

svgeesus commented 3 years ago

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 commented 3 years ago

@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.