FFAR in Origin trials

[michal-kalisz]

Hi,

We have noticed that for users who participate in OT, some features are not available - especially Fenced Frame Ad Reporting.

Let's consider case:

1. in reportWin add registerAdBeacon
2. Ad rendered in fenced frame report event by FFAR (fence.reportEvent)

For User in OT: FFAR seams to be not available:
Condition "window.fence && fence.reportEvent" are not met.

But when User in OT enable flag 'Privacy Sandbox Ads APIs' - FFAR starts to be available and request are send.

I was wondering if it is possible to turn on FFAR for OT?
Would it be possible to provide full set of flags that has to be enabled to have exactly the same setting as user in OT?

Second thing - more related to cookies - we observe that if ad is rendered by iframe (with opaque url) request send to render_url contains cookies in header, but for FF it is not.
I suppose it is related to partitioned cookies (CHIPS), but is there other logic for iframe than for FF ?

I am aware that eventually cookie will not be available, but for current stage of fledge testing I assumed that it is available.

Bests,
Michal

[shivanigithub]

Thanks for the questions!

I was wondering if it is possible to turn on FFAR for OT? Would it be possible to provide full set of flags that has to be enabled to have exactly the same setting as user in OT?

Being in OT should indeed be enabling both fenced frames and FFAR automatically. Could you please confirm which Chrome version you are using?

Second thing - more related to cookies - we observe that if ad is rendered by iframe (with opaque url) request send to render_url contains cookies in header, but for FF it is not. I suppose it is related to partitioned cookies (CHIPS), but is there other logic for iframe than for FF ?

I am aware that eventually cookie will not be available, but for current stage of fledge testing I assumed that it is available.

You are right, fenced frames are using a unique partition for all cookies while iframes don't do that. Even for the testing phase, fenced frames cookies are set up to behave as they would in the long term.

[michal-kalisz]

Thank you for the answers.

My assumption about FFAR was based on two observations:

1. We added to creative(ad) simple invocation of fence.reportEvent. (Example of creative)
   Publisher - changed iframe to fenced frame (in opaque mode)
   For real user in FOT we observed - no cookie in header, no "FFAR" request

2. In locally installed canary chrome (version below) I made experiment:

• clear chrome, no additional flags
• assign to OT
• display ad in fenced frame: no cookie, no request to FFAR
• in chrome chrome://flags/ enable "Privacy Sandbox Ads APIs"
• again display ad in fenced frame: no cookie, request to FFAR was sent.
  (I understand why cookie is not send in header)

