Developer information? - Githubissues

jcayzac commented 3 years ago

Hi,

Rakuten has started to add support for third-party merchant websites in its mobile payment application, based on PWA. The catalogue of web apps you can "install" and use in our "super app" thus gets all the app's metadata from its web manifest.

When a user launches a 3rd-party app the first time, a dialog is shown to present some information about it: name of the developer with an optional URL, as well as links to the app's privacy policy, terms of use and support site. This information is also available from the web view menu once the web app is opened.

Although a few schemas could be used, for instance Organization or Service, they are quite complex. Moreover, JSON-LD seems out of place in a manifest, and the schemas too obscure for us to expect them be used in merchants' web apps either.

Our current implementation thus takes inspiration from Kai OS webapp manifest, which feels more "idiomatic":

"developer"

Type: Object

Mandatory: No

Developer information. Use this to provide information about your company and your service to end-users. The recognized keys are shown below, and most are optional.

Key Description

name (Mandatory) If you provide a developer object, it must at least contain the name of your company.

url Absolute URL of your company's main website (optional).

privacy_policy_url Absolute URL of the page detailing your company's privacy policy (optional).

terms_of_service_url Absolute URL of the page detailing your service's terms and conditions (optional).

support_url Absolute URL of a page with methods for end-users to contact you for support (optional).

Key	Description
`name` (Mandatory)	If you provide a `developer` object, it must at least contain the name of your company.
`url`	Absolute URL of your company's main website (optional).
`privacy_policy_url`	Absolute URL of the page detailing your company's privacy policy (optional).
`terms_of_service_url`	Absolute URL of the page detailing your service's terms and conditions (optional).
`support_url`	Absolute URL of a page with methods for end-users to contact you for support (optional).

Although our user agent is a super app, we think this metadata would also have value in a web manifest for web browsers. Without this, discovering the information relies on parsing the HTML DOM and looking for many complex schemas with a lot of fragmentation, with no easily predicable behavior.

tomayac commented 3 years ago

Do you have pointers to Rakuten's documentation for this feature? I failed to find it.

jcayzac commented 3 years ago

@tomayac unfortunately it's not public yet. I copy-pasted the part relevant to the "developer" field above.

aarongustafson commented 3 years ago

Most of this is on the roadmap for the Manifest App Info spec (which is focused on catalog info). I'm going to move it over there and connect it to the various issues we've already got in the hopper.

aarongustafson commented 3 years ago

Developer Info: #6 Publisher Info: #3 Policies: #16

aarongustafson commented 3 years ago

Questions:

Should developer & publisher be different fields? It feels like yes because they may not be the same one.
Should the linked policies be associated with the developer, publisher, or app? Or should each be able to have its own? In my experience, apps or sites generally have their own policies, but in the case they are shared (Microsoft’s for example), I think I’d be fine having the policy be at the app level and link to the one being applied to this product, wherever that may be.
Should support_url be at the manifest level? It feels to me like it might make sense because it likely differs by app (as opposed to by developer… any large developer has dozens–or hundreds—of apps, likely with distinct support pages).

jcayzac commented 3 years ago

@aarongustafson Thanks for moving the issue. I didn't know there was a proposal already for supplemental app information. I just read the draft and liked what I saw a lot. Thanks for writing it.

Regarding your questions, and the factors that guided our current implementation above:

Current popular distribution channels for apps (Apple App Store, Google Play Store, etc) don't have a distinction between developer*, publisher or seller, and the terms there often seem interchangeable. Support/privacy/TOS links are also directly relevant to the app itself, not much so to the larger entity who published it. Only the "developer website" links to the organization.

Functionally, I think this maps well to the Service and Organization schemas I linked to in my original message, but we wanted to avoid the complexity of those schema by keeping only a subset of the most common information. The discussions around these schemas in https://github.com/schemaorg/schemaorg are very interesting to read.

Our implementation also packages this information into an object field, rather than spreading the fields at the top level of the manifest. This was both to avoid collisions with other extensions of the web manifest, and to make the data better structured. But maybe a single object isn't the best option after all.

* The developer information, when talking about the people who actually wrote the code, is usually not exposed by the various app stores. On the web, agencies use humans.txt for this.

aarongustafson commented 3 years ago

Considering this (and the related items), I’d propose we consider the following structure:

{
  "name": "App Name",
  "publisher": {
    "name": "Company X",
    "url": "https://domain.tld"
  },
  "policies": {
    "usage": "/terms",
    "privacy": "https://domain.tld/privacy",
    "accessibility":  "/accessibility",
    "support": "/support",
    "security": "/security",
    "license": "/#license"
  }
}

publisher is informative, but very open for spoofing so the spec would need to recommend that app catalogs provide some means of validating this information. Many may choose to ignore it and use the domain instead (which Chromium’s current behavior: "Publisher: twitter.com").

policies is an object that could be expanded with new keys over time. All would be optional, but I think the above example covers most of the use cases I’ve seen.

Would love to hear thoughts from @jgw96 here as to what they are seeing folks ask for or need in the Microsoft Store. @tomayac and @torgo Do y’all have any insights into whether this might be of interest in the Play and Samsung stores?

jcayzac commented 3 years ago

publisher and policies look good to me 👍🏼

jcayzac commented 3 years ago

Just a comment on the URL format:

Our platform enforces absolute URLs for simplicity, because we actually open these links in the default browser and not in our super app.

Relative links are of course great, but I think it should be explicitly mentioned that absolute URLs are supported as well, and that they are not affected by the scope field —company policy pages are rarely located in the same space as a web app.

aarongustafson commented 3 years ago

Relative links are of course great, but I think it should be explicitly mentioned that absolute URLs are supported as well, and that they are not affected by the scope field —company policy pages are rarely located in the same space as a web app.

@jcayzac Totally agree. That’s why I showed both within the same policies block. At Microsoft, for instance, we have a single Privacy Policy for all web properties, but other policies may differ by property. It should totally support both.

aarongustafson commented 3 years ago

@JudahGabriel Does this proposal align with what the Microsoft Store is interested in? Any feedback you have would be much-appreciated.

JudahGabriel commented 3 years ago

Yes, this align with some of our goals for PWA ingestion. Looks great!

w3c / manifest-app-info

Developer information? #40

`"developer"`