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

Further alignment with Permissions Policy #356

Open
marcoscaceres opened this issue Feb 7, 2022 · 0 comments
Open

Further alignment with Permissions Policy #356

marcoscaceres opened this issue Feb 7, 2022 · 0 comments
Assignees

Comments

@marcoscaceres
Copy link
Member

Elsewhere, @equalsJeffH wrote:

Please see also my belated comment on PR #264 (relevant portion copied here for convenience):

WRT the text this PR #264 added to the Permissions spec, it seems to be only implied that where a given feature is both a powerful feature, and is also subject to permissions policy, that the feature's "policy-controlled feature token" (as defined in the feature's specification), and in the Permissions spec's PermissionName enum (aka "Powerful features registry"), can be the same, but (I am guessing) do not have to be the same. Though, I am guessing that the intent is for them to be the same (I cannot quickly find an example where they are not the same). In any case, whatever the requirement is, it ought to be stated explicitly.

E.g., the strings "camera" and "microphone" are both defined as powerful feature names and are also declared as policy-controlled feature tokens (aka "strings").

Additionally, I find this statement in the text this PR added confusing:

The APIs and features in scope for the Permissions Policy specification go beyond those identified in this specification's PermissionName enum (e.g., "sync-xhr" and "gamepad").

...because: neither "sync-xhr" nor "gamepad" are permission names (i.e., enum values within PermissionName) -- so it is not obviously clear what using those policy-controlled feature tokens (aka "strings") as examples is intended to mean. Clarification would be good.

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

1 participant