Surfaced by @tomvangoethem in review of #73.
The budget replenishes on user activation with no ceiling on total distinct hashes, and a hash stays in the probe set free forever once resolved. So a site the user visits often keeps everything it has already resolved and keeps earning more. The bound describes a single visit, not a lifetime.
The proposed text is more permissive than that framing suggests: it is a lifetime accumulator rather than a per-visit allowance. A tracker delivered as <script src> inherits the first party's budget, so on a frequently visited site it accrues steadily.
Why it matters. A tracker with no storage of its own must re-read the bits on every visit to use them. So the quantity that determines whether it can recognise a user is how many distinct hashes it can hold resolvable at one time, not how many it has resolved cumulatively.
Direction under consideration. Cap the probe set's size, LRU-evicted, so a site holds a bounded number of hashes resolvable for free at once and re-resolving an evicted one costs budget again. Expiry alone is not sufficient: with a long window and an interactive user, a set can still grow wide before anything expires. Capping size is what bounds width.
Open. The resulting bound is on the order of the cap plus one visit's budget rather than exactly the cap, and whether that constant is small enough depends on the budget value, which is itself unsettled. Interacts with the keying question in the companion issue.
From #73 (comment).
Surfaced by @tomvangoethem in review of #73.
The budget replenishes on user activation with no ceiling on total distinct hashes, and a hash stays in the probe set free forever once resolved. So a site the user visits often keeps everything it has already resolved and keeps earning more. The bound describes a single visit, not a lifetime.
The proposed text is more permissive than that framing suggests: it is a lifetime accumulator rather than a per-visit allowance. A tracker delivered as
<script src>inherits the first party's budget, so on a frequently visited site it accrues steadily.Why it matters. A tracker with no storage of its own must re-read the bits on every visit to use them. So the quantity that determines whether it can recognise a user is how many distinct hashes it can hold resolvable at one time, not how many it has resolved cumulatively.
Direction under consideration. Cap the probe set's size, LRU-evicted, so a site holds a bounded number of hashes resolvable for free at once and re-resolving an evicted one costs budget again. Expiry alone is not sufficient: with a long window and an interactive user, a set can still grow wide before anything expires. Capping size is what bounds width.
Open. The resulting bound is on the order of the cap plus one visit's budget rather than exactly the cap, and whether that constant is small enough depends on the budget value, which is itself unsettled. Interacts with the keying question in the companion issue.
From #73 (comment).