Wildcards in Permissions Policy Origins

[arichiv]

This change harnesses Content Security Policy matching to allow wildcards in the origins of Permissions Policy allowlists. The goal of this is to provide greater granularity in permissions to better balance the ease and risk of a wildcard permission against what might otherwise be a long list of similar, yet distinct origins.

The only wildcard allowed before was *, which matched all origins.

Wildcards will now be supported for:

• https://example.com:\* (ports, any port for example.com over https)
• https://*.com (hosts, any https origin ending in .com)
• https: (scheme-only, any https origin)

Feature: https://chromestatus.com/feature/5101218029895680

closes #479

---

Preview | Diff

[clelland]

I think this is looking pretty good -- a couple of issues with allow parsing though.

[clelland]

Thanks -- I think this looks good -- can you file an issue on CSP to export the three terms that we use here? (That shouldn't block merging this, but it would be good cleanup for later)

The only thing that we might want to do to tighten it up a bit would be to give Allowlist two actual properties, so that we don't have to keep referring to "the origin representing self/src in allowlist", and could actually link to a definition there. That would probably require accounting for those properties to possibly be null. We'd be able to assume at that point that the "list" part of the allowlist is just patterns, as well.

(Not necessary right now; this is functionally equivalent, but if you wanted to do that before merging, let me know and I'll hold off)

[arichiv]

Filed w3c/webappsec-csp#604

I think this can merge as is, I can circle back on that cleanup when the DFNs are exported by CSP.