Split application manifest outside of the runtime spec

[mounirlamouri]

No description provided.

[marcoscaceres]

Happy to do this.

[hollobit]

I agree. I think there are many consideration point about application manifest specifications.

• API usage notification using manifest
• more detailed specification
• Application manifest validation
• using another manifest format (e.g. microdata format in HTML)

so I think it would be good to split application manifest.

[marcoscaceres]

@hollobit, I think "application manifest validation" and "using another manifest format" might be out of scope.

With regards to "application manifest validation", this is generally left up to app stores to do. I.e., they won't accept manifests that are missing certain things (e.g., description). See, for example: https://marketplace.firefox.com/developers/validator

However, such validation is for quality of service on the market place side, but has limited effect on the manifest specification itself. For example, currently, a manifest is only required to have a name, which can be empty:

{ "name": ""} 

With regards to "using another manifest format", the only other format I'm aware of is Apple's various <meta> elements to denote an installable app. I'm not sure if we want to standardize some of those. I don't think we should standardize yet another format.

[marcoscaceres]

@hollobit can you provide a bit more detail on what you mean by "API usage notification using manifest"?

[hollobit]

@marcoscaceres I figure out as the permission notification on Google Play.

https://play.google.com/store/apps/details?id=com.beaglemap.tranggle&feature=editorial-apps_promotion_apps_outdoor_kr#?t=W251bGwsMSwyLG51bGwsImNvbS5iZWFnbGVtYXAudHJhbmdnbGUiXQ..

THIS APPLICATION HAS ACCESS TO THE FOLLOWING:
SERVICES THAT COST YOU MONEY
DIRECTLY CALL PHONE NUMBERS
Allows the app to call phone numbers without your intervention. This may result in unexpected charges or calls. Note that this doesn't allow the app to call emergency numbers. Malicious apps may cost you money by making calls without your confirmation.
SEND SMS MESSAGES
Allows the app to send SMS messages. This may result in unexpected charges. Malicious apps may cost you money by sending messages without your confirmation.

[hollobit]

@marcoscaceres "using another manifest format". I was thinking for Hosted Web Application.
Just for Fully Hosted Web Application (like as general web application), I think a microdata format would be reasonable method to provide simple manifest information. :P

[marcoscaceres]

@hollobit yes, I can imagine that using Microdata could have worked too ... though there are some advantages to having a single JSON file that can be used/indexed independently of the application itself - the JSON file encapsulates the meta data of the application without needing every HTML page in the application to contain this information also. From that perspective, I think having a separate JSON resource was the right solution.

[marcoscaceres]

@hollobit regarding the permission notifications, we discussed that at the F2F. The consensus in the group is that Google Android/Play Store blanket permissions don't work (because users don't understand or read those things - or they only make sense in context). We want to make the APIs "secure by design" ™️ instead.

[jplyle]

I support splitting the manifest spec from the runtime spec. This might even make it possible for an implementation to support the Widget packaging formats but the runtime behaviour and security model.

[marcoscaceres]

...Work started...

[marcoscaceres]

Work complete. Waiting as PR.