Is a new Permission type required for presentation display availability?

[mfoltzgoogle]

This issue considers whether it's required to add an explicit enum to the Permissions API [1] to track the request by a page to monitor presentation display availability via the Presentation API [2](as a followup to #45 (comment)).

Currently, user agents may deny the request for continuous monitoring of screen availability based on power consumption considerations. Based on TAG review of the API [3], there was a sense that some user agents may also want to make this an explicit permission granted by the user, to allow the user to control the amount of information discoverable about their network environment.

We'll add discussion here, and then make an issue/PR against the Permissions API if necessary.

@mounirlamouri @marcoscaceres do you have any feedback? What is the criteria for including a new permission type in the API?

[1] https://w3c.github.io/permissions/
[2] http://w3c.github.io/presentation-api/
[3] https://www.w3.org/2015/10/29-webscreens-minutes.html#item02

[anssiko]

I think the initial idea was to add "partial enum" support to WebIDL, but since that has not yet made it to WebIDL, patching PermissionName is the way. I believe the editors @mounirlamouri @marcoscaceres will appreciate a PR and given this API ships in Chrome there's a good reason for "presentation" to be included (considering e.g. "midi" is included, "presentation" likely matches the same criteria for inclusion).

We do not need to block this spec on getting the enum updated in the canonical spec, and can describe in prose the new permission name to be used in the interim.

[mfoltzgoogle]

First I'd like to see a good justification for adding the permission to begin with. I am wondering how the initial set of permissions were chosen for the Permission API and what the criteria are for adding new ones.

[mounirlamouri]

I think we should add presentation only if it is used by some UA. At the moment, I don't think there is a need for it and it would be a no-op permission. I'm not sure it is worth it.

Regarding midi, it was added becaus of sysex being linked to a permission (at least in Chrome) and the design of midi is to request midi access. As a consequence, for completeness, instead of having a midi-sysex permission, we decided to have a design closer to the Midi API: there is a midi permission for which some boolean (like sysex) can be passed. Note that Chromium design is changing to allow midi to become a real permission. I do not know if Chrome will use it as a real permission but other content embedders (ie. Chromium-based projects like Opera) might have a midi permission.

[marcoscaceres]

The same applies to other things in the spec: they were already asking for permission.

[mfoltzgoogle]

@anssiko Are you still in favor of adding a permission given the feedback of @mounirlamouri and @marcoscaceres?

[anssiko]

I did not have a strong position on this issue -- I was just pointing out how we'd need to mechanically patch PermissionName enum if the group would decide to go down that path.

I haven't heard any implementer voice concerns over not having Permissions API integration, also horizontal reviews beyond TAG did not raise this as an issue. That suggests we would be fine closing this issue without normative changes to the spec. My expectation is we could retrofit the feature at a later stage if a need arises, as has been done with some other APIs (e.g. geolocation, camera, notifications).

Does anyone see a need for some informative text to be added to the spec to clarify permissioning? Unless we hear objections, @mfoltzgoogle you can close this issue.

[tidoust]

Discussed at the F2F:
http://www.w3.org/2016/05/24-webscreens-minutes.html#item13

PROPOSED RESOLUTION: re. #255, no new permission type required
ACTION: Mark to close issue #255 with summary of discussions.

[mfoltzgoogle]

Per discussion from F2F, there is no implementation today where there is a chance to skip the device selection list via PresentationRequest.start(). Also the Permissions API editor @mounirlamouri does not deem a new permission necessary.

Closing.