Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

On Tue, May 27, 2014 at 5:11 PM, Marcos Caceres <w3c@marcosc.com> wrote:

>
> The only way one could do what you describe would be for "my own app
> store" to host its own manifests. So:
> http://myownappstore.com/gmail/index.html
>
> Would contain:
> <link rel="manifest"
> href="http://myownappstore.com/gmail/manifest.json">
>
> Which would have:
>
> {
>    "name": "Gmail"
>    "start_url": "http://gmail.com"
> }
>
> This would allow custom stores that provide tailored "app experiences" for
> sites that lack manifests.
>
> Where this could become a problem in the future is if manifests start
> granting elevated privileges (e.g., access to specific APIs or unlimited
> storage). However, the security model could then be refined so that, for
> instance, only same origin manifests that are served over HTTPS get special
> powers. In such a case, non-same-origin manifests could be "tainted" and
> only the basic metadata from the manifest would be used by the user agent.
>

To be clear, this is the case I was talking about. The benefit is that it
makes it much easier to build a large "app store" of "tailored app
experiences for sites that lack manifests" without the involvement of app
authors themselves. For example, everything.me may have a larger catalogue
of "web apps" than the Firefox Marketplace because the latter requires
same-origin manifests and for app authors to submit their own apps, whereas
the former doesn't require any involvement from app authors themselves.

One risk of allowing cross-origin manifests might be that these "tailored
app experiences" are perceived by the actual app author and/or end users as
a "fake app" masquerading as the real thing. In the longer term when
additional features are added to the manifest there could be additional
risks.

That is why I'm interested in feedback on whether this is a desirable
feature or not.