-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interest Group User Interaction w/r/t B & A Optimizations, Server Side Storage of User Bidding Signals in Particular #56
Comments
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. |
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. |
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 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 |
(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. |
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? |
This issue has been migrated to the new WICG/protected-auction-services-discussion repository. Please continue the discussion in the migrated issue here: WICG/protected-auction-services-discussion#19 |
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.
The text was updated successfully, but these errors were encountered: