You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the permissions policy comes with important security/anti-fraud benefits (prevent arbitrary third-parties from registering sources without the publisher’s knowledge), it comes with the following limitations for API users:
Limitations
A permissions policy is lost in a chain of nested iframes (See developer issue)
A permissions policy is lost in redirects (See developer issue)
For example, let's take an HTTPS deployed site, that embeds an ad iframe that looks like this:
page-that-redirects redirects to final-destination. So while the API is allowed in page-that-redirects, it's not allowed in final-destination. Repro here in IFRAME 7: https://shimmer-well-juravenator.glitch.me/.
This can also happen in more subtle ways. e.g. redirecting from https://a.com to https://www.a.com.
Mitigations
One way to mitigate 2. is to explicitly list the final destination of the redirect in the policy's src, but I don't know how realistic this is in practice.
The explainer mentions Without a Permissions Policy, a top-level document and cooperating iframe could recreate this functionality. This is possible by using postMessage to send the source_event_id, attributionsrc origin, destination values to the top level document who can then wrap the iframe in an anchor tag (with some additional complexities behind handling clicks on the iframe) but IMU this doesn't solves 1. nor 2, does it?
For 1., even if there was way for an iframe to delegate the permission to all its children, this would seem like a security issue.
The text was updated successfully, but these errors were encountered:
While the permissions policy comes with important security/anti-fraud benefits (prevent arbitrary third-parties from registering sources without the publisher’s knowledge), it comes with the following limitations for API users:
Limitations
For example, let's take an HTTPS deployed site, that embeds an ad iframe that looks like this:
page-that-redirects
redirects tofinal-destination
. So while the API is allowed in page-that-redirects, it's not allowed in final-destination. Repro here in IFRAME 7: https://shimmer-well-juravenator.glitch.me/.This can also happen in more subtle ways. e.g. redirecting from
https://a.com
tohttps://www.a.com
.Mitigations
src
, but I don't know how realistic this is in practice.The text was updated successfully, but these errors were encountered: