Safety limits enable possible DOS attacks

[csharrison]

The safety limits in the spec enforce a broader privacy unit not partitioned by site. The issue here is that a group of sites can collude to intentionally hit these limits (possibly logging bogus data), locking out other sites from using the API.

This seems inherent. The only mitigation I can think of is that if a normal site's budget is $\epsilon$ and the safety limit is $k \epsilon$, it takes $k$ sites to fully pull off the DOS attack and deny everyone else access, but this seems quite weak.

[martinthomson]

Yes. A lot depends on the value of $k$ then, doesn't it? The intent was to set that limit higher than a heavy web user is likely to hit, so that sites aren't affected. Keep in mind that a group of sites can potentially collude to undermine privacy, so it will depend on what each browser decides with respect to the privacy-utility balance.

[bmcase]

We have also brainstormed some other best-effort heuristics to detect patters of collusion and mitigate.

[csharrison]

My biggest worry for even large $k$ values is that no value of $k$ is large enough to prevent sites from silently window.location'ing in the background to continually consume budget.

One possible mitigation is to constrain safety limit budget-depletion to only user-initiated navigations, but it adds a bunch of complexity.

[martinthomson]

Would some constraints on API usage help? Conversions could be limited to one per engagement gesture. We'd need to allow for a pre-navigation gesture to carry over for the "landed on page" conversion as well.

Though we should consider whether there should be any limit to how many intermediaries are able to access that through bounces: one theory says that one navigation is one destination and the bounces should move to be iframes on the destination page instead; another recognizes that the industry won't change. In the first, the use of navigation tracking (which is impossible to prevent) means that all the spends can be linked, meaning that any additional allowance there effectively increases the per-site budget. In the second, some small concession is made to give the industry time to adapt. From past interactions, I predict Google would prefer a large factor, Mozilla might choose a factor closer to 1.

A conversion might also fail if the window lacks focus. That too carries risk, but if the goal is to measure interactions with humans, that might be acceptable (maybe with a short period of time after losing focus to allow for task switching and whatnot).

The paper @bmcase links to mentions several possible safety nets in terms of pure rate limiting as well: a short-term limiter that might avoid spikes in budget consumption and a longer term limiter that might prevent sustained attacks. In the former, how many conversions could occur each minute? Would conversions on 100 different sites be acceptable? Would the 101st site really suffer that much if it got a zero contribution at that point? An attack that combined budget from 100 sites could do serious privacy harm, for sure.

[csharrison]

The brainstorm is good, and I think this is worth discussing live too. From my POV we'd need to carefully assess any constraints for compat risks, since there are lots of legitimate flows on the web that could be collateral damage to heavy-handed constraints. Those make me nervous.

I honestly don't know what the best option is here. These are tough compat <-> privacy <-> security tradeoffs that imo need a lot of careful thought.

[martinthomson]

I'd prefer we not veer too much into characterizing different choices as "safe" or "heavy-handed". Like choice of $\epsilon$, this is an area where different browsers will reach different conclusions. Some browsers are content to be heavy-handed when it comes to this business, where the question of legitimacy is contested.

That, I think is the good part. We don't necessarily need to agree on the exact set of safeguards. We can discuss a range of options and consider the effect that each might have on privacy and compatibility under various conditions, then leave it to implementations to define how they want to select from that set of options.