We're considering integrating FLEDGE with a flow that looks like:

1. The ad tag on the client sends a traditional contextual ad request.

2. It receives a contextual ad response, and also auction signals generated on the server, such as the estimated likelihood of the slot being viewable.

3. The tag invokes the FLEDGE APIs to run an interest group auction, providing those signals.

We are concerned that other scripts on the page could extract auction signals from the contextual ad responses. These signals are the outputs of complex proprietary models, and access to high-quality bidding signals is one reason buyers choose a particular sell-side platform.

Could FLEDGE provide a path for the server to provide auction signals to the browser auction, without making them accessible to other scripts on the publisher page? (We understand that this would not protect signals from headless browsers or manual inspection, and we think these vectors should be followed up separately.)

One way this could work would be if the worklet processing the decision logic began executing before the auction. The worklet could send a request to the ad server to fetch additional signals to append to auction_signals, which the server would restrict to the worklet's origin with an ACAO response header. If other scripts on the page attempted to read the response, they would be blocked by the same-origin policy.

Unfortunately this requires an additional round trip to fetch the signals. We could avoid that by having the contextual ad response be a web bundle, where the signals are provided in an opaque-origin resource, with an ACAO header limiting response access to the seller's origin. The ad tag could pass the opaque resource's URL to the decision logic worklet through auction_signals, and the signals fetch could be fulfilled from the bundle.