1844431 - [wpt-sync] Sync PR 41111 - Allow non-opaque fenced frames to inherit permissions.

Status: RESOLVED INVALID

(Testing :: web-platform-tests, task, P4)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Sync web-platform-tests PR 41111 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/41111
Details from upstream follow.

Liam Brady <[e-mail]> wrote:

Allow non-opaque fenced frames to inherit permissions.

Permissions policy inheritance was historically disabled in fenced
frames. This was done in order to prevent cross-site data from flowing
across a fenced frame boundary into a fenced frame, which would've
allowed the fenced frame to learn about its embedder's permissions
policies and use that to fingerprint what site it's embedded in. The
fenced frame team has recently decided that, in the case of fenced
frames being navigated to non-opaque URLs (we historically called this
"fenced frames in default mode"), since arbitrary data can be put into
the parameters of a URL, there will always be an
embedder-to-fenced-frame flow of information.

Because of that, there is no point in adding extra restrictions on
embedder-to-fenced-frame information flow since those can be easily
circumvented. This CL allows fenced frames loaded to non-opaque URLs to
inherit permissions from their embedder. Note that opaque fenced frames
loaded through an API like FLEDGE or Shared Storage will still have the
current restrictions in place, since their security model still
disallows information flowing from the embedder into the fenced frame.

As a feature of its architecture, MPArch does not have access to
permissions policy information in its parent on the renderer side. To
give a fenced frame that access, we need to explicitly give it that
information through the fenced frame properties. This CL adds the parent
frame's parsed permissions policies and its origin to the
FencedFrameConfig and FencedFrameProperties objects. This is done
instead of just adding the PermissionsPolicy object for IPC reasons. The
parsed permissions policies and origin can be sent in an IPC message and
are the 2 pieces needed in order to reconstruct a PermissionsPolicy on
the renderer-side.

This CL explicitly does not modify any permissions policy code related
to client hints. That will be done as a follow up.

This CL also updates WPTs to account for the change.

Change-Id: Id7ebdb29405dc77f581af63a3f5b3f3526322d33

Reviewed-on: https://chromium-review.googlesource.com/4690303
WPT-Export-Revision: 9b9dbbcac3d91da48441e582bcb6e2ae55874b05