[Question] Why does the spec require a browser to select the presentation device

[Marvin-Brouwer]

I've been reading the closed issues and I've skimmed through the spec before posting this.
I don't really understand why I'm not allowed to get a list of objects containing the presentable device's name, id, capability etc. and call presentationRequest.start('deviceId') or something similar.
Like the Media Capture and Streams API.

I've seen someone speculate here #315 (comment) that it might be because you want to give users control over which device they want to select. Preventing a website from just picking one at random and causing strange situations.
However, I haven't seen any official statement as to why this is specced the way it is.
If you make a mobile app you get the option to list out devices and style them inside of the app, so to me it makes sense a web site could do something similar. If I'm wrong that's fine, but I'd like to be able to read why the decision has been made.

[tidoust]

I'd say a major reason is fingerprinting. Giving access to the list of presentation displays would reveal too many bits of information about the user's context. I believe enumeration of devices in the case of the Media Capture and Streams API is only possible once capture of audio/video has already started (meaning when user has already granted permission about microphone and camera usage).

The Presentation API still allows web pages to assess whether there is a presentation display (and notes the underlying fingerprinting consequence under Personally Identifiable Information).

The spec notes another reason under Device Access: "The Presentation API requires user permission for a page to access any display to mitigate issues that could arise, such as showing unwanted content on a display viewable by others".

The Window Management API could perhaps be a better fit for multi-screen scenarios and allows to get detailed information about screens used by the user's device.

[Marvin-Brouwer]

Hmm, I figured it had something to do with security.
Didn't think of the fingerprinting.
However, from a user standpoint, I'm not particularly happy with the browser scanning my network for cast devices without my consent anyway. So I'd be more than fine with a popup saying something like "chrome would like to scan your network for cast devices". And then make the start of casting similar to playing audio, that it has to be a user interaction.

I'm not a security expert by any means so maybe I'm missing something, but I am experienced with javascript, and from a developer's perspective this is yet another inconsistency in programming api.

I'm not sure if this is the right place, but I hope sharing this helps.

[markafoltz]

MacOS is moving in the direction you suggest and requiring users to give Chrome permission to access your local network before Cast or other devices can be discovered. This does give users more control, but has also has caused a lot of problems because features like Cast and printing stop working if the permission is not granted. Users don't always associate (technical) prompts like these with features and capabilities they rely on.

[Marvin-Brouwer]

Interesting, I guess asking for specific permission like scanning for cast devices or printing would be more user friendly than just "local network access".
However, yet again, I'd rather have consistency in functionality and usage.

[tidoust]

I see you redacted this part of your comment, but you initially drew a parallel with Web Bluetooth and Web USB which I found interesting. Both specs have a mechanism to enumerate devices: Bluetooth.getDevices() and USB.getDevices(). These enumerations are restricted to "allowed devices", meaning those devices that the user previously granted the origin permission to use. Something similar could perhaps be discussed for the Presentation API?

[Marvin-Brouwer]

I see you redacted this part of your comment, but you initially drew a parallel with Web Bluetooth and Web USB which I found interesting. Both specs have a mechanism to enumerate devices: Bluetooth.getDevices() and USB.getDevices(). These enumerations are restricted to "allowed devices", meaning those devices that the user previously granted the origin permission to use. Something similar could perhaps be discussed for the Presentation API?

I redacted this because I realized the Bluetooth api opens a "native" browser window to list the devices similar to the chrome cast.
So my point was invalid and distracting.
But I do like your suggestion of "allowed devices" or perhaps even "allowed protocols". However, for the latter a human friendly description should be provided I guess.