Re: [mediacapture-screen-share] A CaptureController object for getDisplayMedia() (#230)

> 1. focus() is a one time thing.
> This option is more capturer saying "I made a decision to focus or not to focus".
> In that case, I would prefer that web site be explicit about either 'I focus' or 'I do not focus'.

That's the version I'm after, and for that reason, I want an explicit decision - `setFocusBehavior(FocusBehaviorEnum)`.

> It does not seem bad for capturer to provide UI to quickly go to capturee.
> In that case, we could gate it by standard user activation, and we could say that getDisplayMedia prompt selection (if successful) is a user activation.

Vendors of video conferencing software have requested this functionality (this = focus-capturee at an arbitrary time). At the moment, I don't think we can accommodate them, because the risks outweighing the rewards. (Note that user activation is insufficient - tricking the user to double-click at arbitrary coordinates on the capturer then becomes equivalent to tricking them into single-clicking at the respective coordinates of the captured surface.)

Focus at an arbitrary moment is out of scope for me at this time.

> At the same time, I don't have a specific use case in mind

That's my situation too. There's significant overhead to **adding** this functionality (this = Promises that resolves when focus-change happens).
* Spec authors need to (1) evaluate the risk and (2) specify.
* Implementers (3) have more work when implementing.
* Someone has to (4) document this additional functionality for Web-developers.
* Web-developers (5) need to read longer documentation and (6) produce more involved code.

A use case has to motivate all of this extra work. I have thought about it and could not find it.

> The method model does offer us a way to convey failure to focus for whatever reason. Might that be of interest to video conferencing sites?

I don't think it's actionable enough to justify the costs. To hedge our bet, if this changes in the future, we can fix our mistake by exposing a `getLastFocusResult()` that returns a Promise. It's not pretty, but I believe that it's a plan B that we'll never have to implement, so it's existence is enough to calm my nerves over this design decision.

> This is not sufficient.

I don't understand why. Your example attack consists of capturing the wrong tab, but one which looks identical to the right one. How is focusing it making it less identical? How does it defang the attack? Focus seems orthogonal here.

---

I propose the following consolidation:
1. No controller provided - legacy behavior retained (focus not specified).
2. `getDisplayMedia()` with a reused `CaptureController` object -> rejected Promise before showing the user a dialog.
3. If `CaptureController.setFocusBehavior()` is not called, focus behavior is not specified. It's a non-issue, and user agents will **continue** to implement their own behaviors.
4. If `getDisplayMedia()` fails, all methods on the `CaptureController` will raise an exception.
5. `CaptureController.setFocusBehavior()` raises an exception if called from a microtask other than the one `getDisplayMedia()` resolved on.
6. Second call to `CaptureController.setFocusBehavior()` within the same aforementioned task raises an exception.
7. `CaptureController.setFocusBehavior()` is no-op if called from the aforementioned microtask, but >= N milliseconds after that microtask has started executing. (I can go into details about why no-op is important for Chrome here, but I'm trying to keep the discussion focused for now, no pun intended.)
8. Spec TODO to decide whether `setFocusBehavior()` before `getDisplayMedia()` is allowed, and if allowed, exactly how it works. (Chrome will implement this as no-op so as to ensure we can easily align with specified behavior once we reach consensus.)

If we can agree on this, I can prepare the PR.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1235415996 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 September 2022 12:00:51 UTC