Skip to content

Commit

Permalink
Add description of how trustedScoringSignalsUrl works (#230)
Browse files Browse the repository at this point in the history
* Update FLEDGE.md

Add description of how trustedScoringSignalsUrl works.
  • Loading branch information
MattMenke2 authored Nov 8, 2021
1 parent eeb1313 commit e603b09
Showing 1 changed file with 24 additions and 1 deletion.
25 changes: 24 additions & 1 deletion FLEDGE.md
Original file line number Diff line number Diff line change
Expand Up @@ -232,7 +232,30 @@ Buyers may want to make on-device decisions that take into account real-time dat
The base URL `https://www.kv-server.example/getvalues` comes from the interest group's `trustedBiddingSignalsUrl`, the hostname of the top-level webpage where the ad will appear `publisher.com` is provided by the browser, and `keys` is a list of `trustedBiddingSignalsKeys` strings, perhaps coalesced (for efficiency) across any number of interest groups that share a `trustedBiddingSignalsUrl`. The response from the server should be a JSON object whose keys are key1, key2, etc., and whose values will be made available to the buyer's bidding functions (un-coalesced).
Similarly, sellers may want to fetch information about a specific creative, e.g. the results of some out-of-band ad scanning system. This works in the same way, with the base URL coming from the `trustedScoringSignalsUrl` property of the seller's auction configuration object, and the keys being the `renderUrl` fields of all entries in the `ads` and `adComponents` fields of all interest groups in the auction. The value associated with a `renderUrl` key is provided as the `trustedScoringSignals` parameter to the seller's `scoreAd()` function.
Similarly, sellers may want to fetch information about a specific creative, e.g. the results of some out-of-band ad scanning system. This works in much the same way, with the base URL coming from the `trustedScoringSignalsUrl` property of the seller's auction configuration object. However, it has two sets of keys: "renderUrls=url1,url2,..." and "adComponentRenderUrls=url1,url2,..." for the main and adComponent renderUrls bids offered in the auction. It is up to the client how and whether to aggregate the fetches with the URLs of multiple bidders. The response to this request should be in the form:
```
{ 'renderUrls': {
'https://cdn.com/render_url_of_some_bid': arbitrary_json,
'https://cdn.com/render_url_of_some_other_bid': arbitrary_json,
...},
'adComponentRenderUrls': {
'https://cdn.com/ad_component_of_a_bid': arbitrary_json,
'https://cdn.com/another_ad_component_of_a_bid': arbitrary_json,
...}
}
```
The value of `trustedScoringSignals` passed to the seller's `scoreAd()` function is an object of the form:
```
{ 'renderUrl': {'https://cdn.com/render_url_of_bidder': arbitrary_value_from_signals},
'adComponentRenderUrls': {
'https://cdn.com/ad_component_of_a_bid': arbitrary_value_from_signals,
'https://cdn.com/another_ad_component_of_a_bid': arbitrary_value_from_signals,
...}
}
```
_As a temporary mechanism_ during the First Experiment timeframe, the buyer and seller can fetch these bidding signals from any server, including one they operate themselves (a "Bring Your Own Server" model). However, in the final version after the removal of third-party cookies, the request will only be sent to a trusted key-value-type server. Because the server is trusted, there is no k-anonymity constraint on this request. The browser needs to trust that the server's return value for each key will be based only on that key and the hostname, and that the server does no event-level logging and has no other side effects based on these requests.
Expand Down

0 comments on commit e603b09

Please sign in to comment.