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?
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
Sfor your enrollment, you must:S.ownerof yourIGs must match a siteS. If it does not, then the call to joinAdInterestGroup will fail?sellerattribute of the auction config must match yourS, and if it doesn't then the auction will not run?reportEventfor reporting clicks, views, video events, etc, go to a URL inS. If the beacon registered in reportResult/reportWin does not haveSas it's site, it won't send? Is that enforced at "declaration time" whenreportResult/reportWinregister the beacon usingregisterAdBeacon, or at run time when the event is invoked.S, and any event level or agg reports must be sent toS.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
Sif 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 assumeScan also be blacklisted?