Why does this need to be provided as a web-facing API? All three provided use-cases could likely be done with closed (e.g. extension specific) APIs and you could deploy that as an enterprise policy, which would alleviate the risks of abuese by having it exposed on the web.

Why does this need to be provided as a web-facing API? All three provided use-cases could likely be done with closed (e.g. extension specific) APIs and you could deploy that as an enterprise policy, which would alleviate the risks of abuese by having it exposed on the web.

An extension API requires the installation of an extension, which implicitly grants permission to the extension to access a myriad other APIs that the admin might not even know about, let alone wish to allow. In some regards the extension path is actually riskier than a Web-exposed path, where the default stance is more security-conscious, and the holes enterprise policies poke through the wall are more deliberate.

Hi @eladalon1983 I'm not sure we entirely follow your argument. As @cynthia said, there are risks for abuse by exposing this to the entire web. From a safe to browse point of view, it should be difficult for the user to get into a scenario where they are sharing their screens. A risk I see that is not discussed in the explainer or the spec is users' responses to permission prompts being gamed – e.g. by phishing attacks claiming to be customer service for a financial provider. At the very least, it feels like there needs to be more in the spec about the potential abuse scenarios and mitigations, beyond presence of a "privacy indicator".

A risk I see that is not discussed in the explainer or the spec is users' responses to permission prompts being gamed

@torgo, a user cannot chance upon an arbitrary malicious site and be shown a dialog to share all their screens with that site. This API is restricted to origins allowlisted by the admin. That configuration should even be enough to forego a user-prompt altogether, if the user was warned earlier that the device might be subject to surveillance at any time, allowing them to walk away from the device rather than use it if they don't accept that.

That said, I believe other concerns (XSS) have prompted discussion of potentially moving this API off of the Web. @shangl would know the status of these and whether this TAG review request is still relevant.

Hi @eladalon1983 we've just been discussing in our TAG f2f today. We're of the mind that, for many of the same reasons articulated in our review of the managed device API we don't think this should be part of the web platform. The kind of surveillance you're talking about (where, by the way, people might not be able to make the decision to "walk away" without also losing their job or incurring other harms) is not something we're comfortable signing off on.

The kind of surveillance you're talking about (where, by the way, people might not be able to make the decision to "walk away" without also losing their job or incurring other harms) is not something we're comfortable signing off on.

I understand the discomfort and even share it, especially after seeing some public backlash to other controversial APIs. So I'd like to mention[*] for record that this very unfortunate dilemma - "accept or quit" - is already present in the lives of countless people, whose employers provide a machine running Windows/Mac/Linux with a native application installed that surveils the employee. Such existing native applications can even surveil the user without their knowledge. The API proposed by Simon here would take steps to improve our world, because it would at least ensure that the user knows the machine is subject to potential surveillance.

Creating a world completely free of surveillance is beyond our powers; we take pride in the little strides forward we can make.

-- [*] Also mentioned here.