Wildcards in Permissions Policy Origins

[arichiv]

Request for position on an emerging web specification

• WebKittens who can provide input: @johnwilander

Information about the spec

• Spec Title: Wildcards in Permissions Policy Origins
• Spec URL: https://github.com/w3c/webappsec-permissions-policy/issues/479
• GitHub repository: https://github.com/w3c/webappsec-permissions-policy/

Design reviews and vendor positions

• TAG Design Review: https://github.com/w3ctag/design-reviews/issues/765
• Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/679
• Chromium Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/biH6g79KclA

Bugs tracking this feature

• Chromium Feature: https://chromestatus.com/guide/edit/5170361717489664
• Chromium Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1345994

Anything else we need to know

Design Doc

This feature will add support for wildcard in permissions policy structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where a valid Origin could be constructed from SCHEME://HOST:PORT (e.g., https://foo.com/). This requires that HOST is at least eTLD+1 (a registrable domain). This means that https://*.bar.foo.com/ works but https://*.com/ won’t (if you want to allow all domains to use the feature, you should just delegate to *). Wildcards in the scheme and port section will be unsupported and https://*.foo.com/ does not delegate to https://foo.com/.

Before, a permissions policy might need to look like: permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://cdn1.foo.com" "https://cdn2.foo.com" "https://foo.cdn2.foo.com")

With this feature, it could look like: permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")

[annevk]

At TPAC I gave the feedback that this should reuse the CSP parser (it could still be more restrictive than CSP, but we should try to limit the number of parsers we have around this space). Overall this seems reasonable to me, although it may lead to inadvertent delegation to an origin that the corresponding site is not in control over (e.g., the webmail endpoint or some such).

[arichiv]

Would you be okay with setting parser re-use as a goal after initial implementation, but before any future extensions are made? Specifically, as far as spec modification goes.

[arichiv]

There is a new 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:*”.

[annevk]

Thanks for the update! Is there any progress on layering this correctly?

FWIW, I found some substantive issues in CSP looking at how this matching is defined there:

• https://github.com/w3c/webappsec-csp/issues/590
• https://github.com/w3c/webappsec-csp/issues/591
• https://github.com/w3c/webappsec-csp/issues/592

[marcoscaceres]

Add integration concerns because of https://github.com/WebKit/standards-positions/issues/51#issuecomment-1470519891

@arichiv we discussed this internally and we'd really like to see more movement on the layering issues @annevk filed https://github.com/WebKit/standards-positions/issues/51#issuecomment-1470519891 before we are confident about reaching a position. That will also give us more confidence about maintenance.

[arichiv]

The spec change landed: https://github.com/w3c/webappsec-permissions-policy/pull/516

And 2/3 of the CSP issues highlighted by @annevk have been addressed.

As I pursue chrome launch are there any objections from WebKit we should be aware of?

[annevk]

Thank you for the substantial progress you made on this @arichiv across both specifications! I filed a couple follow-up issues, but by-and-large this looks good now (CSP needing improvements notwithstanding). As this is now layered on top of CSP I suggest we resolve this as "position: support" one week from now.

[hober]

It's been a bit longer than a week. :)