Re: [w3ctag/design-reviews] Wildcards in Permissions Policy Origins (Issue #765)

> 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. `https://*-assets.example.com/` is invalid, `https://*.*.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.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/765#issuecomment-1246928276
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/765/1246928276@github.com>