Does this provide an easy, dangerous mistake for web developers? Currently, the developer has to delegate the origins specifically: I might decide I want this particular feature to be accessible at feature.example.com and I have to make a case-by-case decision whether I want the feature to also be available at other-service.example.com. With this change, a developer could be encouraged to just provide the feature to *.example.com, which will surely all be subdomains that the developer controls and wants the feature on. Later, when a third-party provider requests a CNAME for a subdomain (analytics.example.com), that service automatically gets access to all those features, inadvertently.

That is, in your questionnaire answers, you repeatedly note that this isn't creating any new capabilities. But is it encouraging accidental expansion of a capability to potentially many different origins?

Does this change introduce a new dependency on the PSL? What happens if the PSL is out of date or a site is accidentally included/not included?

It's true that a developer might be encouraged by this new feature to allow *.example.com where as they would previously have to manually add subdomains. That said, they could currently be being pushed to use just * due to their CDN needing 100+ subdomains whitelisted. This seems a safer corner to be backed into.

I was planning to depend on the PSL by referencing this language. As the permissions policy directives aren't cached beyond the lifetime of the page load, if the list is out of date it could result in sites being delegated (or not being delegated) permissions. If an invalid target is detected in the list that target would be ignored without throwing away the rest of the targets (i.e., https://*.example.com/ https://*.org would parse the same as just https://*.example.com/).

I have a few questions about matching: Does https://www.example.com:443/ match https://*.example.com/ ? (implicit port equivalence) Is it possible to use the wildcard as part of a token or to replace more than one token, ie: https://*-assets.example.com/ matching https://img-assets.example.com/ or https://*.example.org/ matching https://two.levels.example.org/ or should it be https://*.*.example.org/

Also, to avoid only opening everything, would it be possible to have negative matches? Thinking of something like Permissions-Policy: geolocation=(self "https://*.example.com/" "!https://notallowed.example.com/") this would be useful if there are a few subdomains to exclude, or combined with partial matches like the question above !https://*-no.example.org'

I have a few questions about matching: Does https://www.example.com:443/ match https://*.example.com/ ? (implicit port equivalence)

Yes

Is it possible to use the wildcard as part of a token or to replace more than one token, ie: https://*-assets.example.com/ matching https://img-assets.example.com/ or https://*.example.org/ matching https://two.levels.example.org/ or should it be https://*.*.example.org/

No, you can only ever have one wildcard and it must have a . after it and the // before it. https://*-assets.example.com/ is invalid, https://*.*.example.com/ is invalid, https://foo.*.example.com/ is invalid, https://*.example.com/ is valid.

Also, to avoid only opening everything, would it be possible to have negative matches? Thinking of something like Permissions-Policy: geolocation=(self "https://*.example.com/" "!https://notallowed.example.com/") this would be useful if there are a few subdomains to exclude, or combined with partial matches like the question above !https://*-no.example.org'

We want to keep this first foray into wildcards to the minimum feature set to support the use case (CDNs with hundreds of subdomains). In the future, more flexible matching (like what's supported in the Content Security Policy) might be added, and later down the line support for negation could then be considered in both spots. It's a lot easier to expand the syntax if we need more later than to shrink it if we over-extend now.

We discussed this issue today in our call and came to the conclusion that a way to mitigate the "all on or all off" effect of the wildcard as currently defined. Something as simple as possible, like allowing only one partial match (but we let you discuss what could be an acceptable solution) would be good to avoid people using it too broadly "to make it work".

I'm not sure I understand. It doesn't look like the minutes have been published yet, but I can read the notes from the 10/10 meeting when they're available.

Hi @arichiv the minuted discussion is here. Also cc @cynthia.

@arichiv did you have time to read our feedback? Any plan on working on it?

Yes! Sorry for the delay, I hope to get to the expansions proposed Q1 2023.

Ok thanks for letting us know. Please let us know updates when you can.

There has been a further expansion of this proposal. Specifically:

Subdomain wildcards in allowlists provided some valuable flexibility, but differed from existing wildcard parsers and required novel code and spec work. This intent will reduce that overhead by reusing parts of the existing Content Security Policy spec and permitting ‘scheme + wildcard domain’ and ‘wildcard port’ in the allowlist.

Specifically, this intent would adopt the definition of host-source and scheme-source instead of origin in the Allowlist definition while requiring that the path-part is empty (as Permissions Policies apply to matching origins). This would change three things from the prior wildcard implementation (all of which expand the range of allowed wildcards and none of which add new restrictions):

(1) Removing the eTLD+1 requirement for subdomain wildcards Previously, you could not have a subdomain wildcard like “https://*.com” but could have one like “https://*.example.com”. Now, you can have subdomain wildcards both like “https://*.com” and “https://*.example.com”.

(2) Allowing scheme restrictions on wildcard domains. Previously, you could allow “*” but not restrict to a specific scheme like “https://*” or “https:”. Now, you can still allow “*” but have the option of delegating to just a specific scheme like “https://*” or “https:” (the behavior of these is identical).

(3) Allowing port wildcards. Previously you could delegate to the default https port like “https://example.com” or “https://example.com:443” (the behavior of these is identical), but there was no way to explicitly delegate to all ports like “https://example.com:\*”. Now, you can still delegate to “https://example.com” or “https://example.com:443” but delegation is also permitted to a wildcard port like “https://example.com:\*”.

Thank you for the update! We've reviewed the latest changes and they look good. We've also noted the positive developments on multi-stakeholder support on the Mozilla and Webkit standards positions threads. Despite the fact that we would like to see intersections in matching, the fact that is now consistent with CSP is good. We're happy to see this move forward and on that basis we're going to close this review.