Move permissions out to each spec

[marcoscaceres]

The Permissions registry seems a roundabout way to maintain things.... I think we definitely keep the various parts other specs need to define (plus an example of what other specs need to do), keep the enum, but then move all permission descriptions to their respective specs.

That allows this spec to "gate-keep" the main enum for the API, but allows other specs to define their own permissions.

TODO:

• Ensure "accelerometer" is integrated into parent spec #296
• Ensure "ambient-light-sensor" is integrated into Ambient Light Sensor spec #307
• "background-fetch", (Ensure "background-fetch" permission is integrated in Background Sync spec #295)
• Ensure "background-sync" is integrated into Web Background Synchronization spec #308
• Ensure "bluetooth" is integrated into Web Bluetooth spec #317
• Ensure "camera" & "microphone" are defined in their parent spec #323
• Ensure "display-capture" is integrated into Screen Capture API spec #322
• "geolocation" (Editorial: update permission policy usage geolocation#105)
• Ensure "gyroscope" is integrated into Gyroscope API #321
• Ensure "magnetometer" is integrated into parent spec #326
• Ensure "midi" permission is integrated in Web Midi API spec #294
• Ensure "nfc" is integrated into parent spec #328
• Ensure "notifications" permission is properly integrated into parent spec #291
• Ensure "persistent-storage" is integrated into parent spec #329
• Ensure "push" permission is integrated into Push API spec #293
• Ensure "screen-wake-lock" permission is integrated in Screen Wake Lock API (or just remove it?) #319
• Ensure "speaker-selection" is integrated into Audio Output Devices API spec #320
• Ensure "xr" is integrated into parent spec #330

[jyasskin]

I tried to do this at some point by having each spec <dfn> its PermissionName enum value, but IIRC Bikeshed didn't autolink from https://w3c.github.io/permissions/#enumdef-permissionname to definitions outside the current spec, and writing that enum manually broke reffy's IDL parser. https://w3c.github.io/permissions/#bluetooth is the maximum amount of "define everything in the feature's spec" that seemed possible, but going that far seems like a good idea.

[marcoscaceres]

My plan is to separate the concept of a "permission" (a new definition type), and those independent of the enum values. Specs now routinely define an "Integration with Permissions Policy" section where they identify the permission string they are using. Our spec will just define the enum and values, but not claim to be the permission itself.

That way, we can avoid the auto-linking issues (🤞) and everyone can own their own stuff.

[hamishwillee]

@marcoscaceres Somewhat related to this, should web-share be listed as a permission in the spec? I ask because there appears to be a 1:1 mapping to the Permission Policy definitions for most permissions and permission policy settings..

It isn't totally clear what the mapping "should" be (to me). Is the following correct?

• permissions control what options are offered to users via the browser settings or GUI when you try to use an API.
• permission policy determines what the server thinks you should be able to use, and generally might be what sets the permission or what makes it visible to a user.

Further, more closely related, if you move the permissions out to specs it would be really helpful to provide some information about where they are going to. Then we can update the browser compatibility info https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API#browser_compatibility with spec links.

[marcoscaceres]

@marcoscaceres Somewhat related to this, should web-share be listed as a permission in the spec? I ask because there appears to be a 1:1 mapping to the Permission Policy definitions for most permissions and permission policy settings.

No, and I totally understand that it looks like there is a 1:1 mapping. This is something I'm actually trying to fix.

This spec will only deal with APIs that prompt for UI: like Geolocation.

I added some text to try to explain the relationship between the two specs:
https://w3c.github.io/permissions/#relationship-to-permissions-policy

For the case of "web-share", there is no permission prompt UI in any browser - hence, it's not part of this spec.

It isn't totally clear what the mapping "should" be (to me). Is the following correct?

• permissions control what options are offered to users via the browser settings or GUI when you try to use an API.

Yes, what we call "power features" in our spec. Powerful features (e.g., geolocation) need to get "permission" via some UI.

permission policy determines what the server thinks you should be able to use, and generally might be what sets the permission or what makes it visible to a user.

Correct (I wish Permissions Policy wouldn't of changed their name - it's made everything very confusing!)...

A "permissions" per the Permission Policy spec control the availability of an API in a given context, for example:

<!-- this allows geolocation -->
<iframe allow="geolocation" src="https://third-party.com"></iframe>

Further, more closely related, if you move the permissions out to specs it would be really helpful to provide some information about where they are going to. Then we can update the browser compatibility info https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API#browser_compatibility with spec links.

Sure! should I ping you directly? I can add something to our pull request template.

[hamishwillee]

1. Excellent summary of the differences in the APIs in the spec. Wish I'd know about that 6 months ago :-). One typo "Policy governs wether a feature ..."
2. I'll try and make sure this is untangled more on MDN too. Might take a little while.
3. Rather than ping me, please create an issue here: https://github.com/mdn/content/issues and @hamishwillee tag me in it. That way if something happens to me someone else can pick it up.

Thanks again for your help.

[marcoscaceres]

Where applicable, we should add a "Permission prompt" heading/section to specs and add:

• it is a default power feature,
• and any step/algorithms there...