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.

Sign up for GitHub

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

Jump to bottom

Initializing Feature Policy is racy #4783

Open
dtapuska opened this issue Jul 17, 2019 · 2 comments
Open

Initializing Feature Policy is racy #4783

dtapuska opened this issue Jul 17, 2019 · 2 comments
Labels
integration Better coordination across standards needed topic: frames/navigables/browsing contexts topic: navigation

Comments

@dtapuska
Copy link
Contributor

The initialization of the feature policy occurs after the navigation completes. But while the child is being navigated it is possible the browser context's policy could change and then inheritence could be incorrect from when the navigation occurred.

See #4772 (comment) and in w3c/webappsec-permissions-policy#256
@annevk
Copy link
Member

annevk commented Jul 18, 2019

In particular, we should snapshot all necessary state for all policies at the time "navigate" is invoked. "Navigate" is always invoked from a stable point in time (we're getting rid of all remaining queue a task to navigate cases that are relevant for this afaik) and so it should be doable to get the necessary state from the source browsing context and navigated browsing context (the former should become the source document).

@danyao
Copy link

danyao commented Jul 18, 2019 •
edited
Loading

In particular, we should snapshot all necessary state for all policies at the time "navigate" is invoked.

+1

https://bugs.chromium.org/p/chromium/issues/detail?id=972089#c4 is a concrete failure of this exact bug, where PaymentRequest is enabled in an iframe when it shouldn't be.

clelland added a commit to clelland/html that referenced this issue Nov 18, 2019
@clelland
Snapshot sandbox at start of navigation.
a8cc209 
This change fixes a race condition where an iframe's sandboxing flag set could
be changed in between the start of a navigation and when the response is
returned, and the new document created. In that case, it was unclear how
the new document could reliably synchronously get the updated flags, or
just exactly how late those flags could be changed and still impact the
new document. Now, the sandboxing flag set is routed from the beginning of the
navigation to the eventual document creation.

Ref: whatwg#4783, and also see
w3c/webappsec-permissions-policy#256
@clelland clelland mentioned this issue Nov 18, 2019
Merged
3 tasks
domenic pushed a commit that referenced this issue Nov 25, 2019
@clelland @domenic
Snapshot sandbox at the start of navigation
eb13fec 
This change fixes a race condition where an iframe's sandboxing flag
set could be changed in between the start of a navigation and when the
response is returned, and the new document created. In that case, it
was unclear how the new document could reliably synchronously get the
updated flags, or just exactly how late those flags could be changed
and still impact the new document. Now, the sandboxing flag set is
routed from the beginning of the navigation to the eventual document
creation.

See #4783 and
w3c/webappsec-permissions-policy#256 which
outline similar problems for feature policy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
integration Better coordination across standards needed topic: frames/navigables/browsing contexts topic: navigation
Milestone
No milestone
Development

No branches or pull requests
3 participants
@annevk @dtapuska @danyao