Re: [w3c/manifest] Ability to claim web app (#476)

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

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/476#issuecomment-231023770