You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The attestation process claims that I can't use HTTP redirects to serve the attestation file. I would understand this where the redirect goes to a different TLD+1 but where the redirect handles to the same TLD+1 but say... at a subdomain, this should be acceptable behavior. Presumably the issue is assuring individual domains do their own attestation and that's fine, but it isn't an uncommon use case for sites to serve entirely through a TLD+2 URL.
This is very common for sites and publishers who force all traffic to www. for consistent URLs. Especially because keeping all URLs to a consistent either TLD+1 or www. is a thing Google's search engine is generally understood to prefer. It's generally understood that should a site not do so that would conflict with directives from Google products like Search Console. If Google strongly suggests global redirection to or away from www. from domains it seems questionable to not allow a domain to serve the attestation file from www.[domain].com/.well-known/privacy-sandbox-attestations.json. Additionally, while enrollment requires the TLD+1 be entered, there are other configurations one commonly sees where the domain is primarily served from TLD+2, this includes government and national domains [domain].co.uk or [domain].gov.uk and academic domains. It also has been popular to compose domains in the style of well.known.com and operate only off the TLD+2. All these styles of domain might have good reason to participate in enrollment. At the very least the domain I represent does and does operate at www..
In any case where the TLD+1 hosting of the attestation file redirects to a TLD+1+x hosting of the attestation file and where the TLD+1 is the same in both cases, this should be considered acceptable.
The attestation process claims that I can't use HTTP redirects to serve the attestation file. I would understand this where the redirect goes to a different TLD+1 but where the redirect handles to the same TLD+1 but say... at a subdomain, this should be acceptable behavior. Presumably the issue is assuring individual domains do their own attestation and that's fine, but it isn't an uncommon use case for sites to serve entirely through a TLD+2 URL.
This is very common for sites and publishers who force all traffic to
www.for consistent URLs. Especially because keeping all URLs to a consistent either TLD+1 orwww.is a thing Google's search engine is generally understood to prefer. It's generally understood that should a site not do so that would conflict with directives from Google products like Search Console. If Google strongly suggests global redirection to or away fromwww.from domains it seems questionable to not allow a domain to serve the attestation file fromwww.[domain].com/.well-known/privacy-sandbox-attestations.json. Additionally, while enrollment requires the TLD+1 be entered, there are other configurations one commonly sees where the domain is primarily served from TLD+2, this includes government and national domains[domain].co.ukor[domain].gov.ukand academic domains. It also has been popular to compose domains in the style ofwell.known.comand operate only off the TLD+2. All these styles of domain might have good reason to participate in enrollment. At the very least the domain I represent does and does operate atwww..In any case where the TLD+1 hosting of the attestation file redirects to a TLD+1+x hosting of the attestation file and where the TLD+1 is the same in both cases, this should be considered acceptable.