Attestation file endpoint

[jiali-ebay]

When we enroll the Privacy Sandbox, we are asked to input the site (scheme, eTLD+1). For example, our ad tech origin is https://www.example.com, so the site we enrolled is https://example.com. But we need to upload the attestation file on https://example.com/.well-known/privacy-sandbox-attestations.json
However, https://example.com doesn't under our control. Do we need to enroll the https://www.example.com again?
Or we can only add an endpoint without www.?

[jyfhsszq]

We got the same situation, https://example.com isn't under control. Usually, there is no proxy configuration for domain example.com. All traffic to example.com will be redirected to www.example.com automatically. If it's mandatory that the attestation file should be under example.com, we have to make a exceptional configuration which is very tricky and risky. Hi team, Could please remove this restriction which is really difficult for us?

[thegreatfatzby]

Agreed, having some flexibility here would be quite good.

[thegreatfatzby]

Hey fwends, curious if there's been some unannounced happy news that this has been made more flexible, perhaps by looking for the attestation file in the subdomain indicated in the IG/auction config. I ask b/c in doing a bunch of testing I had assumed that our internal folks had made the apex domain thing work, but in a conversation it became apparent that isn't the case and the apex domain still isn't resolving, i.e. https://adnxs.com/.well-known/privacy-sandbox-attestations.json fails.

I tried doing this on different machines, including both a) different machine same chrome account and b) different machine fresh chrome install (a Linux VM), and c) a different persons machine...and I see IGs being joined in an adnxs.com origin.

So I'm now wondering if either a) I'm magic (well, more-so than I already knew) b) there's a bug in Chrome c) there's a fix in Chrome d) other.