This is basically a continuation of what I was previously assigned @connorjclark so I can take this one.

Thanks for merging them @khempenius! Couple questions before I dive in...

• How would one signify that they own *.my-cdn.com? By listing https://a.my-cdn.com, https://b.my-cdn.com, etc?
• Should it be possible to opt out of the root-level first-party consideration? Say my site is on foo.wordpress.com and WordPress injects some stuff at third-party-assets.wordpress.com, would manually specifying foo.wordpress.com remove the wider net or is this purely additional? I see the property was renamed to extraFirstPartyOrigins (maybe based on my comment in the previous PR?) so curious if that policy changed or should change.
• Is it intentional to base this on origins rather than domains? Someone following best practices probably wouldn't be affected, but there is a bit of mismatch with our default root domain check and then others needing to care about http vs. https.

@patrickhulce All good points! I'm changing course a bit and proposing what's below instead. I think this design this should answer all of the above questions.

Proposed API

firstPartyHostnames: ["$HOSTNAME"]

A hostname may optionally contain a leading * to match multiple subdomains as well as the root domain. For example, *.example.com matches both example.com and blog.example.com.

Examples of valid patterns for hostnames:

• "*.example.com"
  Applies to root domain and all subdomains.

• "example.com"
  Only applies to root domain; does not apply to any subdomains

• "cats.example.com"
  Applies to a specific subdomain

Edge case example (multiple subdomains):

All of these are valid inputs.

• "www.notifications.service.gov.uk"
• service.gov.uk"
• "*.service.gov.uk"
• "*.notifications.service.gov.uk"

Thoughts

Re: Property Name
Alternatives considered: firstPartyDomains, firstPartyHosts

• I think the property name firstPartyDomains would make it easier to misinterpret example.com as applying to “everything, including subdomains, within example.com”.

• It seems reasonable to me to follow the convention set forth in Url() for host, hostname, etc. & I can’t think of a use case where you’d want to get ports mixed up in all of this - hence hostname, rather than host. That being said firstPartyHosts would be more concise.

Re: Property Value

• This is more configurable than blanket domain-level granularity with minimal additional user effort ("*.example.com" vs. "example.com"--> two extra characters.)
• If a user wants to exclude a subdomain, they're stuck writing out all of the other subdomains. That being said, I don't see many sites with that many 1P subdomains. I don’t think trying to support a regex format more complex that *.<$DOMAIN> is worth the effort, IMO.

Appendix

This API assumes that granularity beyond domain-level is helpful and worth supporting and not an edge case. I see these as the two most likely use cases for this:

• Tag managers / analytics servers located on a 1P domain: This seems like a fairly common pattern on larger sites. e.g. Your server-side tag manager is hosted at tag-manager.my-site.com; it has a small (but non-zero) client-side footprint. It seems reasonable to me that you might want to consider any overhead associated with tags as 3P.
• Resources loaded from multi-tenant sites: e.g. you load resources from my-site.big-cdn.com; a third party on your site loads images from third-party.big-cdn.com.

Love it! And essentially the default value for firstPartyHostnames if unspecified is ["*.<tld+1>"]?

I think that addresses everything I can think of! 👍

Updated.

If left unspecified it is ["*.<ROOT_DOMAIN>"] & the root domain logic comes from one of the existing helper functions that is tld-aware, so it handles things like .co.uk properly.

@khempenius is this ready to be merged?

@patrickhulce yep, it's ready to merge :)