shouldn't the default scope be bounded?

[kenchris]

If scopeURL is undefined (i.e., it is unbounded because of an error or it was not declared in the manifest), return true.

I find it a bit scary that it is fully unbounded. I would expect that the default scope would be the base url

[benfrancis]

I agree @kenchris. I actually think it would be great if the default scope was the whole origin of the manifest, it would make scope much more useful for user agents to determine which app a given navigation belongs to. Unfortunately we found that this potentially breaks a lot of existing web content because it's common for a single web site/web app to span multiple origins.

[kenchris]

Well in that case, those users would have to define their scope. As we want people to create great web apps, I think that they should at least be able to do that :-)

I don't think that scope currently allows this, so we should have a look at it.

I am also interested in how to open other apps. Like if I launch a URL which already have a manifest associated (which I have bookmarked etc) then maybe we should just launch that app instead?

[benfrancis]

Well in that case, those users would have to define their scope.

Currently I think the maximum scope is one origin. If we allow an app to handle the scope of another origin we risk evilapp.com/manifest.json registering to handle navigations to mybank.com. I think the maximum scope should stay as one origin, and should have to be the same origin as the manifest.

There was also a proposal for a "stay_in_app" type property to enable defining a URL scope for which navigations should stay in the app if the user is already in the app (e.g. for third party authentication), and could include more than one origin. We could re-visit that.

I do still think it would be great if the default scope of an app is the whole origin of the app manifest, but it would break some existing content.

I am also interested in how to open other apps. Like if I launch a URL which already have a manifest associated (which I have bookmarked etc) then maybe we should just launch that app instead?

This is "deep linking" and is already addressed in the spec http://w3c.github.io/manifest/#deep-links Installed apps should be able to capture navigations to URLs which fall within their scope, although nobody has implemented this yet as far as I know.

[PaulKinlan]

Two things I am concerned about with scope.

1. I am unclear of the relationship between this and the SW scope,
2. If SW has a scope then a 2nd scope adds a huge amount of confusion.

re: Multiple scopes: I am presuming the worry is that you can't verify you own the domain just via the manifest. We never had this problem with the Chrome Web Store because it hooked up to the domain verification tools that we have in Webmaster central.

EDIT: No multiple scopes means that you can't do path based exclusions, and you also can't do http and https without having two manifests.

re: Manifest origin: I really do think the origin of the manifest is incredibly shortsighted. I've spoken to numerous companies that find it incredibly hard to deploy any file to their site and it needs to be hosted on a CDN. It looks like you are also blocking http site having an https manifest.

[PaulKinlan]

Also deeplinking, the section in the spec makes no sense. Is there a plan for it to be expanded? I ask because Deep linking on Android has a very specific configuration, and I would expect to see some configuration of ownership of multiple paths, protocols etc (potentialy via a scope).

[kenchris]

Great comments @PaulKinlan , I hope you can help us find solutions, or at least discuss it internally with your teams

[benfrancis]

Hi Paul,

1. I am unclear of the relationship between this and the SW scope,

This was discussed at some length in #114. The scope of the app is independent of the scope of a Service Worker, you should be able to install an app without requiring a Service Worker. The maximum scope of both an app and a Service Worker is the root of the origin, but a Service Worker may register to handle only a part of the scope of the app and vice-versa. It's possible to register multiple Service Workers for a single app.

The scope defined in the manifest is "navigation scope", it determines whether a navigation should be carried out in a browsing context or in an application context with a particular manifest applied, i.e. whether the navigation should be handled by a browser tab or an app (e.g. in a standalone display mode). Conversely the scope of a Service Worker can be used to determine whether an HTTP request is handled by the network or from a cache for example, but this is orthogonal to browsing context/application context and display mode.

Do you have any proposals of how to clarify this in the spec?

2. If SW has a scope then a 2nd scope adds a huge amount of confusion.

What do you think is confusing? If they had to have the same scope that could be very limiting. In particular I feel it's important that an app is not forced to register a Service Worker in order to register to handle a URL scope in a particular display mode.

I suspect that Google has a more Service Worker centric view on what apps are, but currently the direction of the spec is that a manifest identifies an app, and a Service Worker is an optional feature of an app (there are already many uses of the manifest which don't specify a Service Worker). Do you have an alternative proposal? We are discussing integration between the manifest and Service Workers in #161.

Also deeplinking, the section in the spec makes no sense. Is there a plan for it to be expanded? I ask because Deep linking on Android has a very specific configuration, and I would expect to see some configuration of ownership of multiple paths, protocols etc (potentialy via a scope).

Can you expand on this? Which part doesn't make sense? What do you mean by "configuration of ownership of multiple paths, protocols etc"? There have been various proposals for how to define scope in the manifest including a list of URL prefixes, whitelists, blacklists and a "stay_in_app" property for cross-origin navigations which should stay in the app if they originated in the app. The current spec is quite simplistic, do you have a proposal for something more complex?

[marcoscaceres]

@kenchris, I don't have a strong opinion, but can see the rationale for your concern ... right now, I guess I would prefer we keep Chrome's current behavior (i.e., unbounded, with the UA able to pull the plug or change the UI if a user leaves an origin). Maybe you can list some more potential issues?

@PaulKinlan, I've created a separate issue for deep linking aspects. I agree that it's a bit hand-wavy right now... no one has made a proof of concept to show that it would actually work. Can we please discuss in #363?