Permissions-Policy rules to consider

[philwareham]

We have implemented some Permissions-Policy header rules - although the feature is in draft form and the spec and number of policies is in flux. Listed below are rules that we may want to consider as things develop. Please leave this issue open (but check off any rules we have implemented) as this will be an ongoing process. I have included links to documentation for each policy where available - feel free to add any missing doc links as and when you find them.

• accelerometer
• ambient-light-sensor
• autoplay
• battery
• camera - set to none except forum set to self (users potentially access camera roll for posts)
• cross-origin-isolated
• display-capture
• document-domain
• encrypted-media
• execution-while-not-rendered
• execution-while-out-of-viewport
• fullscreen
• gamepad
• geolocation - set to none (we don't use any geolocation features or targeting)
• gyroscope
• interest-cohort (only declared on forum, which is potentially the only domain where this could be of use - will keep an eye on this as it's not part of official spec)
• layout-animations (TBC)
• legacy-image-formats (TBC)
• magnetometer
• microphone
• midi - set to none (we don't use Web MIDI API on our sites)
• navigation-override
• oversized-images (TBC)
• payment
• picture-in-picture
• publickey-credentials-get
• screen-wake-lock
• speaker-selection
• sync-xhr
• unoptimized-images (TBC)
• unsized-media (TBC)
• usb
• web-share
• xr-spatial-tracking

See https://github.com/w3c/webappsec-permissions-policy/blob/master/features.md for the latest list of accepted/proposed features.

[petecooper]

Feature Policy has been renamed Permissions Policy:

https://scotthelme.co.uk/goodbye-feature-policy-and-hello-permissions-policy/

https://caniuse.com/permissions-policy (no browser support at the moment)
https://caniuse.com/feature-policy (~90% at time of writing)

[philwareham]

Thanks Pete - will investigate this next week.

[petecooper]

No action needed really, I'm doing Feature Policy to Permissions Policy duping as sites are migrated (given zero browser support it's hardly urgent), so we can run both in parallel for as long as we need to.

[philwareham]

@petecooper I think now is the time to remove Feature-Policy from the headers and just use Permissions-Policy. The inclusion of the older header is giving me console warnings in Chrome and affecting Lighthouse scores.

Since Chrome is the browser that's most advanced terms of Feature-Policy/Permsisisons-Policy support which should IMO use that as the benchmark. Other browsers will gradually fall in line with the updated spec.

[petecooper]

Yep - agreed. I'll strip 'em out and upload this evening unless you get there first.

[petecooper]

Actually, I have a bit of time before a meeting, I'll start now.

[philwareham]

Cheers. I see we are also missing some of the previous rules such as accelerometer - any reason for that?

[petecooper]

Not intentionally, no - by all means add back in, I haven't taken stuff out knowingly!

[philwareham]

OK, if you can strip out Feature Policy I will then add the additional rules to Permission Policy, so we don't clash with commits. Thanks very much!

[petecooper]

OK, first pass of FP stuff done, I'll upload configs in the interim then do it again when you're done.

[philwareham]

@petecooper great, I have now updated all the Permissions-Policy rules as per our list above. Happy for this to move to the live servers when you have spare time. No rush.

[petecooper]

@philwareham - all uploaded just now, Nginx bounced.

[petecooper]

@philwareham - we (you) should also update the OP links to reflect PP directives, not FP directives.

[philwareham]

Thank you Pete! Have a good day.

[Bloke]

Continuing discussion from here then...

Seems we have various classes of policy but categorising them is not intuitive (as you've no doubt found!). Combined with that, we currently have two broad sets of policies:

1. For docs, RPC, Textile, .io, .net, .org:
   camera=()
   fullscreen=(self)
   geolocation=()
   gyroscope=()
   interest-cohort=()
   magnetometer=()
   microphone=()
   midi=()
   notifications=(self)
   payment=()
   push=(self)
   speaker=()
   sync-xhr=(self)
   vibrate=()
2. Additional policies for .com:
   accelerometer=()
   ambient-light-sensor=()
   autoplay=()
   battery=()
   display-capture=()
   picture-in-picture=()
   screen-wake-lock=()
   usb=()
   xr-spatial-tracking=()

BUT in the .com case there are three missing from the common list:

• notifications
• speaker
• vibrate

So the 'cheap' way to do it is to just have 3 includes, one for each of the above sets and load them in according to how we need them per server.

Better, might be a classification system that we can use to lump newer things in as and when they come along but, as noted, that's fun especially given that some of the classes we need on one server and not another. I've had a go and come up with four potential groups:

Peripherals - always shared (at the moment)

• Common
  camera
  microphone
  midi
• Omitted from .com
  speaker

Mobile (out and about)

• Common
  geolocation
  gyroscope
  magnetometer
• Extras for .com
  accelerometer
  ambient-light-sensor
  battery
  screen-wake-lock
• Omitted from .com
  vibrate

Display-related (notifications/updates)

• Common
  fullscreen(self)
  push(self)
  sync-xhr(self)
• Extras for .com
  display-capture
  picture-in-picture
• Omitted from .com
  notifications(self)

Interfaces (to other software systems)

• Common
  interest-cohort
  payment
• Extras for .com
  autoplay
  xr-spatial-tracking
  usb

Bit of a mess. We could narrow that down to hardware/software split - that might be neater. I'm sure if we hammered this around a bit we could come up with a suitable taxonomy that allowed us to keep our hair/beards intact and manage this stuff in a sane way.

[petecooper]

BUT in the .com case there are three missing from the common list:
notifications
speaker
vibrate

They must've slipped through the net - not deliberately omitted afaik. Will fix.

[Bloke]

Ah, that makes it slightly easier as we only have two sets to maintain - common and extras, potentially for each distinct group :)

[philwareham]

Please don’t action this until I’m back from holiday. The sets should be identical and also reflect the list at the top of this thread (some policies never became final candidate so we’re removed, which I updated above). I need to double check if any more have been added or removed from spec in last 2 months before we can revise again.

[Bloke]

Cool, then that makes it simpler still :) One include. Job done.

[philwareham]

They must've slipped through the net - not deliberately omitted afaik. Will fix.

Sorry, I've reverted your commit - those rules were removed from the spec hence why they were purposely not on .com site. I'll go through the other site configs and remove them too now. Cheers.

[philwareham]

FYI I've removed the interest-cohort policy from all but the forum domain, for reasons I've already stated in the forum.

[philwareham]

@petecooper hi Pete, I have just updated all the server config files to ensure they have latest (and consistent) set of rules. Can you deploy to live when you get a moment? Thanks!

[petecooper]

@philwareham - done. For future ref, please try to leave files in https://github.com/textpattern/server-config/tree/main/temp/_to%20check%20and%20purge as-is since I need to pick through for anything that's dropped by the wayside as things evolve. No worries in this case since it's permissions policy uniformity, but there's value in them being former production files – I take a few now and again and diff against the current files, and tweak as necessary (mostly it's a just a housekeeping exercise). Thanks!

[philwareham]

OK, will keep that in mind. Thanks Pete.