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

Update permissions policy to match implementation #125

Merged
merged 7 commits into from
Nov 7, 2023
Merged
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 72 additions & 23 deletions spec.bs
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ WPT Display: open
</pre>

<pre class="link-defaults">
spec:dom; type:dfn; for:/; text:element
spec: url; for:/; type: dfn; text: url
</pre>
<pre class="biblio">
Expand Down Expand Up @@ -222,9 +223,12 @@ spec: permissions-policy; urlPrefix: https://w3c.github.io/webappsec-permissions
text: ASCII-serialized policy directive; url: serialized-policy-directive
text: serialized permissions policy; url: serialized-permissions-policy
text: supported features; url: supported-features
text: declared policy; url: declared-policy
text: the special value *; url: the-special-value
text: permissions policy; url: permissions-policy
text: policy directive; url: policy-directive
for: permissions policy
text: declared policy; url: permissions-policy-declared-policy
text: inherited policy; url: permissions-policy-inherited-policy
for: permissions
text: matches; url: matches
spec: CSP; urlPrefix: https://w3c.github.io/webappsec-csp/
Expand All @@ -237,10 +241,6 @@ spec: CSPEE; urlPrefix: https://w3c.github.io/webappsec-cspee/
type: dfn
text: Is response to request blocked by context's required CSP?; url: process-response
text: required csp; url: browsing-context-required-csp
spec: permissions-policy; urlPrefix: https://w3c.github.io/webappsec-permissions-policy
type: dfn
for: permissions policy
text: inherited policy; url: inherited-policy
spec: css2; urlPrefix: https://www.w3.org/TR/CSS21/visuren.html
type: dfn
for: css2
Expand Down Expand Up @@ -2659,20 +2659,59 @@ algorithms to achieve the outcomes described in the above explanatory content.
or <{fencedframe}>'s [=container policy=], when it is constructed.
</div>

<div algorithm>
Create a new algorithm, called <dfn export>Create a Permissions Policy for a fenced
blu25 marked this conversation as resolved.
Show resolved Hide resolved
navigable</dfn>.

Given null or an [=element=] (|container|), this algorithm returns a new Permissions Policy.
blu25 marked this conversation as resolved.
Show resolved Hide resolved

1. [=Assert=]: if not null, |container| is a [=fenced navigable container=].
blu25 marked this conversation as resolved.
Show resolved Hide resolved

2. Let |inherited policy| be a new [=ordered map=].

3. Let |effective permissions| be an empty [=list=].

4. Let |fenced frame config| be |container|'s [=Node/node document=]'s [=navigable/active browsing
context=]'s [=browsing context/fenced frame config instance=].

5. If |fenced frame config| is not null, and |fenced frame config|'s [=fenced frame config/
effective enabled permissions=] are not null, set |effective permissions| to
|fenced frame config|'s [=fenced frame config/effective enabled permissions=].

6. [=list/For each=] |feature| [=supported features|supported=]:

1. If |effective permissions| [=list/contains=] |feature|, then set |inherited policy|[feature]
to "`Enabled`".

Otherwise, set |inherited policy|[feature] to "`Disabled`".

7. Let |policy| be a new [=permissions policy=], with [=permissions policy/inherited policy=]
|inherited policy| and [=permissions policy/declared policy=] a new [=ordered map=].

8. Return |policy|.
blu25 marked this conversation as resolved.
Show resolved Hide resolved

Note: While this algorithm doesn't take the <{fencedframe/allow}> attribute into consideration, it
will have already been checked by the time this is called because of [=Should navigation response
to navigation request be blocked by Permissions Policy?=]. Any policy specified in
<{fencedframe/allow}> that is too restrictive would have cause the fenced frame to not load, and
any policy that is more permissive than what is specified in the [=fenced frame config/effective
enabled permissions=] will be ignored.
</div>

<div algorithm=create-permissions-policy>
Modify the [$Create a Permissions Policy for a navigable$] algorithm:

Given null or an element (|container|), an [=origin=] (|origin|), and an optional [=boolean=]
Given null or an [=element=] (|container|), an [=origin=] (|origin|), and an optional [=boolean=]
|fenced| that defaults to false, this algorithm returns a new Permissions Policy.

Rewrite step 1 to read:

1. [=Assert=]: if not null, <var ignore>container</var> is either a [=navigable container=] or a
1. [=Assert=]: if not null, |container| is either a [=navigable container=] or a
[=fenced navigable container=].

Rewrite step 3 to read:

4. For each |feature| [=supported features|supported=]:
4. [=list/For each=] |feature| [=supported features|supported=]:

1. Let |isInherited| be the result of running [$Define an inherited policy for feature in
container at origin$] on |feature|, |container|, |origin|, and |fenced|.
Expand All @@ -2687,14 +2726,20 @@ algorithms to achieve the outcomes described in the above explanatory content.
[=origin=] (|origin|), and a [=response=] (<var ignore>response</var>), this algorithm returns a
new [=Document/permissions policy=].

Add a step before step 1 that reads:
Rewrite step 1 to read:

1. Let |fenced| be true if |container| is a [=fenced navigable container=], and false otherwise.
1. If |container| is a [=fenced navigable container=], then let |policy| be the result of running
[=Create a Permissions Policy for a fenced navigable=] given |container|.

Otherwise, Let |policy| be the result of running [$Create a Permissions Policy for a
navigable$] given |container| and |origin|.
</div>

Modify what is *now* step 2 of the algorithm to read:
<div algorithm=process-permissions-policy-attribute-patch>
Modify step 1 of the [$Process permissions policy attributes$] algorithm to read:

2. Let <var ignore>policy</var> be the result of running [$Create a Permissions Policy
for a navigable$] given |container|, |origin|, and |fenced|.
1. If <var ignore>element</var> is not an <{iframe}> element or a <{fencedframe}> element, then
return an empty [=policy directive=].
</div>

<div algorithm=attempt-populate-history-patches>
Expand Down Expand Up @@ -2737,11 +2782,15 @@ algorithms to achieve the outcomes described in the above explanatory content.
creating a permissions policy$] given |navigable|'s [=fenced navigable container=], |origin|,
and <var ignore>fenced</var> set to true.

Note: This is identical to the [=Document/permissions policy=] that will be created when the
navigation constructs the ultimate {{Document}} for this pending navigation. We create it now
and run tests on it since this is the appropriate time to determine if a navigation will fail,
and then throw it away. If the navigation succeeds, it will be recreated identically and
unconditionally installed on the {{Document}}.
Note: This is almost identical to the [=Document/permissions policy=] that will be created when
blu25 marked this conversation as resolved.
Show resolved Hide resolved
blu25 marked this conversation as resolved.
Show resolved Hide resolved
the navigation constructs the ultimate {{Document}} for this pending navigation (with the
[=Create a Permissions Policy for a fenced navigable=] algorithm). We create it now and run
tests on it since this is the appropriate time to determine if a navigation will fail, and then
throw it away. If the navigation succeeds, it will be recreated and unconditionally installed
blu25 marked this conversation as resolved.
Show resolved Hide resolved
on the {{Document}}. However, the recreation will not include any additional enabled
permissions that are not included in the [=fenced frame config/effective enabled permissions=],
effectively locking the enabled permissions to only what is specified in [=fenced frame
config/effective enabled permissions=].

1. Let |inherited policy| be |permissions policy|'s [=permissions policy/inherited policy=].

Expand Down Expand Up @@ -2786,13 +2835,13 @@ algorithms to achieve the outcomes described in the above explanatory content.

Rewrite step 3 to read:

3. If |feature| is present in |policy|'s [=declared policy=],
3. If |feature| is present in |policy|'s [=permissions policy/declared policy=],

1. If |fenced| is false, and the [=allowlist=] for |feature| in |policy|'s [=declared policy=]
[=permissions/matches=] |origin|, then return "`Enabled`".
1. If |fenced| is false, and the [=allowlist=] for |feature| in |policy|'s [=permissions policy/
declared policy=] [=permissions/matches=] |origin|, then return "`Enabled`".

2. Otherwise, if |fenced| is true, and the [=allowlist=] for |feature| in |policy|'s [=declared
policy=] is [=the special value *=], then return "`Enabled`".
2. Otherwise, if |fenced| is true, and the [=allowlist=] for |feature| in |policy|'s
[=permissions policy/declared policy=] is [=the special value *=], then return "`Enabled`".

3. Otherwise, return "`Disabled`".

Expand Down