Hi @alois-bissuel

That's puzzling.

Would you be able to paste a screenshot of DevTools origin trial information for the page or pages where you're experiencing this? If you can share a link to the page(s), that would be great, but no worries if you can't.

I'll check about srcdoc.

documentation with all token status

Good idea -- I'll add that to developer.chrome.com/docs/web-platform/origin-trials or developer.chrome.com/docs/web-platform/origin-trial-troubleshooting.

(@maudnals is out-of-office this week.)

Hi @samdutton ,

Here is a screenshot of the specific token issue. Please tell me if you were expecting something else.
I would love to send you a link to the page, but I don't have a "static" way to reproduce the issue (one has to be retargeted by us for our ads to show up, etc). I could send you the source in a hacky copy-paste manner if this is of any help.

Thanks @alois-bissuel — I'll take a look.

Just to confirm: srcdoc is treated as a same origin iframe: as long as the embedding page is secure, it will be as well.

Hi @samdutton
Please tell me if you need any further information (html source, etc)

Hi there @alois-bissuel. I'm am a member of the Origin Trials support team taking a look at this issue, but I would need some minimal test case to reproduce the problem in order to debug further. Would it be possible to provide this?

Hello @DanielRyanSmith .
It is the end of the day for me in France, so I don't have the time today to create a real minimal example, but I believe you can reproduce my issue yourself. It might be tedious as it will be probabilistic (you need to get retargeted by Criteo...)
You can visit a large retailer website (such as one starting by Ma and ending by cy's...), and then go to weather.com.
If you get retargeted by Criteo (all our endpoints have criteo in their name, you can filter them easily), with an ad inside a google ads iFrame (such as as the one highlighted in the image below) with two sandbox.html nested iFrames before our ad, you will land into our issue.

Please tell me if this is sufficient, otherwise I will try to hack a custom reproducible minimal working example. It might be hard for me to do it, as I am not sure of what causes the loss of secure context here (all nested iFrames are sourced from https adresses).

I tried this method for some time with no luck reproducing 😔 I'm not sure what causes the loss of secure context here either. Any definitive way to reproduce this would be of great help. Sorry about this issue, but thank you for your thorough descriptions and assistance in investigation.

Hi @DanielRyanSmith (i'm working with @alois-bissuel on this), Here's an example taken from https://www.lachainemeteo.com/meteo-france/previsions-meteo-france-aujourdhui

The main google ads iframe is deemed "secure"

It wraps another intermediary iframe (not owned by us) which chrome defined as insecure context, even though the url is https://s.hubvisor.io/wrapper/01BYK28ENND8X5G8K0AJ2DPK9E/sandbox.html?pid=ban-atf :

which seems to disable the attribution-reporting feature altogether. Our code, making use of the attribution api, is running in a child iframe, but to no avail since the feature is disabled by inheritance.

The puzzling question is why the context becomes suddenly insecure in the hierarchy ? is is related to the initialization of this intermediary iframe ?

Hi all, it seems we're looking at an overlapping, if not identical issue in #40 filed by @alois-bissuel.
I put together a deployed repro site as well as local repro code and a few observations, see details in #40 (comment).

@DanielRyanSmith and all, feel free to chime in - Thanks!

Thanks a lot for the demo @maudnals! I am seeing what is being described in your comment using your demo. I'm still unsure of the cause unfortunately, but I'll update here if I have any additional info.

Hi @alois-bissuel @fabienbk
I'm trying to reproduce this specific issue, so we can loop in the right folks and get additional Chrome Eng support on this.
I can't see a frame that nests sandbox.html in the Frames panel, any idea / any other place where I could try and reproduce?

@alois-bissuel @fabienbk

Could it be that this frame's src origin is insecure, and redirects to an HTTPS URL?

(In case of redirects, what DevTools displays is the final destination, so if the original src is HTTP we wouldn't see it here
)

Additionally, beyond the secure context aspect:

• A nested iframe wouldn't inherit the policy (see repro: https://shimmer-well-juravenator.glitch.me/ check out IFRAME 8)
• Redirects would cause a loss of the permissions policy too (see Protocol-relative URL and permissions policy #40 (comment)).

Thanks for looking into this @maudnals
I will try to detail the steps needed to reproduce on Monday (at least in France for a specific advertiser / publisher pair, I am not sure if this is easy to redo in the US).

Regarding your last point, I will check the iFrame src origin, but I guess it is a secure one. I will try to see if there are any hints of redirect in the network tab (please enlighten me if there are other place I can check to be sure of this).

Hello @maudnals,

I have looked at the issue again, and I haven't been able to find any definitive proof that a redirect happens or not for the creation of these iFrames. The only hint is that the "topmost" hubvisor iFrame in devtool (Application tab) has a button close to the URL to get the associated network request, and this request has an http code 304. This is a form of redirect to a cached resource if I am not mistaken. I do not know whether this might cause an issue or not, and I have no idea how to reproduce this in a controlled manner.

Closing, as this might be covered in #52.