privacysandbox / attestation Goto Github PK

Hello,

In the documentation on how to enroll, the location of the attestation file is not really clear with regards to the origin and possible subdomains used by an adtech.

Let's assume an adtech uses https://A.adtech.com for one Privacy Sandbox API (eg ARA) and https://B.adtech.com for another (eg Protected Audience).
In this example, should the attestation file be hosted on the common site (ie https://adtech.com/.well-known/privacy-sandbox-attestations.json) or on both origins (ie https://A.adtech.com/.well-known/... and https://B.adtech.com/.well-known/...)?

The documentation speaks of site, so I assume the first answer is the correct one, but I would rather ask before making any suppositions.

Thanks a lot!

I'm a little unclear, I don't see CHIPS called out in any of the fields for the attestation, should that be included?

We would like to estimate the expected traffic volume for the attestation files (e.g. https://example.com/.well-known/privacy-sandbox-attestations).
Are they going to be fetched by browser? When?
Will cache control headers be honoured?

The attestation is a single point of failure for running business using the Privacy Sandbox, and must be handled accordingly by Ad Tech participants.

The explainer says in 6. What happens if there are one-off errors in serving the attestation file? :

Access would be cut off only if the server checking the attestation file is repeatedly unable to validate it. A single error/serving issue would not cause access to be removed.

In order to adapt attestation serving and monitoring, could you please be more specific in the scenarios that would lead to API access removal? What's the expected SLA for attestation serving?

I'm trying to organize in my head all of the "impacts" of the choice of Site for your enrollment, and to some extent what it even means to like, enroll, man, and am hoping for confirmation.

Site Choice

So far I see that, given a choice of site S for your enrollment, you must:

• Place your attestation file in S.
• The owner of your IGs must match a site S. If it does not, then the call to joinAdInterestGroup will fail?
• I don't see it in the attestation but I assume that the assume the seller attribute of the auction config must match your S, and if it doesn't then the auction will not run?
• Once the IG has won, it's calls to reportEvent for reporting clicks, views, video events, etc, go to a URL in S. If the beacon registered in reportResult/reportWin does not have S as it's site, it won't send? Is that enforced at "declaration time" when reportResult/reportWin register the beacon using registerAdBeacon, or at run time when the event is invoked.
• ARA Reporting Origin must be in the S, and any event level or agg reports must be sent to S.

Enrollment

I feel like I understand what it means for a company to enroll: the company is saying it will follow the rules, not re-identify across contexts, make the file available at the well-known address, and expect to have their IGs/auctions/beacons/etc fail if the file doesn't serve (or if they are out of compliance, see below).

What does it mean for a developer at a company to enroll? I believe I'm seeing that local development can be done without enrollment, and since I don't see any requirements for app_user_ssp_* or service principles, once the code is deployed it's not "under Isaac Foster" or "Bill Gates" or "app_ssp_user_main"...so I'm not totally clear what that's giving.

Compliance

I do see that the attestation is not legally binding, but outside of the issue of continuous 404s of the well-known file, will you also be shutting off access for a site S if the organization behind it is deemed out of compliance? From what I can see the browser nodes will get communication from some home server checking well-knowns periodically, I'd assume S can also be blacklisted?

For registration purposes is use of Attribution-Reporting-Register-OS-Source considered a Chrome API or an Android use?

Must the point of contact be an individual's name, or can the name be a group, say 'Sandbox Platform Team' or similar?

The form requests two e-mail addresses, a point of contact and organisational support.
Confirming that the former is solely for outreach from Google, such as technical/business questions and will not be published, and that the latter is for inquries from the public and will be published.

The point-of-contact email address must be a "corporate email address that matches your organization's domain." By organization's domain you refer to the entity's corporate web presence, not the domain it will use for activating the APIs?

Where do you intend to publish the public-facing address?

In https://github.com/privacysandbox/attestation, I see an explanation for ServiceNotUsedForIdentifyingUserAcrossSites. However, in the attestation file, it contains ServiceNotUsedForReidentification. I do not see documentation/explanation for ServiceNotUsedForReidentification in https://github.com/privacysandbox/attestation. Could someone clarify and add an explanation for that?

EDIT: Solved

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.

We need to ensure we're consistent on which format is correct:

• /.well-known/privacy-sandbox-attestations
• /.well-known/privacy-sandbox-attestations.json

Raised via #24 (comment)

Are single redirects, such as from https://adtech.com to https://www.adtech.com, permitted when serving the attestations json?
A corporate site CMS may only accommodate serving a resource at https://www.adtech.com.

Using the process at https://github.com/protocol-registries/well-known-uris.