Surfaced by @tomvangoethem in review of #73, referencing ephemeral fingerprinting.
There is no script-facing removal API. But Eviction says that clearing an origin's site data removes that origin from every storing origins set, and that an entry whose storing origins is then empty may be considered for deletion. The spec does not say what a site-initiated clearing does there. So a site that is the sole storer of a resource can plausibly cause its removal at a moment of its choosing, and a second site polling for that resource observes the transition. The timing is the identifier, and no stored value is needed.
Removal is not even required: where disclosure hinges on storing origins membership, as it does for the same-site and list tiers, dropping out of that set is itself observable.
The probe budget does not bound this. Repeated probes of one hash are free after the first charge, by design, because re-probing yields no bit the caller does not already have. That property is what makes the identifier-width argument work, and it is also what makes polling for a disappearance cheap. The two pull in opposite directions.
Direction under consideration. A site-initiated clearing must not remove an entry or make it eligible for deletion, leaving user-initiated clearing and user-agent eviction as the only removal paths, neither of which an attacker times.
Open. That does not fully close it, since storage pressure is weakly attacker-influenceable. This may be better written up as a named limitation with a stated mitigation than claimed as solved.
From #73 (comment).
Surfaced by @tomvangoethem in review of #73, referencing ephemeral fingerprinting.
There is no script-facing removal API. But Eviction says that clearing an origin's site data removes that origin from every
storing originsset, and that an entry whosestoring originsis then empty may be considered for deletion. The spec does not say what a site-initiated clearing does there. So a site that is the sole storer of a resource can plausibly cause its removal at a moment of its choosing, and a second site polling for that resource observes the transition. The timing is the identifier, and no stored value is needed.Removal is not even required: where disclosure hinges on
storing originsmembership, as it does for the same-site and list tiers, dropping out of that set is itself observable.The probe budget does not bound this. Repeated probes of one hash are free after the first charge, by design, because re-probing yields no bit the caller does not already have. That property is what makes the identifier-width argument work, and it is also what makes polling for a disappearance cheap. The two pull in opposite directions.
Direction under consideration. A site-initiated clearing must not remove an entry or make it eligible for deletion, leaving user-initiated clearing and user-agent eviction as the only removal paths, neither of which an attacker times.
Open. That does not fully close it, since storage pressure is weakly attacker-influenceable. This may be better written up as a named limitation with a stated mitigation than claimed as solved.
From #73 (comment).