Permission policy system after the OT

[alois-bissuel]

Hello,

During the OT, the permission policy system has been lifted for easier testing (#551, see our related ask in #519 and in the ps-dev-support).
I am now wondering about the end state of the API if it graduates after the OT.

If the permission policy system is to be kept as is (ie the standard delegation system), there is a high probability that some of our inventory won't have access to the API. Ads may be rendered in nested iFrames dropped by transient actors (eg for AB-testing or other purposes), who may not delegate the permission.

Do you see any solution to this kind of issue?

P.S. Linking #393 as it already lists various arguments for the default permission policy.

[csharrison]

Thanks @alois-bissuel for filing. I chatted with @clelland about this briefly in TPAC because it seems like a legitimate concern. Let me summarize how I am thinking about this:

1. We want some level of opt-in for the APIs in third party contexts, to ensure that sites have control over who can measure their user's cross site activity. This is also important for things like rate limits where we don't want evil iframes consuming any kind of "budget".
2. The kind of opt-in that Permissions Policy asks for is very heavyweight, because it requires a whole tree of frames to opt-in to their children having the permission.
3. In the real world, it is common for transient frames to pop in and out of existence in the course of ads serving, and it is a large coordination problem to ensure that the whole tree is decorated correctly with the right permissions. One badly configured / buggy frame will cause the API to be disabled.

After thinking about it for a bit I thought of a potential middle ground policy we might want to consider: a way for frames to set a policy on a child and allow it to recursively propagate:

<iframe src="..." allow-recursive="attribution-reporting"></iframe>

Concretely, the recursively allowed features would be inherited by a subframe, and also propagated to that subframe’s children (and so on). Possibly, it could also be applied to documents the frame navigates to e.g. in redirects?

The biggest challenge with a relaxed permission like this is that it could be surprising to a frame not expecting a recursive permission to be applied (e.g. one that embeds untrusted content). To prevent security issues from silently propagating permissions, we would need to ensure that frames understand what is happening and what their recursive policy is, e.g. via HTTP headers or JS accessors. They should similarly be able to revoke the recursive policy with those same mechanisms (response headers, JS API).

Anyway, I’m still not sure how I feel about a proposal like this but I’d be curious to understand if it would solve the issues you mentioned, @alois-bissuel. My thinking is that this is strictly better than a default of * because:
a. Default * requires all publishers and frames to opt-out if they don't want children using the API
b. Default self with allow-recursive mechanism requires all embedded frames to opt-out if they don't want children using the API.

(b) is a strict subset of (a), so we'd be reducing the number of parties needing to explicitly opt-out.

cc @maudnals

[alois-bissuel]

Thanks for the detailed answer.
It looks like it would indeed solve our use case, depending on the default permission being discussed in #393.

[zhengweiwithoutthei]

with (a) I am not sure if it is true that default * requires all frames to opt-out if they don't want children to use the API. My understanding is the opt-out with header is recursive in nature. For example, if a publisher opt-out with header Permissions-Policy: attribution-reporting=(), the API is disabled on the publisher's document as well as any child frame.

(b) self + "allow-recursive" basically turn any nested frames into the case of (a). It does provide some flexibility for publisher to opt-in itself and the frames they truest but disable the API on the others.

[jfggit]

I just want to chime in here to echo the concern with the existing permissions policy behavior. As mentioned, there can be an entire chain of iframe ancestors owned by parties who may be 1) unknown, 2) ephemeral, 3) unwilling or uninterested in propagating permissions downstream, against the preferences of the top-level site owner.

Although in reading these permissions-policy docs, it reads like even if the default policy is attribution-reporting=*, we would still need allow="attribution-reporting" on every iframe in order to actually propagate that permission. Is that accurate to the current state of the OT? Similarly, if post-OT, a publisher were to mark their top-level page with Permissions-Policy: attribution-reporting=*, would that setting also be limited by a lack of allow attributions on containing iframes?

Or, for a more targeted example, if publisher.com explicitly wants to allow a particular buyer (partneradtech.com) to measure on its domain, even when intermediary sellers are involved, there's no way to do that. If publisher.com returns headers Permissions-Policy: attribution-reporting=(partneradtech.com), partneradtech.com iframes would still only have permission if running as a direct child of the top page. Otherwise any intermediary iframes without allow attributes on them would block this permission propagation. Is that correct?

[csharrison]

with (a) I am not sure if it is true that default * requires all frames to opt-out if they don't want children to use the API. My understanding is the opt-out with header is recursive in nature. For example, if a publisher opt-out with header Permissions-Policy: attribution-reporting=(), the API is disabled on the publisher's document as well as any child frame.

