Limiting the delivery of reports to untrusted third-parties using Feature Policy seems to go against the agreement on the scope of the Feature Policy specification

[ehsan]

I believe https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212 describes the latest agreement between Google and Mozilla on splitting Feature Policy into three separate pieces, where the existing allow attribute would be used for delegating permissions for powerful features.

https://github.com/csharrison/conversion-measurement-api#third-party-reporting refers to using feature policy's delegation of permissions to address restricting delivery of conversion reports to untrusted third-parties, without going into too much detail on how that would be done. But at any rate, since this isn't a powerful feature, this seems to be incompatible with this latest agreement, and as such I believe feature policy isn't a good candidate for addressing this use case.

CCing @annevk from the Mozilla side for visibility.

[michaelkleber]

Interesting -- why would this not qualify as a "powerful feature"? Philosophically, https://github.com/WICG/ad-click-attribution certainly seems to treat it as one. (Apologies for my ignorance if there is a clear characterization here that I don't know about.)

That said, I think any mechanism which gives the 1st party a clear way to delegate this capability to some-but-not-all 3rd-parties would fit the bill here.

[csharrison]

Hey Ehsan, thanks for filing, this may indeed be an issue. It seems like some mechanism for delegating non-user-facing permission to third parties would be a useful addition to the web platform but I agree it doesn't quite fall into the three categories referenced in https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212.

Another use-case for this kind of delegation is in w3c/webappsec-permissions-policy#129, where we want to delegating permission for third parties to use Client Hints.

[csharrison]

cc @clelland FYI

[ehsan]

@michaelkleber I believe w3c/webappsec-permissions-policy#252 gives a good definition of what's considered to be "powerful features" in the context of the feature policy spec (among the other classes of features being discussed wrt that spec.) Based on that definition and my understanding of what the intention is here, it seems like the use case here more or less falls into the "Sandbox features" bucket (but I could be wrong.)

I more filed this as a heads up since it seems like FP isn't the right tool for the job here. I hope Anne and Ian can advise on a more concrete solution (unfortunately I haven't followed all of the relevant discussions to have a very well informed opinion on what the right solution would look like here.)

[clelland]

I think that the issue here is not that whether or not it's a powerful feature, or whether it should follow that model (available top-level, must be delegated to third-party frames) -- I think that both of those could be true.

The issue I think is that, similarly to what we're trying to do with 3p-subresource-client-hints, the allowlist in a single document is not used just to control inheritance in subframes, but to decide whether a given third party is trusted to receive conversion reports.

[ojanvafai]

I believe https://github.com/w3c/webappsec-feature-policy/issues/282 is still an unfinished discussion. I didn't notice the nuance in wording when Anne first posted, but the plan I had heard was to explore splitting up feature policy. It's not quite clear exactly where we'll end up until we have the details worked out.

[csharrison]

I think this is resolved with the move to Permissions Policy, but feel free to re-open if I'm mistaken.