question about permissions policy without "self"

[Fergal Daly]

Hi Ian,

with PP:unload, we want sites to be able to say "disable unload for myself and everything else except legacy-unload-user.com but it's looking like this isn't possible.

From testing and reading around, it seems that a header like

Permissions-Policy: unload=("http://legacy-unload-user.com/")

does not do anything (unless the main frame is legacy-unload-user.com). Without a `self` in there, nothing will be allowed due to inheritance.

However, this doc

https://developer.chrome.com/en/docs/privacy-sandbox/permissions-policy/

has an example without `self` (search for "Policy applied to the specified origins") and claims it will work but requires `allow` to be set on the iframe.

That does not seem to work in my testing and it seems like this test is testing that it doesn't work. This test is a bit confusing because the wording is "test fullscreen is allowed on specific cross-origin subframe" but actually test_disallowed_feature_for_subframe asserts that it is disallowed but maybe I'm misreading the test.

Can you clarify what's expected?

F

[Ian Clelland]

On Tue, Jul 12, 2022 at 9:15 AM Fergal Daly <fer...@google.com> wrote:

Hi Ian,

with PP:unload, we want sites to be able to say "disable unload for myself and everything else except legacy-unload-user.com but it's looking like this isn't possible.

From testing and reading around, it seems that a header like

Permissions-Policy: unload=("http://legacy-unload-user.com/")

does not do anything (unless the main frame is legacy-unload-user.com). Without a `self` in there, nothing will be allowed due to inheritance.

It's not that it doesn't do *anything* -- it will in fact block unload completely. Without 'self' present, the document accompanying that header will not be allowed to use the 'unload', and neither will any other documents it embeds.

 

However, this doc

https://developer.chrome.com/en/docs/privacy-sandbox/permissions-policy/

has an example without `self` (search for "Policy applied to the specified origins") and claims it will work but requires `allow` to be set on the iframe.

I proofread that doc (or a previous version of it) and missed that -- every other example includes 'self' or * properly.

What it shows is technically valid syntax, which might be the point of that section. And if the document's origin actually was either https://a.example or https://b.example, then this would work as expected. You can use the actual origin explicitly instead of 'self'; 'self' is just convenient shorthand.

That does not seem to work in my testing and it seems like this test is testing that it doesn't work. This test is a bit confusing because the wording is "test fullscreen is allowed on specific cross-origin subframe" but actually test_disallowed_feature_for_subframe asserts that it is disallowed but maybe I'm misreading the test.

You're right that it shouldn't work in general -- you need to have either 'self', *, or the document's origin listed explicitly. We should at least add a note to the doc there to explain that. 

