Interest Group User Interaction w/r/t B & A Optimizations, Server Side Storage of User Bidding Signals in Particular

[kevinkiklee]

From fledge-docs created by thegreatfatzby: privacysandbox/protected-auction-services-docs#56

I believe one of the goals of the the sandbox has been to make it easier for consumers to understand how they are being targeted (comment here) and to be able to delete that (I believe I've seen that in a few places but for now can't really find it spelled out, maybe "long term unlinkability" would imply that if PS is adopting that (are you? :) )).

The initial on device version of PaApi enabled this in a pretty strong way with all local storage and processing of IGs and creatives. We've had to make tradeoffs in the move towards B & A and the iterative nature of some of the requirements (i.e. event level reporting till 2026), but in particular I'd like to understand how we'll enforce/try-to-enforce the Interest Group View/Delete-ability with the suggested (and wise) payload optimization of user bidding signals. It seems an important top level privacy goal that gets a bit trickier in a server side world, and while the tradeoff may be worth it (I think it is) we'd want to account for that if we can.

Will there be an expectation that the KV server will provide a GET and DELETE service that the browser can use to pull the bidding signals and delete them? Would that be a technical solve, in that the the browser would do some mini-service-discovery, "enforced" via the attestation, or some combination? Happy to kick this around.

[kevinkiklee]

Original comment by JensenPaul: privacysandbox/protected-auction-services-docs#56 (comment)

---

Side note: it looks like your 3rd link goes to the same place as your 2nd. I suspect your 3rd comment meant to link here.
I look forward to discussing on the WICG call in a couple hours.

[kevinkiklee]

Original comment by thegreatfatzby: privacysandbox/protected-auction-services-docs#56 (comment)

---

I have failed https://www.youtube.com/watch?v=W647gDp-u-s

[kevinkiklee]

Can you explain how the payload optimizations of user bidding signals affects the interest group view/delete-ability? As I understand it, the interest groups stored on-device still contain the full ad URLs and thus I think the browser retains its ability to view and delete interest groups.

Can you explain why the browser would delete bidding signals? This seems like a violation of the "has no other side effects based on these requests" constraint on the server that helps protect the user's privacy.

[kevinkiklee]

Original comment by thegreatfatzby: privacysandbox/protected-auction-services-docs#56 (comment)

---

So perhaps I'm not understanding properly, but I'm reading the B & A Payload Optimizations proposed here to mean that the "state" of the IG would now be split between the client and server, so that the On Device piece would now have a key, presumably a first party cookie or PPID, that would be sent to the BA auction to join the userBiddingSignals and other other server side stored piece, so that potentially very large userBiddingSignals blobs would be not need to be sent over the wire on every request.

If that's the case, then I'd think we'd want the deletion of the IG to also result in the deletion of the server side userBiddingSignals, or anything else associated with the IG definition. I'd think we'd also want the view'ing part as well, but of course userBiddingSignals may not be cognizable to a human (even a technically trained one) and so might be less valuable.

[kevinkiklee]

Original comment by chatterjee-priyanka: privacysandbox/protected-auction-services-docs#56 (comment)

---

(I am still trying to understand the problem, apologies in advance if my comment is not addressing it.)

I think B&A's payload optimization may be orthogonal to how interest groups are fetched and the associated TTL on the client. When the interest group is no longer valid / expired, the interest group shouldn't even be sent in ProtectedAuctionInput.BuyerInput to B&A. Fetching user_bidding_signals from KV server is an optimization and it is up to the DSP if they want to have additional key for the lookup from buyer's KV server. The user_bidding_signals can be made available in trusted_bidding_signals as well such that it can be ingested by buyer's generateBid() and no additional call to buyer KV may be required.

Though let us know if you think an additional key (if required for fetching user_bidding_signals server side should be passed in a separate field in interest group to the client). I am trying to seek some feedback from adtechs about that. Thanks.

[kevinkiklee]

Original comment by hbikmal: privacysandbox/protected-auction-services-docs#56 (comment)

---

Deletion of users browsing history on advertisers site (list of interest groups) from advertisers database is probably not the responsibility of fledge. Fledge enables/disables the advertisers ability to recommend ads. If the advertiser_specific_user_id IG is registered in the browser, advertiser can use all its history, including the products viewed 2 years ago to recommend ads (subject to various other privacy guidelines).

Its the same even without the B&A server. A new tagging call can register all the IGs the user ever joined whenever the user comes back to the advertiser site. This works even if all IGs got expired in the browser before revisiting the advertiser site.

Did I get it right?