Ability to claim web app

[RobDolinMS]

CHALLENGE: How does a web app author "claim" their web app.

DISCUSSION:
Having web app authors include a ton of developer metadata in the web app manifest could make the file bloated.
It would also be non-optimal to force web app authors to include email addresses or other PII in the web app manifest.

Looking to how search engines enable website authors to claim their sites seems informative:

• Upload a file
• Include a meta tag with opaque content:

<meta name="google-site-verification" content="PxOAmyFt5AWoMLGXou0nol_x3xPYuYjdclDlFTj2Chg" />

Allowing the author to include one or more opaque identifier strings in the W3C Web App Manifest seems to be the most straightforward solution.

PROPOSAL: Add a description of this scenario to the Extensibility section of the spec http://www.w3.org/TR/appmanifest/#extensibility

[marcoscaceres]

🤔 maybe TLS could be used here? For example:

If Let's Encrypt, and like services, can set the site owner's info, then you get a verified owner for a given application.

[raucao]

Let's Encrypt does not and (as far as I know) will not ever certify identity via EV certificates like the one GitHub is using. The reason is that Let's Encrypt is a machine-usable and machine-run automatic certificate authority, and for EVs you need humans evaluating official paperwork.

[marcoscaceres]

Yeah, that's what I figured. Still, it's a good opportunity for someone to set this up and make it work (e.g., a store provider could help by acting like a CA, but also supporting other verified certificate options, like DigiCert above).

[marcoscaceres]

Anyone want to start a Progressive Web Apps CA company with me? 💰🤑💸

[raucao]

Still, it's a good opportunity for someone to set this up and make it work (e.g., a store provider could help by acting like a CA, but also supporting other verified certificate options, like DigiCert above).

Not really. The whole point of Let's Encrypt is that we can circumvent that whole extortionist snake-oil industry, and it's unlikely someone can do it for free, or cheap enough for most app authors to use it, when there's human work involved for every single validation.

[marcoscaceres]

Not really. The whole point of Let's Encrypt is that we can circumvent that whole extortionist snake-oil industry, and it's unlikely someone can do it for free, or cheap enough for most app authors to use it, when there's human work involved for every single validation.

If certifying identity is mostly just snake oil, then it might be possible for Let's Encrypt to do it (by simply authenticating prior to generating the cert). I'll ask around.

[marcoscaceres]

Took it to the twitters.... hopefully someone from Let's Encrypt will respond.

[annevk]

I don't understand OP. Claim it where? How is this different from origins?

[raucao]

The whole system is kind of snake-oil-y, because we can't really trust every single "trusted" CA that much. However, EV validation actually has to adhere to rules, and LE can't do it automatically:

https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Issuing_criteria

[annevk]

(I agree that building upon EV is not the way to go. We should get rid of EV, not strengthen it.)

[marcoscaceres]

(I agree that building upon EV is not the way to go. We should get rid of EV, not strengthen it.)

Agree - not a great idea. TBH, I was hoping that Let's Encrypt would allow us to circumvent the Issuing Criteria by just allowing the "Owner" to be set by anyone without any paperwork (thus weakening and democratizing EV - and basically killing off the snake oil businesses).

[marcoscaceres]

I don't understand OP. Claim it where? How is this different from origins?

So, IIUC, what the OP is asking is for a means for a store to verify that a developer is actually in control of a domain.

Google, today, does this by asking the developer to prove ownership of said site by:

• setting meta
• Upload a file
• setting a DNS record

By forcing developers to prove that they do, in fact, own a particular web application (by including a magic token in the manifest), it gives a store a trust model: allowing the web application to be listed in that store (and possibly more things on the store site)... the same way that this allows developers today to use Google's "Search Console".

This prevents bad actors from listing sites they don't own in a store, because without including this magic key, they can't get listed in the store.

[marcoscaceres]

@RobDolinMS,

PROPOSAL: Add a description of this scenario to the Extensibility section of the spec

I'd be in favor of adding such an example in the extensibility part of spec:

{
   "vendor_example_site_verification": "KEY_9864D0966935"
}

[annevk]

So, IIUC, what the OP is asking is for a means for a store to verify that a developer is actually in control of a domain.

Why does the store need that information? Is it building a proprietary feature on top? Do we actively want to support that?

[NekR]

