Clarify ability to update interestGroup's userBiddingSignals through updateURL

[zapo]

Hello, we're trying to figure out the best place to passback user/device specific data known server side at join and update time that we can use at generateBid() time for decisionning. Looking at the spec/API and various discussions it seemed that userBiddingSignals would be the best place however it's unclear if it's meant to be updated through updateURL. Going through trustedBiddingSignals could be an alternative but is less desirable than storing directly on device.

After testing it's clear that it doesn't get updated. I can confirm by looking at chromium code that this field is not covered by the update.

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/interest_group_storage.cc;l=1507
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/interest_group_storage.cc;drc=a056443eb4e1a5922ce82b2d11a7b4e64e01f5a6;l=1560

If this is intentional, should we update https://github.com/WICG/turtledove/blob/main/FLEDGE.md to reflect that?
Currently the document says:

The updateURL provides a mechanism for the group's owner to update the attributes of the interest group: any new values returned in this way overwrite the values previously stored (except that the name and owner cannot be changed, and prioritySignalsOverrides will be merged with the previous value, with null meaning a value should be removed from the interest group's old dictionary)

Thanks!

[JensenPaul]

As we discussed on Wednesday's WICG call, userBiddingSignals is a good place for storing (by calling joinAdInterestGroup()) and updating (by calling joinAdInterestGroup()) information from the joining site. For information coming from other places (e.g. from advertisers, like changes to ad campaigns or budgets) using interest group updates or real-time trusted bidding signals works for the use cases we've heard of. I think we left updating userBiddingSignals out of interest group updates in the implementation and the spec because it was orthogonal to the purpose of the field. Can you explain a particular use-case for updating userBiddingSignals via interest group updates?

[bmilekic]

As we discussed on Wednesday's WICG call, userBiddingSignals is a good place for storing (by calling joinAdInterestGroup()) and updating (by calling joinAdInterestGroup()) information from the joining site. For information coming from other places (e.g. from advertisers, like changes to ad campaigns or budgets) using interest group updates or real-time trusted bidding signals works for the use cases we've heard of. I think we left updating userBiddingSignals out of interest group updates in the implementation and the spec because it was orthogonal to the purpose of the field. Can you explain a particular use-case for updating userBiddingSignals via interest group updates?

Our current design uses one interest group per advertiser domain. When a Chrome user visits the advertiser domain, they are added to a single IG, and userBiddingSignals is set with that specific user's bidding signal data. In general, users are recognized by some first-party uid (e.g., CHIPS) on the advertiser domain, and we encode this information in the updateURL that we set for that particular user.

We are looking to update userBiddingSignals without the user having to go back to the site where they were originally set / where the user joined the IG. There are many cases where the associated user's bidding signals would have changed even though the user has not gone back to the site. This happens for example when the advertiser site has linked offline data to the user, and the user may take some actions offline. For retailers with brick and mortar stores and loyalty programs, this is not that uncommon. For example, a user visits an advertiser's site, authenticates themselves with a Loyalty Member ID (thereby linking their visitor uid with their loyalty member data), and then a few days later makes a purchase offline.

Our understanding was that updateURL would allow us to do what we want. When Chrome calls updateURL, our previously encoded uid tells our system which user's data to lookup and return the freshest copy of. In the previously described example, uid would be linked to a loyalty member profile which in turn has updated offline purchase information inside of it, now returned as updated user bidding signals.

During Wednesday's WICG call, you suggested that we use the KV server to store and update user-level state instead. Am I remembering that correctly? I think we could technically do that, though it would mean dealing with a lot more keys in the KV server and looking up by uid there. Our current preference would be to be able to update the user's bidding signals via updateURL.

[michaelkleber]

I think we just need to break free of a little bit of history here :-).

The decision to not update the userBiddingSignals via updateURL dates back to a time when updates still required k-anonymity of the Interest Group. In that setting, of course updating userBiddingSignals didn't make sense, because you didn't know who the user was at update time. Now that IG update does not have a k-anon requirement, it seems to me that allowing userBiddingSignals updates is entirely consistent with the rest of the design.

[dmdabbs]

it seems to me that allowing userBiddingSignals updates is entirely consistent with the rest of the design.

So should @bmilekic et al open an InterestGroups issue requesting this amendment?

[caraitto]

@dmdabbs The work to implement this is tracked in https://crbug.com/1501828.