Change FP inheritance by clelland · Pull Request #378 · w3c/webappsec-permissions-policy (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation0 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

clelland

This modifies the calculation of the inherited policy to allow the Feature-Policy header to completely block origins from being able to use features, even when the iframe's container policy is used to delegate them.

The unused 'none' default allowlist is removed, as the new algorithms would not allow it to ever work, and examples which no longer apply after this change are either removed or updated.

Closes: #357

@clelland

@clelland clelland deleted the change-fp-inheritance branch

May 26, 2020 13:16

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 9, 2020

@clelland @chromium-wpt-export-bot

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 10, 2020

@clelland @chromium-wpt-export-bot

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 11, 2020

@clelland @chromium-wpt-export-bot

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 11, 2020

@clelland @chromium-wpt-export-bot

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2363169 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request

Nov 11, 2020

@clelland @chromium-wpt-export-bot

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2363169 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408}

pull bot pushed a commit to Mu-L/chromium that referenced this pull request

Nov 12, 2020

@clelland

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2363169 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408}

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request

Nov 13, 2020

@clelland @moz-wptsync-bot

…a=testonly

Automatic update from web-platform-tests Change Feature-Policy header semantics

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2363169 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408}

--

wpt-commits: 19f0e5b428566278daf7902c469a540cf1353ea5 wpt-pr: 26459

aosmond pushed a commit to aosmond/gecko that referenced this pull request

Nov 15, 2020

@clelland @moz-wptsync-bot

…a=testonly

Automatic update from web-platform-tests Change Feature-Policy header semantics

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2363169 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408}

--

wpt-commits: 19f0e5b428566278daf7902c469a540cf1353ea5 wpt-pr: 26459

qtprojectorg pushed a commit to qt/qtwebengine-chromium that referenced this pull request

Feb 16, 2021

@clelland @mibrunin

Partial cherry-pick (skipping tests) of patch originally reviewed on https://chromium-review.googlesource.com/c/chromium/src/+/2363169: Change Feature-Policy header semantics

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408} Reviewed-by: Allan Sandfeld Jensen allan.jensen@qt.io

bhearsum pushed a commit to mozilla-releng/staging-firefox that referenced this pull request

May 1, 2025

@clelland @moz-wptsync-bot

…a=testonly

Automatic update from web-platform-tests Change Feature-Policy header semantics

This change implements the algorithmic changes for a recent change to the Feature/Permissions policy spec: w3c/webappsec-permissions-policy#378

With this change, the Feature-Policy or Permissions-Policy headers by themselves cannot be used to delegate powerful features to cross-origin iframes; the allow attribute must be used as well. To allow this to still be ergonomic, the default value for the header for powerful features is effectively '*', so that delegation is allowed by the header implicitly. The header can now be used effectively to completely block access to a feature, as any origins not present in the header allowlist cannot be granted the feature through the allow attribute.

This also removes some code which previously only existed to track the cases where this change would affect the output of an IsFeatureEnabled call.

Several tests will have been modified or rewritten prior to landing this change; this CL depends on the following (though they are all independent, so they are not chained together):

This CL, while large, can best be understood as the union of the following changes:

Bug: 1095641, 937131 Change-Id: Iecbb0950c27a4565998ee5192590d6691a03b4a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2363169 Reviewed-by: Yoav Weiss yoavweiss@chromium.org Reviewed-by: Charlie Hu chenleihu@google.com Reviewed-by: Ken Buchanan kenrb@chromium.org Commit-Queue: Ian Clelland iclelland@chromium.org Cr-Commit-Position: refs/heads/master@{#826408}

--

wpt-commits: 19f0e5b428566278daf7902c469a540cf1353ea5 wpt-pr: 26459

1 participant

@clelland