Supporting 3PAS subframes in Protected Audience API

[keweigegoog]

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 in genereateBid():

registerAdBeacon({
 'reserved.top_navigation': 'https://adtech.example/click?buyer_event_id=123',
});

setReportEventDataForAutomaticBeacons is called at creative rendering time:

<iframe src='adtech.example'>

// Controlled by DSP
win.fence.setReportEventDataForAutomaticBeacons(
     'eventType': 'reserved.top_navigation',
     'eventData': JSON.stringify(eventData),
     'destination': ['buyer'],
);

  <iframe src='thirdpartyadtech.example'>
    …
  </iframe>

…
</iframe>

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:

<iframe src='adtech.example'>

  <iframe src='thirdpartyadtech.example'>
    // Controlled by third-party
    win.fence.setReportEventDataForAutomaticBeacons(
         'eventType': 'reserved.top_navigation',
         'eventData': JSON.stringify(eventData),
         'destination': ['buyer'],
    );
    …
  </iframe>

…
</iframe>

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.

[shivanigithub]

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.

[keweigegoog]

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.

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 setReportEventDataForAutomaticBeacons in the mainframe.

[blu25]

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 setReportEventDataForAutomaticBeacons in the mainframe.

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 setReportEventDataForAutomaticBeacons(), as is the current behavior. However, the render-url ad frame can set the event data which will be attached to the beacons. For that, the render-url ad frame will need to set a new crossOrigin field in setReportEventDataForAutomaticBeacons() to true.

[blu25]

Adding more details to the above design:

We propose introducing a new Allow-Fenced-Frame-Automatic-Beacons response header. This will be set to true by the 3PAS server to opt in a 3PAS document to sending automatic beacons: Allow-Fenced-Frame-Automatic-Beacons: true.

For ads loaded in fenced frames, the server can use the Sec-Fetch-Dest: fencedframe header to determine if the target document will need access to this API, but since URN iframes are being currently used for protected audience ads, the server will need to supply the Allow-Fenced-Frame-Automatic-Beacons: true response header for any pages that can be loaded in Protected Audience ad frames.

[blu25]

The API shape has slightly changed. The parameter is now going to be called crossOriginExposed. I'll update if anything else changes.

[dmdabbs]

Thanks @blu25. So this?

 win.fence.setReportEventDataForAutomaticBeacons(
         .....
         'crossOriginExposed': true
    );

Also would you mind please posting the Monorail issue for the work?

[blu25]

Thanks @blu25. So this?

win.fence.setReportEventDataForAutomaticBeacons(
.....
'crossOriginExposed': true
);

Exactly. Here is the crbug link: https://crbug.com/1504306

[sunnypav]

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.