Closed shuranhuang closed 1 year ago
That does seem like a bug -- that step should be checking to see if the feature can potentially be delegated to the child frame, or if it is blocked by the policy in the containing document. Either 9.8 needs to return Enabled
in all default cases, or 9.7 should be calling something different in this step.
This algorithm needs to be rewritten to handle #480 as well, so I'll see if I can come up with text that fits that and matches the intended behavior for default-self inheritance.
Thanks for confirming! I think this issue was first introduced in https://github.com/w3c/webappsec-permissions-policy/pull/501. The fix should be easy.
According to the explainer, when no declared policy presents, a powerful features that has default allowlist value "
self
" should be allowed in the top-level document and its same-origin frames, but blocked in cross-origin frames, unlessallow
attribute is used to set this policy and the origin of the document in the frame matches the iframe'ssrc
attribute.However, the following step from the "Define an inherited policy for feature in container at origin" algorithm, https://github.com/w3c/webappsec-permissions-policy/blob/b363be8b113ed980b0449945483920bf1a19bac3/index.bs#L912-L915 which steps into "Is feature enabled in document for origin?" algorithm to the following steps https://github.com/w3c/webappsec-permissions-policy/blob/b363be8b113ed980b0449945483920bf1a19bac3/index.bs#L949-L952 will return "Disabled" for the case mentioned at the beginning, where "Enabled" is expected.
Could this be a bug or I am missing something here?