core(budget): support additional first-party domains

[csabapalfi]

Summary

This PR adds a new optional field in budget.json named ownDomains (open for suggestions) to allow specifying additional first-party domains (that won't be considered third-party while budgeting).

Pages can load their assets from a CDN that has a non-matching domain (not even at the root level). This change will make it possible to use third-party budgets without incorrectly including first-party requests for these pages.

Examples:

• https://www.vrbo.com/vacation-rentals/usa -> https://csvcus.homeaway.com/...
• https://www.hotels.com/ -> https://a.cdn-hotels.com/...

Open to naming suggestions or moving this elsewhere in budget.json.

Please note I'm raising this PR before adding more tests to get some feedback first.

Related Issues/PRs
N/A

[brendankenny]

Hi @csabapalfi! Huge thanks for taking the time to figure this out and for writing up the PR.

For a substantial change like this (especially one that will affect the public API), however, it's generally better to approach with discussion in an issue before moving to implementation. Third- vs first-party in particular hits a few different places in the Lighthouse report that are actively being worked on (e.g. third-party filtering in audit results, #9067, etc), so it would be great if we could come up with something to claim origins as first party for all these features so we don't end up with a few different ways of doing it in the end.

I actually don't have a strong opinion on this yet, but (hopefully) calling in those that do: @patrickhulce @khempenius.

We can roll with the PR for now or move to an issue as this plays out.

[csabapalfi]

@brendankenny Thanks a lot! Makes perfect sense to discuss first. I understand your concerns. 💯

The more important thing is definitely the discussion. There are not many code changes in the PR (also it's not 100% complete without more tests). I just wanted to see one way of doing this myself (i.e. no problem if it ends up not being merged 😆).

At the moment we can't use lightwallet/budgeting for third-parties on some of the Expedia Group sites I help with because of this. (To clarify: we can use budgets but not for third parties).

[patrickhulce]

I'd like to move to a world where first-party is assumed by default and third-party designation is opted-into by a static list (like the method proposed for web almanac or just third-party-web). This would more closely match the model from before where we assume you control your website and there are just some known big players that you're unlikely to be able to affect.

@paulirish mentioned though that any change to a resource in the third-party list for budgets would require a breaking version change for Lighthouse, and I'm not sure how to reconcile that with certain real-world situations if we went this direction (i.e. if a third-party changes their domain and we don't update then the user will be broken anyhow).

If that's how we intend to treat the breaking changes of budgets third-party list then I think we have no choice but to keep it assumed third-party by default and only the user can opt certain domains into first-party status like this PR enables.

One alternative I see is to allow different third party strategies in budgets that let the user opt-in into potentially shifting third-party definitions.

For example there's a thirdPartyIdentificationStrategy with the following options:

• eTLD+1 (default and current), anything not matching eTLD+1 of the inspected page is a third-party
• optOut, user lists the domains that they control and everything else is third-party.
• optIn:web-almanac@latest, user opts in third-parties by domain to the list used by latest web-alamanc
• optIn:third-party-web@latest, user opts in third-parties by domain to the list used by latest third-party-web package

[brendankenny]

let's move to an issue rather than keeping this open indefinitely :)

[csabapalfi]

Thanks @brendankenny! Makes sense.

[csabapalfi]

Nice, this is now done :) #10324