@annevk I guess this is related to linking PWAs in Edge to Microsoft Store. I don't know all the details, but integration planned to be very tight, e.g. PWA can be searchable in the Store and will be installed to device in real app container, from both Edge and the Store.

I can be wrong though.

[annevk]

None of that requires an ownership relationship.

[kenchris]

In a store you have the concept of "vendor", ie, in the Play Store you can trust that if an app says it comes from Google, it does come from Google as that is being verified. The Play store additionally brands some vendors as "Top Developer". I assume that MS does something similar.

It seems like something which should be done like an extension, ie ms-store-developer-id or similar.

[benfrancis]

This is a well known problem from the Chrome Web Store and Firefox Marketplace, though previous solutions have been pretty hacky. This problem exists because when the app metadata is hosted at a URL on the web rather than in a package submitted by a developer directly to the store, there's no obvious mechanism to know whether the person submitting the URL of a web app "owns" that web app. App manifests on the web can be crawled by store creators or submitted by anyone, which makes it challenging for the app owner to later take control over the app listing to edit it and provide extra information, or have it removed.

IIRC the Chrome Web Store offered a few methods for proving ownership of a domain, including setting a special CNAME record on your DNS server, which was quite cumbersome. The original Chrome app manifests could have a list of URL prefixes which defined the scope of the app.

Firefox Marketplace required a particular Content-Type header to be set on the HTTP response of the hosted app manifest to demonstrate that the manifest is authoritative to some extent. Also the manifest URL was used to identify the app and you could originally only have one app per origin and one origin per app. That's far from foolproof but offered some evidence of the level of control over a web server.

I'm curious about what Microsoft is doing here because the manifest spec as it exists today does not lend itself well to being used by an app store.

1. A web app using a service worker won't work offline until the second time you visit it in the user agent. You can't "install" a game from an app store and then expect to be able to launch it while offline. I guess this is why @RobDolinMS reopened Integration with service workers #161?
2. The spec (intentionally) doesn't include an installation API that a store can use. The Firefox Marketplace and Chrome Web Store use proprietary JavaScript APIs (e.g. navigator.mozApps.install()) to "install" an app into the user agent using an install button on a web page. An app store for web apps would need to either use a similar proprietary API for a web-based store, or create a store as a native app with deep integration into the OS with its own installation mechanism.
3. This issue of identity and ownership is tricky. A decision was unfortunately made early on that a manifest URL does not identify an app (see Define identity of a web app. #272), it's technically possible to have multiple manifest URLs for the same app and multiple apps using the same manifest URL. Also unfortunately a decision was made to have "unbounded" URL scope by default (see URL Scope to which the manifest applies #114) so it's also possible to have multiple apps per origin and multiple origins per app.
4. The manifest alone doesn't really provide enough information for a listing in an app store. I guess that's what Include Minimal Store/Catalog MetaData in Manifest #448 is for.

This all makes it difficult to identify, define, describe and prove ownership over a web app and install it from a web store. What are you even proving ownership of and what is the mechanism for installation?

Maybe these problems can be solved. The alternative is that we simply don't have traditional "app stores" for web apps. Instead anyone can create a curated index of web apps, but rather than have an install button in the store itself they just link you directly to the web app by its start URL and you "install" it "progressively" from the browser.

[NekR]

IMO, one should be able to install web only after that one navigates to the app. This gives a chance for web to start SW and cache everything needed, plus it makes immediate preview of the to the user.

While navigating to such web app from browser doesn't guarantee that browser will prompt installation, navigating to it from the Store should guarantee that user will be prompted to install the app. Maybe not with popup, maybe with big "Install" button at a top of Store UI, but anyway, webapp should be installable immediately after previewing it.

Of course, if someone will figure out the problem with SW not being run until first app's launch, then preview of a web app could be opt-in, not requirement.

[RobDolinMS]

I'll elaborate on the scenario as it seems like there is some healthy confusion in the discussion:

1. Developer (Danica) builds a PWA
2. The PWA is listed in a catalog or store
3. Danica wants to change the way her PWA is listed in the catalog or store (ex: Add more screenshots, add a video, etc.)

CHALLENGE: How does the catalog or store know that Danica is the owner of the PWA?

PROPOSAL (adopting Marcos's comment above): Add text in the extensibility section with the example:
{
"vendor_example_site_verification": "KEY_9864D0966935"
}