Spec: fix 'src' permissions policy allowlist. #172
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The 'src' allowlist is a feature unique to iframes and fenced frames that, if set, only allows a given feature for the origin loaded in the src/config attribute. When loading a fenced frame with a fenced frame config, that origin is opaque to the embedder but transparent to the inner content. When loading an iframe with a URN that maps to a fenced frame config, it will see the opaque urn in the
src
attribute and assume that is thesrc
that the permissions policy allowlists need to check for, which is wrong. When loading a fenced frame, there is nosrc
attribute, and the existing permissions policy spec has no way to handle theconfig
attribute. This results in thesrc
allowlist being incorrect when calculating the permissions policy for a frame loaded with a fenced frame config.This is fixed by updating the declared origin algorithm to account for cases when a fenced frame config instance is installed in the navigated inner document, setting the expected
src
origin in the allowlists to the config's mapped url.The declared origin algorithm is invoked as part of creating a permissions policy for a navigable from response, which in turn happens when initializing the document. This also happens right after the (monkeypatched in) step where the fenced frame config is installed into the inner document's browsing context, so the required information about the mapped URL will be in place by the time the permissions policy is constructed.
Preview | Diff