Usage of deprecatedReplaceInURN for domain macros

Here we see numerous privacy professors teaching their class about how to do string replacement. - iSac, ChatGPT, April 21, 2024.

deprecatedReplaceInURN Usage for Macros in Domain

Overview

Here we demonstrate usage of deprecatedReplaceInURN for replacing the domain target of a creative.

Chrome is in the process of making the availability and documentation of deprecatedReplaceInURN more official, but it will be around until 2026 as discussed here.

Prereqs

I haven't gotten back to Chrome yet on getting my attestation down, so for now see here.

Test

We declare one Interest Group with a macro using the ${macro} format, have the bidding function always return the one macro'ized URL, and see if both the join works and the replacement works and results in a call to the render the "creative", which in this case is just some server returned HTML that says the full url, including swapped domain, that was called..

My initial experiment was with the %%macro%% format and the join failed, and I've included that in the code so you can see the failure in console log, and in a screenshot below. However, it's possible there's just some encoding trick, but given it seems there is a solution here, I'll leave that as exercise for another time.

Per DDabbs, maybe has something to do with this?

See Me Work!!!

Choose the domain you want the creative rendered from.

The JS doing the replacement is here.
The server serving the "creative" is here.

Implications

If this is meant to be supported, it means we can do things with DNS based routing for rendering. It could open up a standards based way to let the seller and buyer do some cooperation using a protocol, or even trusted script that implements said protocol. This could help significantly with supporting adoption of different rendering formats, in particular the pieces that require some information from both the seller and buyer (vast and native come to mind).

This means we could in theory allow the SSP to route all rendering through their own endpoint. Basically, all SSPs would have a https://www.ssp-name.com/path/to/render?dspvariables&sspvariables endpoint, all DSPs would declare their renderUrls as https://${ssp-domain}/path/to/render?dspvariables&${ssp-variables}, and the SSP would wrap the DSPs call in a frame of it's own, using the ssp-domain to point to it's own endpoint, ssp-variables for things like tag id, publisher, etc, and the dsp variables would belong to the buyer and include the url for the SSP to inject (this could arbitrarily interesting, some kind of ORTB renderObject).

Constraints

Very worth seeing if Chrome intends to not allow this at all, i.e. is this something they previously didn't care about during join time url validation but now will.

%%macro%% format either doesn't work or needs some encoding.