The scenario where the publisher has no policy and the embedded frame does not want to propagate permission, the allow-recursive solution does not require the frame to act (as it does not have permission), whereas the default * does require the frame to act.

(b) self + "allow-recursive" basically turn any nested frames into the case of (a). It does provide some flexibility for publisher to opt-in itself and the frames they truest but disable the API on the others.

Yeah I agree with that, it's a good framing.

Although in reading these permissions-policy docs, it reads like even if the default policy is attribution-reporting=, we would still need allow="attribution-reporting" on every iframe in order to actually propagate that permission. Is that accurate to the current state of the OT? Similarly, if post-OT, a publisher were to mark their top-level page with Permissions-Policy: attribution-reporting=, would that setting also be limited by a lack of allow attributions on containing iframes?

This is not the behavior of the current OT, as a default value of * will allow children to use the API without allow. You can see the permissions policy spec for details (9.9.4):
https://www.w3.org/TR/permissions-policy-1/#algo-is-feature-enabled

That being said, your understanding is correct if the default is moved to "self". In that case, even the publisher declaring * does not automatically allow all iframes to use the API. I think that spec link also confirms this.

Or, for a more targeted example, if publisher.com explicitly wants to allow a particular buyer (partneradtech.com) to measure on its domain, even when intermediary sellers are involved, there's no way to do that. If publisher.com returns headers Permissions-Policy: attribution-reporting=(partneradtech.com), partneradtech.com iframes would still only have permission if running as a direct child of the top page. Otherwise any intermediary iframes without allow attributes on them would block this permission propagation. Is that correct?

That's correct if the default is moved to "self".

[jfggit]

Ah, so I think the part that I missed here is that there is a difference between a default value of *, and an explicitly set value of * from the top level page. The "* as default" scenario means allow-based propagation is unnecessary, whereas any other default value means allow-propagation is required and the Permissions-Policy header only serves as a mechanism to additionally restrict permission, not to grant it.

[csharrison]

@jfggit yes that's my understanding (I agree it is kind of confusing). My guess is that most of the docs you read were implicitly assuming a default value of "self", since * is fairly rare. cc @clelland

[jfggit]

Good to know and it would be great to get confirmation, as I was definitely confused here.

Ok, so then with this understanding, I think if "self" ends up as the default, allow-recursive would be potentially helpful, but probably not addressing a good chunk missing coverage. In the simplest and probably most common case, one or more of the "main" ad techs used by the publisher for filling ad space doesn't know or doesn't care about attribution reporting. As the top-most frame in any iframe chain for loading ads, if they don't set allow, it's not going to matter what anyone downstream does. From what analysis we've done, I think this is a significant fraction of our overall traffic.

[csharrison]

@jfggit I understand it is a large migration from the status-quo to use allow-recursive, but in the steady state I think most SSPs will be familiar with the API and will want to enable it. Or at least, that's my hope.

That being said, I agree that it isn't a perfect solve that gives as much coverage as our existing default *.

[zhengweiwithoutthei]

The scenario where the publisher has no policy and the embedded frame does not want to propagate permission, the allow-recursive solution does not require the frame to act (as it does not have permission), whereas the default * does require the frame to act.

I am not sure this is correct. I believe, with default as '*', permissions-policy: attribution-reporting=() is sufficient to disable the feature for all nested frames. I made an example at https://attribution-permission-policy.glitch.me/?disable

By removing '?disable' you can see all nested frames has the feature enabled without 'allow' attribute which indicates the defualt '*' is in use.

Appending the '?disable' introduces the permissions-policy: attribution-reporting=() header in the response to the top document, and it effectively disables the feature in all nested frames without the frame to act individually.

[csharrison]

I am not sure this is correct. I believe, with default as '*', permissions-policy: attribution-reporting=() is sufficient to disable the feature for all nested frames. I made an example at https://attribution-permission-policy.glitch.me/?disable

Yes that's true. I would consider that a case where the publisher has a policy though, right? I was describing a case where the pub does nothing.

[jfggit]

There's a kind of use-case gap with the allow-recursive solution which is somewhat unfortunate. I think we kind of hashed this out above, but to make it explicit: We have publisher, SSP, and DSP, where the publisher loads the SSP's code into their top level, the SSP creates an iframe to fetch ads, and the DSP executes within that frame. The SSP, as the creator of the iframe, has the ability to use allow-recursive to enable the feature to any children frames. However, the publisher does not have a way to do the same. Clearly they have the "permission" to, but from a technical standpoint there's no mechanism for them to specify that (other than maybe to make their own iframe to contain the SSP).

[csharrison]

@jfggit that's true. I wonder @clelland if permissions policy ever considered making the top level headers "automatically" set the allow bits on iframes from an ergonomics POV?