Better fine-grained 'scope' control (in normal manifest scope & scope extensions)

[jacobamills]

In scope_extensions-explainer.md#future-extensions the following is mentioned as a possibility:

• More specific scoping e.g. scope suffix or include/exclude lists or URL patterns.
  • To be able to apply these more specific scoping rules to the primary scope (including exclusion). One possible approach is to have the primary origin specified in the scope_extensions list and have it override the behaviour of scope.

For Google Meet, this is a blocker for us to be able to enable link capturing, as there are specific paths within our application that we do not want our PWA to handle.

Because our meeting codes are defined on the root path (e.g. meet.google.com/aaa-bbbb-ccc), we would specifically need path exclusion, rather than just inclusion. For example, we would want to be able to:

• include: meet.google.com/aaa-bbbb-ccc
• exclude: meet.google.com/about

[jacobamills]

@dmurph Thank you for reaching out to me about this proposal

@LuHuangMSFT FYI

[dmurph]

Amazing, thank you for this use-case! This is incredibly valuable.

@LuHuangMSFT I think this matches with our previous convo. Notes are here

General conclusion currently:

• The above use-case and general behavior seems to be wanted for all scopes, not just extensions or the 'manifest scope'
• So to solve this, we will have a separate 'exclusions' field that is used on top of the manifest scope AND the scope extensions.
• We looked into per-platform capabilities (like Android and iOS) and something like url pattern seems totally incompatible with them. However, prefix-based solutions seem supported. prefix-based exclusion is supported on iOS, but not (yet) on Android.

Something kinda like this is the conclusion:

"scope": "https://www.example.com/app/",
"scope_extensions": [
       { "type": "origin", "value": "https://helpcenter.example-help-center.com" }
]
"scope_exclusions": [
  // This apples to all origins, so this removes any url with the prefixes:
  // https://www.example.com/app/scope/
  // https://helpcenter.example-help-center.com/app/scope/
  "/app/about/",

  // These only apply to the specific origins
  "https://helpcenter.example-help-center.com/abcd/"
  "https://www.example.com/app/phone-numbers",
]

Spec psuedo:

When evaluating if a url is controlled by the app (in scope of the app), the url must be within the manifest scope or the extended scope, but cannot be within scope exlusions.

possible psuedo algorithm:

To evaluate if a url is within scope of an app:
- set is_in_scope to false
- If the url is within the manifest.scope, set is_in_scope to true
- Else if the url is within the manifest.scope_extensions, set is_in_scope to true
- for each manifest.scope_exclusion |exclusion|
  - If url.path()  starts with exclusion, set is_in_scope to false
  - If url starts with exclusion, set is_in_scope to false.
- return is_in_scope

[HowardWolosky]

@dmurph - Is there a reason why scope_exclusions wouldn't follow the same format as scope_extensions?

[dmurph]

@HowardWolosky said:

@dmurph - Is there a reason why scope_exclusions wouldn't follow the same format as scope_extensions?

It can - if we want to make it extensible with the "type" and "value" fields, that can totally work. "type" maybe is "path_prefix" and "url_prefix"? That might make more sense for devs. We can totally iterate on design there.

I think the main "pro" of having this be separate from scope_extensions is that it seemed less confusing to:

• Have this be a different concept - "Why are exclusions in extensions?"
• Make it more clear this applies to both the extension entries AND the manifest scope.

But - if everyone else things we should just put this in the scope_extensions with types like "excludePathPrefix" and "excludeUrlPrefix", then I'm OK with that too.

[dmurph]

We have another use-case here from a partner:

• They need to capture urls to https://other.domain.com
• They need to NOT capture urls to https://other.domain.com/download

[vatanaggarwal]

Adding to what Dan mentioned, it would be ideal for an app to specific paths which are capturable. e.g. https://other.domain.com/app and everything else is non-capturable.

[dmurph]

@vatanaggarwal said:

Adding to what Dan mentioned, it would be ideal for an app to specific paths which are capturable. e.g. https://other.domain.com/app and everything else is non-capturable.

At that point this gets more complicated - if we're doing both inclusions & exclusions, the UrlPattern solution becomes more interesting maybe, but I know discussions there ended up stalling in the past as it got complicated. There is also compatibility with other OS's to consider here and @LuHuangMSFT I believe has the most expertise. I think, for example, Android supports some stuff with basic patterns and prefixes. I'm not sure what you can do on iOS.

[dmurph]

See w3c/manifest#996 as well - likely as a better overarching topic

[LuHuangMSFT]

@jacobamills @vatanaggarwal Could you see a need to allow configuring navigation capture filters differently than scope filters? I.e. the 2 sets are not identical?