-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting 3PAS subframes in Protected Audience API #877
Comments
Option 1 that requires opt-in by the 3PAS subframe is aligned with the web security guidelines for cross-origin information sharing, since this proposal requires information (that a click happened and a top-level navigation was initiated) from an iframe to go to a destination selected by a cross-origin context (via registerAdBecon). This security concern was also discussed in the issue here. To clarify option 1.1 a bit more, does the automatic beacon for the 3PAS cross-origin frame require data to be added by the parent frame? This is slightly more complex API design than 1.2 where data and beacon are both associated with the same frame, so wanted to confirm this requirement. It would also be helpful to hear from any 3PASs about the difference in adoption complexity for them between 1.1 and 1.2. Option 2 is hard because this is introducing an information channel (even if temporary) that does not yet exist on the web-platform, even with 3rd party cookies. |
Confirming that for option 1.1 the automatic beacon for the 3PAS cross-origin subframe will require event data to be added by the parent frame, i.e., calling |
Thanks! The current proposal is given below which aligns with option 1.1: A new response header will be added which, if added to the document response of the cross-origin iframe, will allow 3PAS subframes to send automatic beacons. They cannot set automatic beacon data by invoking |
Adding more details to the above design: We propose introducing a new For ads loaded in fenced frames, the server can use the |
The API shape has slightly changed. The parameter is now going to be called |
Thanks @blu25. So this?
Also would you mind please posting the Monorail issue for the work? |
Exactly. Here is the crbug link: https://crbug.com/1504306 |
As a DSP we work with a lot of 3rd party adservers and one caveat i see with this integration is there is no support of adding separate attribution source URL. Sometimes its not possible to use the same clickthrough URL to register attribution source and need a separate URL which is actually doing the attribution registration. In absence of this support DSP might need to have custom ways to implement this. Can we look at adding attributionsrc for automatic beacons either during registerAdBeacon or during setReportEventDataForAutomaticBeacons. If an attributionsrc is explictly specified chrome should automatically also register the attribution source by calling the URL in attributionsrc. |
Problem
3PAS (Third-party ad serving) is an approach where we / DSP store and serve an ad tag (tag = snippet of HTML) in place of the ad. The tag is sent to the client, which then executes the HTML and retrieves the actual ad from a third-party.
Display ads can have subframes that contain the actual creative content. The sub-frame’s domain may differ from the main frame’s domain. We intend to use
reserved.top_navigation
automatic beacons to record navigation clicks with the current FLEDGE API. However, when clicks occur within sub-frames that are cross origin to the main frame, these automatic beacons will not be sent out.Example
DSP calls
reigsterAdBeacon
ingenereateBid()
:setReportEventDataForAutomaticBeacons
is called at creative rendering time:Proposal
Option 1 - 3P Ad Tech opt-in
Chrome provides a way for third-party ad techs to opt in Protected Audience API, which permits the main frame to report navigations from cross-origin subframes.
Option 1.1 - Opt-in by response header
3P ad techs can opt in by including a new header in their response to the subframe request initiated from the main frame, which allows automatic beacons to be sent out when navigation is triggered within the subframe.
Example:
protected-audience-navigation-reportable: true
Option 1.2 - Opt-in by calling setReportEventDataForAutomaticBeacons
3P ad techs can opt in by calling the
setReportEventDataForAutomaticBeacons
API in the subframe, which allows automatic beacons to be sent out when navigation is triggered within the subframe.Example:
Option 2 - Relax cross-origin enforcement until 3PCD
This option allows the main frame to use the navigation API to report clicks from subframes that have a different origin until 3PCD. This will give us the ability to validate 3PAS ads in FLEDGE while we develop a permanent solution post 3PCD.
The text was updated successfully, but these errors were encountered: