Permissions Policy Support

This patch for D9 works has expected for me.
We can configure the "Permission Policy" headers and it is added and applied.
"Feature Policy" still present and works also.
Thanks

Thanks for this. Couple of thoughts:

-      '#description' => $this->t('Allows configuration of the Feature-Policy header to selectively enable, disable, and modify the behavior of certain APIs and web features in the browser. See <a href=":feature-policy_docs">@feature-policy_docs</a>.', $args),
+      '#description' => $this->t('Warning: The Feature-Policy header has been deprecated by browsers in favor of Permissions-Policy. It is recommended to no longer use Feature Policy and instead set a Permissions Policy below.'),

1) I don't think we should replace the existing docs for Feature Policy with a "do not use this" message. It's fine to add a note about deprecation.

2) In ✨ Text fields not big enough Fixed we've changed a lot of textfields over to textareas where the values can be long. Let's do the same for any new fields we're adding here.

3) It'd be good to have separate issues for the 7.x-1.x and 2.x branches, because it makes testing easier if nothing else.

+  /**
+   * Tests disabled permissions-policy.
+   */
+  public function testDisabledPermissionsPolicy() {
+    $form['seckit_pp[permissions_policy]'] = FALSE;
+    $this->drupalPostForm('admin/config/system/seckit', $form, t('Save configuration'));
+    $expected = 'interest-cohort=()';
+    $this->assertSession()->responseHeaderEquals('Permissions-Policy', $expected);
+  }

IIUC this is effectively testing the FLoC-blocking header that was added to core. That header's now been removed from D7 and will be deprecated/removed in D9/10 in due course ( #3260401: Google is abandoning FLoC - so remove the header → ).

Can we adapt this test so that it would pass if the Permissions-Policy is either absent OR matches the FLoC-blocking example above perhaps?

We don't want it to fail based on changes in core.

More generally, I wonder whether we wouldn't be better adding the ability to add arbitrary key/value pairs as headers as opposed to adding hard-coded headers like this one as the standards develop.

The patch from #6 not applying cleanly to 7.x-1.12.

Created updated patch for 7.x-1.12

Hello,

The module Permissions Policy ( https://www.drupal.org/project/issues/permissionspolicy → ) does the job very well. Maybe integrating it as a Security kit submodule could be a good solution.