Change Feature Policy to Permissions Policy (D8/D9)

Set last patch as NR.

1. +++ b/config/schema/seckit.schema.yml
   @@ -145,14 +145,14 @@ seckit.settings:
   -    seckit_fp:
   +    seckit_pp:
   

   I don't think we should replace fp with permissions policy, but add it. Specially in schema. We might want to mark it as deprecated though.

2. +++ b/tests/src/Functional/SecKitTestCaseTest.php
   @@ -626,27 +626,27 @@ EOT;
   +      'seckit_pp[permissions_policy_policy]' => "accelerometer 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; payment 'none'; usb 'none'",
   

   This is technically invalid and browser (at least Chrome) will report as a parsing error. See https://www.studytonight.com/post/solved-error-with-permissionspolicy-he... for a syntax example. I know it's just a test, but let's provide a valid policy.

I was thinking this might need an upgrade path, but as the syntax is changing, not sure if we can/want to do that. Anyway some mechanism should be added for users to notice. Maybe a status report warning is enough if feature policy exists but no permissions policy?

This creates a new setting instead of replacing the feature-policy one. Adds a text for marking that one as deprecated.
Tests fixed and passing.

$this->t('Deprecated. You might want to set Permissions Policy instead.')

Let's reword this to indicate this setting should still be used to support Safari: https://caniuse.com/mdn-http_headers_permissions-policy

Attached patch with a different description pointing to CanIUse

The patch is working as expected - see screenshots.

A couple of suggestions to improve the UI and usability:

1. May I recommend refraining from using Google or Chrome documentation in the links and using docs from more neutral-web organisations like Mozilla or W3C:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Permissions_Policy
https://www.w3.org/TR/permissions-policy/

2. Proposed: re-structure UI and rephrase some text to indicate that those two headers are related (see proposed screenshot)
also include link to W3C changelog: https://www.w3.org/TR/permissions-policy/#changes-since-fpwd

thanks @jannakha, I like the proposal to restructure the UI and use the docs link from neutral source.

I created a new patch changing a little bit the description and documentation links. I also moved the fields as jannakha proposed but I kept the Permissions policy and Feature policy as different sections.

I dont think 700 characters is enough, if u want to disable everything by default the header is already 811 charachter long and this is without even settings a url or wildcard:

accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=(), clipboard-read=(), clipboard-write=(), gamepad=(), speaker-selection=(), conversion-measurement=(), focus-without-user-activation=(), hid=(), idle-detection=(), interest-cohort=(), serial=(), sync-script=(), trust-token-redemption=(), unload=(), window-placement=(), vertical-scroll=()

Patch for the version 2.0.1

Feature policy has been renamed to Permission policy a while back but this is still not merged.

https://httptoolkit.com/blog/renaming-feature-policy-to-permissions-policy/
https://w3c.github.io/webappsec-permissions-policy/

Can we expect a new release with Permission policy before Drupal 11 is released in less than 2 weeks?