You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prompt for discussion in SPARROW technical workshop July 16th (see #14):
The aggregated report "with the possibility to have real-time information" needs that turn-around "to be able to pause/start, control budget/bidding level, ... with very little latency."
Updating the value in real time seems problematic — I don't see how we could keep it from being used as a signal to detect individual events. The contextual signals mean that the buyer network is in a position to pick out one specific auction and give some campaign the instruction to bid on it. But if there is some campaign that only has one opportunity to show an impression during some minute, and the advertiser sees that campaign's budget drop vs. remain unchanged during that minute, then we've allowed the buyer network to learn the exact context (including publisher-domain identity!) of a person who saw some ad. This is enough to join people's identities across domains.
It seems to me that there are a variety of ways to avoid this privacy problem, which all come down to not letting the buyer observe a very small number of events. That is, "real time" isn't the problem, "real time even if the change is only a handful of events" is the problem.
I'd like to talk about the specific ad buyer flows that you want to support, so that we can figure out what possible approaches could meet those needs without risking buyers seeing the results of individual auctions.
The text was updated successfully, but these errors were encountered:
Following our workshop, please find below a summary of the discussions around this issue. The full video can be found here, password:"0Y$y0.R$" . We invite participants to comment if they want to add a specific point or want to correct the following summary of the discussions.
The report used for real-time reporting will be differential private and therefore come with the appropriate privacy guarantee.
However, differential private noise is additive (each query ads noise to the output) and asking for regular reports will increase the overall noise level.
An intelligent way to handle this report for billing (where low noise is a necessity) and real-time spend management (where noise is less of an issue, but reactivity is paramount) needs to be found. This technical point, if not trivial, should not be insurmountable and no other strong objections were raised on this report.
Prompt for discussion in SPARROW technical workshop July 16th (see #14):
The aggregated report "with the possibility to have real-time information" needs that turn-around "to be able to pause/start, control budget/bidding level, ... with very little latency."
Updating the value in real time seems problematic — I don't see how we could keep it from being used as a signal to detect individual events. The contextual signals mean that the buyer network is in a position to pick out one specific auction and give some campaign the instruction to bid on it. But if there is some campaign that only has one opportunity to show an impression during some minute, and the advertiser sees that campaign's budget drop vs. remain unchanged during that minute, then we've allowed the buyer network to learn the exact context (including publisher-domain identity!) of a person who saw some ad. This is enough to join people's identities across domains.
It seems to me that there are a variety of ways to avoid this privacy problem, which all come down to not letting the buyer observe a very small number of events. That is, "real time" isn't the problem, "real time even if the change is only a handful of events" is the problem.
I'd like to talk about the specific ad buyer flows that you want to support, so that we can figure out what possible approaches could meet those needs without risking buyers seeing the results of individual auctions.
The text was updated successfully, but these errors were encountered: