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

Update permissions policy to match implementation #125

Merged
merged 7 commits into from
Nov 7, 2023
Merged

Update permissions policy to match implementation #125

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
e653d73
permissions changes
blu25 Aug 7, 2023
3386472
Merge branch 'master' into liam-permissions-changes
blu25 Aug 17, 2023
f633cfb
add permissions attribute algorithm
blu25 Aug 21, 2023
44e068f
Merge branch 'master' into liam-permissions-changes
blu25 Sep 27, 2023
de9b454
update comments to explain difference between algorithms
blu25 Sep 27, 2023
6fcc40d
fix formatting
blu25 Sep 28, 2023
f219fa2
address review comments
blu25 Nov 2, 2023
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
104 changes: 77 additions & 27 deletions spec.bs
View file
Open in desktop
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,42 +2659,85 @@ 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>Derive a permissions policy directly from a fenced frame
config instance</dfn>.

Given null or an [=element=] (|container|), this algorithm returns a new [=permissions policy=].

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

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

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

1. 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=].

1. [=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`".

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

1. Return |policy|.

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=]
|fenced| that defaults to false, this algorithm returns a new Permissions Policy.
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|.

2. Set <var ignore>inherited policy</var>[|feature|] to |isInherited|.
1. Set <var ignore>inherited policy</var>[|feature|] to |isInherited|.
</div>

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

Given null, a [=navigable container=]-or-[=fenced navigable container=] (|container|), an
[=origin=] (|origin|), and a [=response=] (<var ignore>response</var>), this algorithm returns a
new [=Document/permissions policy=].
new [=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
[=derive a permissions policy directly from a fenced frame config instance=] 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 +2780,18 @@ 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 [=permissions policy=] that will be [=derive a
permissions policy directly from a fenced frame config instance|created=] when the navigation
constructs the ultimate {{Document}} for this pending navigation. The difference is that this
algorithm, just like when it is called on iframes, will include all of the permissions
specified in the <{fencedframe/allow}> attribute, even if that permission isn't specified in
the [=fenced frame config=]'s [=fenced frame config/effective enabled permissions=]. 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 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,15 +2836,15 @@ 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`".
1. 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`".
1. Otherwise, return "`Disabled`".

Rewrite step 5 to read:

Expand Down