(And I also agree that the comments in that test are misleading; they may have been carelessly copied from another existing test, but they should be updated. If the document 'declines' the feature by not excluding its own origin from the header, then all usage should be denied.

Ian

[Fergal Daly]

Thanks.

In the case of a feature that we're trying to revoke (unload, sync-xhr, document-domain), the incremental removal story is less clear if you cannot say "deny for all except". PP:unload is still very useful without it but it would be better if we could do that.

Is there any reason not to propose adding a mode where this works? We would be separating the ability to use the feature from the ability to set policy. So for example (straw person) we allow a ! in front of entries so that it's explicit

- main frame sets unload=( !self "ads.com") and the top-level origin cannot use the feature

  - ads.com frame can use the feature. Also any subframes of ads,c/om frame can use it by default but this frame's header could set a policy that denies them

One more reply below...

On Tue, 12 Jul 2022 at 23:33, Ian Clelland <icle...@google.com> wrote:

On Tue, Jul 12, 2022 at 9:15 AM Fergal Daly <fer...@google.com> wrote:

Hi Ian,

with PP:unload, we want sites to be able to say "disable unload for myself and everything else except legacy-unload-user.com but it's looking like this isn't possible.

From testing and reading around, it seems that a header like

Permissions-Policy: unload=("http://legacy-unload-user.com/")

does not do anything (unless the main frame is legacy-unload-user.com). Without a `self` in there, nothing will be allowed due to inheritance.

It's not that it doesn't do *anything* -- it will in fact block unload completely. Without 'self' present, the document accompanying that header will not be allowed to use the 'unload', and neither will any other documents it embeds.

 

However, this doc

https://developer.chrome.com/en/docs/privacy-sandbox/permissions-policy/

has an example without `self` (search for "Policy applied to the specified origins") and claims it will work but requires `allow` to be set on the iframe.

I proofread that doc (or a previous version of it) and missed that -- every other example includes 'self' or * properly.

What it shows is technically valid syntax, which might be the point of that section. And if the document's origin actually was either https://a.example or https://b.example, then this would work as expected. You can use the actual origin explicitly instead of 'self'; 'self' is just convenient shorthand.

I don't think it's just that. It says in that section

"In addition to adding the origin to the origin list in the header, the iframe with that origin must set the allow attribute in the tag. The origin list header provides a list of valid origins for the allow attribute to consume."

At the very least, that paragraph belongs somewhere else,

F

[Ian Clelland]

On Wed, Jul 13, 2022 at 4:45 AM Fergal Daly <fer...@google.com> wrote:

Thanks.

In the case of a feature that we're trying to revoke (unload, sync-xhr, document-domain), the incremental removal story is less clear if you cannot say "deny for all except". PP:unload is still very useful without it but it would be better if we could do that.

Is there any reason not to propose adding a mode where this works? We would be separating the ability to use the feature from the ability to set policy. So for example (straw person) we allow a ! in front of entries so that it's explicit

- main frame sets unload=( !self "ads.com") and the top-level origin cannot use the feature

  - ads.com frame can use the feature. Also any subframes of ads,c/om frame can use it by default but this frame's header could set a policy that denies them

We thought about this, and if I recall, we couldn't come up with a case where the distinction between being able to use the feature yourself and being able to delegate it was more than cosmetic, from a security perspective. If you can create a frame which does have access, then it could easily send the data back to you, or could even create a new frame at your origin with access to the feature. It seemed like there's not a meaningful difference in terms of security between "can delegate the permission to an origin I choose" and "can use the feature myself".

At the time, the model for Feature Policy was slightly different, and that may have been a factor in that calculation: Before permissions policy, it was possible to use an allow attribute on *any* iframe to delegate a feature to that frame, regardless of the header -- essentially, if the header *or* the element allowed it, the feature would be delegated. The only way to block that from happening was to not grant the current page access to the feature at all.

(This also has the nice property that if you look at the whole frame tree, you can say that if any frame has a feature blocked, then *all* of its descendants have the feature blocked as well. There aren't any cases where a feature is blocked in one frame and not blocked in one of its children. Maybe that's more aesthetic than practical, but it is at least easy to explain.)

Since we moved to the permissions policy model, where we require the header *AND* the element to both grant access (with the header defaulting to "*" and the element generally defaulting to "self") maybe we could revisit that. We'd need to do some deep compat analysis, to make sure that we're not opening up security holes in pages which are depending on the current behaviour.

[Fergal Daly]

On Fri, 15 Jul 2022 at 03:04, Ian Clelland <icle...@google.com> wrote:

On Wed, Jul 13, 2022 at 4:45 AM Fergal Daly <fer...@google.com> wrote:

Thanks.

In the case of a feature that we're trying to revoke (unload, sync-xhr, document-domain), the incremental removal story is less clear if you cannot say "deny for all except". PP:unload is still very useful without it but it would be better if we could do that.

Is there any reason not to propose adding a mode where this works? We would be separating the ability to use the feature from the ability to set policy. So for example (straw person) we allow a ! in front of entries so that it's explicit

- main frame sets unload=( !self "ads.com") and the top-level origin cannot use the feature

  - ads.com frame can use the feature. Also any subframes of ads,c/om frame can use it by default but this frame's header could set a policy that denies them

We thought about this, and if I recall, we couldn't come up with a case where the distinction between being able to use the feature yourself and being able to delegate it was more than cosmetic, from a security perspective. If you can create a frame which does have access, then it could easily send the data back to you, or could even create a new frame at your origin with access to the feature. It seemed like there's not a meaningful difference in terms of security between "can delegate the permission to an origin I choose" and "can use the feature myself".

For deprecation/self-restraint I guess we don't need it to be water-tight.

At the time, the model for Feature Policy was slightly different, and that may have been a factor in that calculation: Before permissions policy, it was possible to use an allow attribute on *any* iframe to delegate a feature to that frame, regardless of the header -- essentially, if the header *or* the element allowed it, the feature would be delegated. The only way to block that from happening was to not grant the current page access to the feature at all.

(This also has the nice property that if you look at the whole frame tree, you can say that if any frame has a feature blocked, then *all* of its descendants have the feature blocked as well. There aren't any cases where a feature is blocked in one frame and not blocked in one of its children. Maybe that's more aesthetic than practical, but it is at least easy to explain.)

Since we moved to the permissions policy model, where we require the header *AND* the element to both grant access (with the header defaulting to "*" and the element generally defaulting to "self") maybe we could revisit that. We'd need to do some deep compat analysis, to make sure that we're not opening up security holes in pages which are depending on the current behaviour.

Changing the current meaning seems like a minefield but doesn't inflate the spec. Adding an explicit syntax like "!self" ensures we don't break existing pages but will lead to a more complex spec.

Adding an explicit syntax seems less likely to blow up and get people shouting at us.

PP: Unload is still useful without either, so it's not urgent. Maybe a github issue is that right starting point?

F

[Ian Clelland]

On Thu, Jul 14, 2022 at 11:11 PM Fergal Daly <fer...@google.com> wrote:

On Fri, 15 Jul 2022 at 03:04, Ian Clelland <icle...@google.com> wrote:

On Wed, Jul 13, 2022 at 4:45 AM Fergal Daly <fer...@google.com> wrote:

Thanks.

In the case of a feature that we're trying to revoke (unload, sync-xhr, document-domain), the incremental removal story is less clear if you cannot say "deny for all except". PP:unload is still very useful without it but it would be better if we could do that.

Is there any reason not to propose adding a mode where this works? We would be separating the ability to use the feature from the ability to set policy. So for example (straw person) we allow a ! in front of entries so that it's explicit

- main frame sets unload=( !self "ads.com") and the top-level origin cannot use the feature

  - ads.com frame can use the feature. Also any subframes of ads,c/om frame can use it by default but this frame's header could set a policy that denies them

We thought about this, and if I recall, we couldn't come up with a case where the distinction between being able to use the feature yourself and being able to delegate it was more than cosmetic, from a security perspective. If you can create a frame which does have access, then it could easily send the data back to you, or could even create a new frame at your origin with access to the feature. It seemed like there's not a meaningful difference in terms of security between "can delegate the permission to an origin I choose" and "can use the feature myself".

For deprecation/self-restraint I guess we don't need it to be water-tight.

At the time, the model for Feature Policy was slightly different, and that may have been a factor in that calculation: Before permissions policy, it was possible to use an allow attribute on *any* iframe to delegate a feature to that frame, regardless of the header -- essentially, if the header *or* the element allowed it, the feature would be delegated. The only way to block that from happening was to not grant the current page access to the feature at all.

Thinking more after I sent the message yesterday, I believe that this was the biggest reason -- with the original model, it was trivial to work around not having access yourself. Even with a header like "Feature-Policy: some-feature 'none'", if we made it possible to delegate without having access yourself, then you could just create a frame to anywhere, even your own origin, with an allow attribute that would re-enable the feature. The way we closed that hole that was to be strict about not allowing delegation when you don't have access yourself.

 

(This also has the nice property that if you look at the whole frame tree, you can say that if any frame has a feature blocked, then *all* of its descendants have the feature blocked as well. There aren't any cases where a feature is blocked in one frame and not blocked in one of its children. Maybe that's more aesthetic than practical, but it is at least easy to explain.)

Since we moved to the permissions policy model, where we require the header *AND* the element to both grant access (with the header defaulting to "*" and the element generally defaulting to "self") maybe we could revisit that. We'd need to do some deep compat analysis, to make sure that we're not opening up security holes in pages which are depending on the current behaviour.

Changing the current meaning seems like a minefield but doesn't inflate the spec. Adding an explicit syntax like "!self" ensures we don't break existing pages but will lead to a more complex spec.

Adding an explicit syntax seems less likely to blow up and get people shouting at us.

PP: Unload is still useful without either, so it's not urgent. Maybe a github issue is that right starting point?

That's probably a good place to start. There'd almost certainly be bikeshedding on the actual syntax.

[Fergal Daly]

Thanks, I posted https://github.com/w3c/webappsec-permissions-policy/issues/480,

F