Feature request: Provide low-entropy UACH on Real-Time Reporting postbacks

[dmdabbs]

The new Real-Time Reporting API histogram postbacks' usability could be improved with the inclusion of low entropy UACH. Opening this issue per suggestion in the 31 July WICG discussion.

Chrome Canary DevTools, 31-July:

POST /.well-known/interest-group/real-time-report HTTP/1.1
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 206
Content-Type: application/cbor
Host: test.dabbs.net
Origin: https://www.mojotest.com
Pragma: no-cache
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36

[ajvelasquez-privacy-sandbox]

@dmdabbs given the discussion on item #1031 it is not clear to me whether this specific ask is still valid. If so, do you mind please summarizing what specific usability problem you're trying to solve for here?

[dmdabbs]

Hello @ajvelasquez-privacy-sandbox. MK does indicate that the initial request for UACH on BuyerTrustedServer fetches could be accomplished by other means and so was not particularly pressing. He ended by indicating that

There is a more compelling case for making the low-entropy UACH signals available during the IG's periodic calls to its updateURL, which trigger a call to a normal non-TEE'd server. I see @dmdabbs has already opened #1240 to request this.

Similar request here - receive clear low-entropy UACH for correlating with troubleshooting reports.

[ajvelasquez-privacy-sandbox]

@dmdabbs of course, thanks. What I'm asking for tho is, can you please specify why does this improve usability? What is painful now that get less painful if this request is addressed?