My version:
Google Chrome | 105.0.5151.0 (Official Build) canary (arm64)
Revision | 3756c84ef5534a806bff0d7016b1aee108fc0740-refs/branch-heads/5151@{#1}
OS | macOS Version 12.3.1 (Build 21E258)

[shivanigithub]

(Catching up on this thread after the holidays)

Thanks for the details!

Just to correct/clarify my earlier response, the OT being enabled itself is not sufficient for all users' browsers to be able to access the privacy sandbox APIs. A given user's participation is controlled by Chrome based on whether they are in the enabled experiment group or not. A user that is in the experiment group will automatically have the "Privacy Sandbox Ads APIs" flag enabled but not otherwise.

So your observation that everything works after enabling the flag is correct. Although I would expect that without the flag enabled, not just FFAR but FLEDGE and fenced frames will also not work.

[michal-kalisz]

Hi,
thanks for the answer.
I think it is clear. I was thinking about users that are in experiment group.

One thing that we fixed in our side is that ad (response from render url) didn't contain Origin Trial header / meta.
So we started to receive event request from FFAR.

But unfortunately not all - in some cases OT was disabled due to "insecure context":

• publisher use Google Ad Manager to display ad
• it creates iframe dynamically - by js (iframe doesn't have src) like:
  <iframe id="google_ads_iframe_/34616581,22608002814/lagacetadesalamanca.es/home/portada/sticky_0" name="google_ads_iframe_/34616581,22608002814/lagacetadesalamanca.es/home/portada/sticky_0" title="3rd party ad content" width="970" height="90" scrolling="no" marginwidth="0" marginheight="0" frameborder="0" role="region" aria-label="Advertisement" tabindex="0" allow="attribution-reporting" srcdoc="" data-google-container-id="h" data-load-complete="true" style="border: 0px; vertical-align: bottom;"></iframe>
• iframe is seems to be secure:

- within this iframe another iframe with URN are created. But it is insecure and therefore OT status is ValidTokenNotProvided:

Status in details:

Appreciate for your help!

[shivanigithub]

Thanks for the details!
(I think we can close this issue. I don't think I have the access to close it)

[michal-kalisz]

Hi,
If this is ok for you I would like to keep this issue open as from our perspective it is not solved. Although I agree it is not strictly associated with FFAR, but more with Origin Trials: how it can be enabled inside nested frames.

To sum up the problem we observed:

<iframe srcdoc=””>
	<iframe src=”<secured url to ad/>”/>
</iframe>

The nested iframe (with ad) is marked as insecure!

But if srcdoc is not empty:
<iframe srcdoc="<iframe src='<secured url to ad’/>"></iframe>
Or if does not contain srcdoc
Then the nested iframe is marked as secure!

Example:
https://jsfiddle.net/ejytvbgw/1/

        <iframe id="with_empty_srcdoc" srcdoc="" width="200" height="200" ></iframe>
        <iframe id="without_srcdoc" width="200" height="200" ></iframe>
        <iframe id="with_non_empty_srcdoc" srcdoc="<iframe src='https://creativecdn.com/creatives?id=6F5AeFDSQ4j6D1XoJzHb&cs=320x100&c=kQKZEgHd2MX0GUG9VHAS&s=rtbhfledge'/>" width="200" height="200" ></iframe>
<script>
var ad_url = 'https://creativecdn.com/creatives?id=6F5AeFDSQ4j6D1XoJzHb&cs=320x100&c=kQKZEgHd2MX0GUG9VHAS&s=rtbhfledge'
document.querySelector('#with_empty_srcdoc')
        .contentDocument.write("<h1>Injected from parent frame</h1><script>console.log(window.isSecureContext);<\/script><iframe src='"+ad_url+"'/>")
document.querySelector('#without_srcdoc')
        .contentDocument.write("<h1>Injected from parent frame</h1><script>console.log(window.isSecureContext);<\/script><iframe src='"+ad_url+"'/>")

</script>

The first one iframe is marked as insecure:

But second one and third one are secure:

@shivanigithub could you please let me know if this is indeed intended behaviour? It makes real life OT testing much harder

[shivanigithub]

cc @mikewest for thoughts on the impact of srcdoc attribute on whether the context is considered secure.
MIke: I went through https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy which mentions about:srcdoc is considered trustworthy but wasn't sure if there was another part of the spec that differentiates an empty srcdoc attribute with a non-empty one and defines the former as non-secure.

[mikewest]

There shouldn't be a meaningful distinction between <iframe srcdoc=""> and <iframe>. They're certainly implemented differently internally, though, so I can totally believe that something is confused in this edge case.

I'd suggest filing a bug against Chromium at https://crbug.com/new.

[michal-kalisz]

Thanks a lot!
I reported a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1344887
I would really appreciate if you could increase priority of this bug.

Thanks,
Michal

[mikewest]

I would really appreciate if you could increase priority of this bug.

Can you help me understand why this issue has a higher priority? It seems like simply omitting the srcdoc attribute is a sufficient workaround. Is there a reason that fails to satisfy your needs?

[michal-kalisz]

I agree that omitting problematic attribute is good workaround as long as there is an easy way to do this.

Currently in many cases Publisher uses Google Ad Manager to create iframe: as we observed GAM creates iframe with srcdoc.
Unfortunately, we - as RTB House (DSP) - cannot change parent iframe as we only provide url to inner frames (ad and ad components)

I asked to prioritize the issue to have possibility to test FFAR (and possible other Privacy Sandbox API) during FOT.

[jeffkaufman]

@zhengweiwithoutthei in case you know why GAM creates iframes with an empty srcdoc, and in case this isn't actually needed on modern Chrome

[zhengweiwithoutthei]

We are working on solving this issue by removing the srcdoc from GPT. It was intended as a temporary solution for a bug that was already fixed in Chrome.

[michal-kalisz]

@zhengweiwithoutthei friendly reminder. Do you have maybe any update on this issue?

[zhengweiwithoutthei]

We are close to remove it from GPT completely. ETA 2 weeks.

[zhengweiwithoutthei]

The empty srcdoc has been removed from GPT.

[michal-kalisz]

Thank you very much for support and applying changes in GPT.
We have seen an increase in reported FFAR events from ads from various publishers.

We still have problems how to observe clicks in ad components - but this case is raised in #332.
I will close this issue and continue subject in #332.