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
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?
The text was updated successfully, but these errors were encountered:
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:S
.owner
of yourIG
s must match a siteS
. If it does not, then the call to joinAdInterestGroup will fail?seller
attribute of the auction config must match yourS
, and if it doesn't then the auction will not run?reportEvent
for reporting clicks, views, video events, etc, go to a URL inS
. If the beacon registered in reportResult/reportWin does not haveS
as it's site, it won't send? Is that enforced at "declaration time" whenreportResult
/reportWin
register 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
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 assumeS
can also be blacklisted?The text was updated successfully, but these errors were encountered: