Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow feature policy to be used in opaque origins. #10076

Merged
merged 1 commit into from Apr 13, 2018

Conversation

Projects
None yet
5 participants
@chromium-wpt-export-bot
Copy link
Collaborator

chromium-wpt-export-bot commented Mar 16, 2018

Currently, policy-controlled features do not work as expected in
frames with opaque origins, such as isolated sandboxes and data: URLs,
because the eventual opaque origin of the frame is not known when the
HTMLFrameOwnerElement builds the container policy, and so has no way
to tell the browser that a particular origin should be allowed.

This CL adds a new member to the ParsedFeaturePolicyDeclaration, which
indicates that the iframe policy is expected to apply to the origin of
the frame, and is used when that frame has an opaque origin. This can
be triggered with an iframe of the form

<iframe sandbox allow="feature">

or

<iframe sandbox allow="feature src">

This flag is checked when building the feature policy in the new frame,
and ensures that the new feature policy will allow the feature in that
origin.

This is the first part of the eventual solution -- currently this has
the effect of allowing the feature even if a sandboxed frame navigates
to a new page (causing a new opaque origin to be created for it).
Subsequent CLs will add a unique identified to each such origin, and
ensure that the generated policies are properly tied to the specific
origin of the frame.

Bug: 690520
Change-Id: Ie18b9bc3c36be6550baf5a03e355871b9589fd40
Reviewed-on: https://chromium-review.googlesource.com/963382
Reviewed-by: Daniel Cheng dcheng@chromium.org
Reviewed-by: Jeremy Roman jbroman@chromium.org
Reviewed-by: Alex Moshchuk alexmos@chromium.org
Commit-Queue: Ian Clelland iclelland@chromium.org
Cr-Commit-Position: refs/heads/master@{#550463}

@wpt-pr-bot
Copy link
Collaborator

wpt-pr-bot left a comment

Already reviewed downstream.

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-963382 branch 2 times, most recently from 300aec0 to 83a5e12 Mar 16, 2018

@w3c-bots

This comment has been minimized.

Copy link

w3c-bots commented Mar 16, 2018

Build ERRORED

Started: 2018-03-26 14:10:08
Finished: 2018-03-26 14:59:38

Failing Jobs

  • firefox:nightly

View more information about this build on:

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-963382 branch from 83a5e12 to e90eb64 Mar 16, 2018

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-963382 branch 2 times, most recently from 5ef7ad0 to cd4be02 Mar 25, 2018

@chromium-wpt-export-bot chromium-wpt-export-bot changed the title Fix feature policy in isolated sandboxes. Allow feature policy to be used in opaque origins. Apr 10, 2018

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-963382 branch 5 times, most recently from d37264c to 8c8a259 Apr 10, 2018

Allow feature policy to be used in opaque origins.
Currently, policy-controlled features do not work as expected in
frames with opaque origins, such as isolated sandboxes and data: URLs,
because the eventual opaque origin of the frame is not known when the
HTMLFrameOwnerElement builds the container policy, and so has no way
to tell the browser that a particular origin should be allowed.

This CL adds a new member to the ParsedFeaturePolicyDeclaration, which
indicates that the iframe policy is expected to apply to the origin of
the frame, and is used when that frame has an opaque origin. This can
be triggered with an iframe of the form

<iframe sandbox allow="feature">

or

<iframe sandbox allow="feature src">

This flag is checked when building the feature policy in the new frame,
and ensures that the new feature policy will allow the feature in that
origin.

This is the first part of the eventual solution -- currently this has
the effect of allowing the feature even if a sandboxed frame navigates
to a new page (causing a new opaque origin to be created for it).
Subsequent CLs will add a unique identified to each such origin, and
ensure that the generated policies are properly tied to the specific
origin of the frame.

Bug: 690520
Change-Id: Ie18b9bc3c36be6550baf5a03e355871b9589fd40
Reviewed-on: https://chromium-review.googlesource.com/963382
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550463}
@foolip

This comment has been minimized.

Copy link
Contributor

foolip commented Apr 13, 2018

#7660 strikes again. The Chrome job was just fast enough to pass, 41 minutes.

@foolip foolip merged commit 4c8580c into master Apr 13, 2018

1 check failed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details

@foolip foolip deleted the chromium-export-cl-963382 branch Apr 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.