Hi @alois-bissuel (apologies for the delay, I was ooo)

IMU disabling the permissions policy isn't desirable even during the OT, given it's a security/trust feature.
I'm in touch with the Chrome Eng team too and will come back to you with details on that OT question specifically.

IMU your biggest issue at the moment is nested iframes, is this correct? E.g. what you're encountering in #38?

For discussion on the blocks caused by Permissions Policy, I've filed WICG/attribution-reporting-api#519. Please do chime in on that issue with details!

For your OT-related questions we should keep the conversation here in privacy-sandbox-dev-support, but since the issues you're encountering seem to be general limitations due to the permissions policy, we should also talk about it in the WICG, hence the new issue.

Thanks Maud for the answer.

My issue is more broad than the nested iframes problem described in #38. Some actors in the adtech industry are not aware that this OT is taking place, and don't bother passing on the permission. I am sure that if the attribution reporting API were to be put in production, these actors would (in the long run after some adaptation) allow this API, hence my desire to remove the permission policy system. This would enable a better understanding of the performance by the final users of this API.
In the long run, a permission policy system is more than desirable, as it is a trust feature.
To me, it all depends on what the aim of the OT is. Do we want to showcase the complexity of the adtech ecosystem, or simply test the pure performance of the API?

Thanks Alois,
So, IMU, feature-detecting the API and excluding the traffic where the API isn't allowed isn't solving your real issue for the OT, because this means you still lose some portion of the data due to the disabled API⏤data you have otherwise access in a measurement system based on third-party cookies.
Can you confirm?

I am not sure to fully understand what you are trying to say by "my real issue for the OT", but yes, exclusion of the traffic based on the availability of the OT is detrimental for us.
In short, this is a coverage issue where we lose some traffic and configuration for the evaluation of the API.

Thank you Alois, we're aligned. I completely understand this is an issue for experimentation.
I'm in touch with Chrome Eng and we're discussing options to mitigate this problem.

Summary of the issues with Permissions-Policy

While Permissions-Policy is an important security/trust feature needed in the long run, it creates friction in some cases:

• A permission is not passed down to nested iframes. Some actors in the adtech industry are not aware that the OT is taking place, and don't pass on the permission (or don't set the allow attribute that would enable them to automatically get all of its parent's permissions). This means the API is unavailable in nested cross-origin iframes. Example of developer issue due to that behavior.
• A permission becomes invalid if an iframe performs a redirect (Details). For example, for an iframe configured with allow=attribution-reporting and src=www.a.com, a redirect as seemingly minor as https://a.com → https://www.a.com means the API is unavailable at the final destination. Same for other redirects from a.com to any other origin. Example of developer issue due to that behavior.

This affects measurement reliability. Because Permissions-Policy doesn't come into play in a 3PC measurement system, its presence in Attribution Reporting makes it difficult to compare Attribution based measurement with cookie-based measurement.

EDIT: To clarify, by "real issue for the OT", I meant to explore with you the core reason why this limits your ability to experiment, so I can best communicate the limitations of the Permissions Policy to the wider Chrome team and propose a viable solution. I'm not questioning that this is an issue.

I'll come back to this thread when I hear back!

No concrete updates just yet, but just a heads-up that a proposal to mitigate this issue is currently being evaluated.

Hi @alois-bissuel, one related question:
Are you using feature detection with the API?
If so, in which ways is feature detection helping or not helping you correct your cookie-based vs ARA-based measurement results?

(EDIT: I'm aware feature detection doesn't solve the fact that you're losing volume due to the policy; I'm asking if feature detection would at least help you reliably correct your numbers by offsetting sources/conversions where the API wasn't available due to a missing policy)

Hello @maudnals

Sorry for the very late answer, I was in vacations!

We are using feature detection for a correct usage of the API (when using window.open), but not for correcting the measurement we get from the API. We do this by offline correlation of unique ids which we use for both our standard ads system and the attribution-reporting API.

Noted, thank you.
We'll come back to this thread as soon as we have details to share.

One follow-up question:

• (As discussed, the Permissions-Policy as it is today does reduce traffic, no question about this issue).
• Can you help me understand how/whether it skews results? With feature detection, IMU you'd be only using the API where allowed, and use a debug key to compare only these measurement results with cookie-based ones.

Update: the Permissions-Policy default allowlist has been changed during the testing phase, to mitigate both this issue (#41) and issue #52. No code changes are needed from your side. Find all the details on the change and its timeline in this post.

Thank you for reporting this problem and working with us towards a solution!

Let us know in case you have a question/need troubleshooting on this change, by filing an issue here in this repo as usual.

Thanks a lot for the support!
Closing the issue as the change will solve our problem.

A quick comment to indeed acknowledge that we indeed see much more traffic on our endpoints.
Thanks again!