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.

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

Dividing features across different types of policies #296

Closed
annevk opened this issue Apr 24, 2019 · 3 comments
Closed

Dividing features across different types of policies #296

annevk opened this issue Apr 24, 2019 · 3 comments

Comments

@annevk
Copy link
Member

annevk commented Apr 24, 2019

As per https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212 the idea is to divide features across different policies. Here's an initial take on that using https://github.com/w3c/webappsec-feature-policy/blob/master/features.md as source:

Existing features

Feature name Delegating permissions Document sandboxing Full sandboxing
accelerometer
ambient-light-sensor
autoplay ?
camera
document-domain ? (I think this is a new primitive and I'm not convinced it's worth it)
fullscreen
gyroscope
magnetometer
microphone
midi
picture-in-picture
sync-xhr
usb
wake-lock
xr

Proposed features

Feature name Delegating permissions Document sandboxing Full sandboxing
Client Hints
encrypted-media ?
geolocation
payment
speaker

Experimental features

Feature name Delegating permissions Document sandboxing Full sandboxing
document-write
font-display-late-swap
layout-animations
lazyload
legacy-image-formats
oversized-images
sync-script
unoptimized-images
unsized-media
vertical-scroll
serial

(I'm not entirely sure about all of these, let's try to keep this comment updated as we reach firmer conclusions on each of them.)

@eeeps
Copy link
Contributor

eeeps commented Jun 26, 2019

Will these different feature-types be getting different:

  • Syntaxes for values? (seems likely)
  • Header/attribute names? (not sure)
  • Specs? (seems less likely)

@clelland
Copy link
Collaborator

The most compelling insight from this table, I think, is that delegation and sandboxing are two different domains, and that if we're looking at splitting FP into different mechanisms, that seems like a clear distinction that we can make.

Delegation matches the existing spec quite well, and if we were to focus it on just that use case, we could probably trim it down a bit, too.

I'm just working on an actual proposal, but I would suggest:

  • Different syntaxes, due to the deployment of existing delegation
  • Different header / attribute names for the two kinds of features.
  • One spec or two? Hard to say what's better; keeping everything here is administratively easier, certainly.

@clelland
Copy link
Collaborator

Closing with the introduction of Document Policy; the document/full sandboxing features listed in the initial description are all movable to that mechanism (I'll open a separate issue for SyncXHR)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants