Replacing k-anonymity requirement for `selectURL()` with per-page-load entropy bit budgets

[pythagoraskitty]

We are soliciting feedback on the following proposal:

We propose removing the requirement that input URLs for sharedStorage.selectURL() be k-anonymous.

Given that we currently have event-level reporting, we believe a k-anonymity requirement would be of limited benefit and not worth the associated financial, performance, and utility costs.

Instead, each page load would have two entropy-bit budgets: an overall page budget and a per-origin page budget. These budgets are in addition to and separate from the daily budget for navigation.

Each time selectURL() is called during that page load, log2(num_urls) would be charged to both the overall budget and the per-origin budget for the caller's origin, as long as there is sufficient budget remaining in both. If either budget has insufficient remaining budget, then the default URL is returned for selectURL() and no budget charges are made.

We plan to use 12 bits as the page-load overall budget, and 6 bits as the page-load per-origin budget.

[SpaceGnome]

Do we charge every time we call selectURL()? What if we return the same URL every time we call - does that also eat into the budget?

[SpaceGnome]

And also, by overall budget, does this mean even if there are multiple different context origins using Shared Storage, all the context origins are contributing to the overall page's budget?

[pythagoraskitty]

We will charge you each time that you call selectURL().

We considered not charging you additional times for calls with the same input URLs and output URL during the same page load. (Simply having the same input or the same output wouldn't be sufficient privacy-wise to avoid a double-charge, both would have to match.) It seems that it would be better if you could cache the result of the call instead of making an additional call. We will likely not implement any filtering to prevent duplication, due to the performance tradeoff.

Yes, the overall budget is contributed to by all origins on the page calling sharedStorage.selectURL().

[SpaceGnome]

Makes sense to cache it and perhaps store it in a 1P cookie.

Some other thoughts:

• What happens if there is intentional abuse to hit the budgets (perhaps by a malicious site to easily hit the page-load overall budget) and hence force each context origin to only get the default URL?
• If this proposal does move forward, could we consider a "soft enforcement" period until there is enough usage to determine if the proposed budgets actually make sense before actual enforcement?

[jkarlin]

I want to call out that that this proposal is for an intermediate period in which fenced frames are leaky (unfettered network access) and we have event-level reporting. Once those two issues are resolved then the plan is to significantly relax the budget by only counting against an origin when a user clicks on their fenced frame and the frame navigates (e.g., the originally proposed budget).

We're starting with a constrained budget for now until we see enough legitimate usage/adoption to warrant expanding it during this trial phase.

[SpaceGnome]

Also, in this proposal, what is the window for the budget? Is it also 24 hours like in the budget for navigations?

[pythagoraskitty]

No, this budget will be refreshed at the start of each top-level navigation.

[SpaceGnome]

Ah, thanks!

In this case, I think the proposal makes sense. My only remaining concern is with any malicious sites that intentionally hit the budgets and prevent legitimate users of Shared Storage from getting a non-default URL.

[pythagoraskitty]

We will need to monitor the situation with metrics and if this becomes a problem, figure a way to prevent abuse. Closing for now.

Meanwhile, please reopen this issue or start a new one if you detect a problem from your end.