Setting budget and safety limit parameters

[bmcase]

The spec has a section on Privacy and Safety Limit Parameter Configuration with TODOs on i) setting some minimum values ii) if safety limits should be defined as multiples of the per-site budget and what recommended or minimum multiples should be.

[martinthomson]

As I noted in the discussion, I think that the right thing to do is suggest minimums that are probably too low. Those can be specified in terms of multiples of the per-site budget.

The key part is to explain why implementations might want to expand on those minimums.

The obvious one is based on expected (and observed, ideally) usage of the APIs. As usage increases, we'll get information on the number of different destinations that conversions might result from a an impression site. We'll get a better sense of how many sites use the API. That usage will help inform better values.

Secondly, as was mentioned, it might be desirable to set a somewhat higher multiple to account for the possibility that the limit comes under attack. In that case, the API might still be able to function if the attack is kept small, so a higher limit allows the API to function for longer. This is why we have user activation checks: to (hopefully) limit the scale of any attacks and ensure that sites can continue to use the API successfully when an attempt is made to attack the budgets/quotas.

Obviously, if the attack is successful at circumventing user activation safeguards, no limit can really help as the attacker will absorb all capacity. It's only when the attack is successful that the API then stops working entirely, but it might be possible to have a functional or degraded service with a higher limit in place if the activation safeguards are effective. In practice, that might not require much additional capacity, but it might need to absorb a multiple relative to the number of activations that can be harvested by an attacker.