Aspects and integration with Permissions Policy

[antosart]

The Permissions specification allows powerful features to have aspects that further restrict or enlarge the allowed capability. However, policy-controlled features in Permissions Policy are simple string which are either allowed or not. So "aspects" are not controllable via Permissions Policy.

What is the guidance on defining new powerful features for which aspects would in principle make sense, but where it would also make sense to control those aspects via Permissions Policy?

One concrete existing example could be "midi", which specifies a "sysex" aspect. There is a corresponding "midi" policy-controlled feature, but in Permissions Policy there is no way of distinguishing between midi-with-sysex and midi-without-sysex.

One perhaps more realistic (future) example could come up with approximate geolocation: it would likely make sense to distinguish between the two variants (precise vs approximate geolocation) both in Permissions and in Permissions Policy, but that seems only doable via two distinguished policy-controlled features (e.g. geolocation-precise and geolocation-approximate).

Related to #410.

[annevk]

How many permissions do we have with "aspects"? Can we just turn them into explicit permissions instead so they can also be represented by a standalone string? And then not introduce any new "aspects".

[antosart]

Trying to compile a list:

Powerful feature with extended PermissionDescriptor	corresponding policy-controlled feature
midi, with MidiPermissionDescriptor	midi
clipboard-write with ClipboardPermissionDescriptor	Chrome seems to support clipboard-write and clipboard-read
push with PushPermissionDescriptor	no policy-controlled feature
Chrome has a FullscreenPermissionDescriptor	fullscreen
camera with CameraDevicePermissionDescriptor	camera
file-system with FilesystemHandlePermissionDescriptor	none?

[annevk]

A fair number of these are not fully standardized.

push is not really something you can delegate so that slight disparity makes sense to me.

They also all seem like they could be flattened.

[antosart]

I guess flattening could make sense.

I was wondering if this had been taken into consideration when the section around PermissionDescriptors etc in the Permission spec was written and if there was any background which I wasn't aware of.

[annevk]

I don't fully remember. Except that the current setup always seemed over-engineered to me.

[jyasskin]

I designed the aspects to handle permissions like 'camera', 'usb', and 'display-capture', where you don't just have the permission or not. Instead you have permission to use a particular camera, device, or screen/window/tab. Permission policy hasn't needed to capture the particular device that's being delegated, so it could ignore those aspects.

+1 that it was probably a mistake to try to use them for boolean things like sysex and allowWithoutGesture. However, to flatten them, you'll need to figure out what you want to do with the "stronger than" relation: do you want a permission policy of "midi-with-sysex" to allow requesting midi-without-sysex? (Probably, but you'll need to include it in your specification change.)