- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Feb 2022 14:23:00 +0000
- To: public-webrtc-logs@w3.org
eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-screen-share: == Active User Consent == Section 9.2.1 refers to "Active User Consent" (henceforth: AUC). As of the time of this writing, it reads: > Active user consent is sufficient where there is little or no risk of an application gaining information that the user did not intend to share. These cases can be identified by those where the application that requests capture has no control over what is rendered to the captured display surface. > > To prevent applications from limiting the available choices presented to a user with the goal of promoting a particular choice, the getDisplayMedia API does not permit the use of constraints to narrow the set of options presented. I see a few issues here. 1. The discussion opens with when AUC would be sufficient. I think it would be better to start with a definition. 2. The second paragraph has what partially looks like a definition, but is probably an elaboration of how the concept of AUC is to be applied to the issue of narrowing the user's choice. My reading of AUC is that the user has to take an action that's outside of their path-of-least-resistance user journey in order to consent. That the action has to suffer "friction" so that it would be clear the user has made a conscious choice, and hopefully made an informed decision. (For example, in the case of the Chrome media picker, there is no pre-selected display surface, even when there is only one option. There is a minimum of two clicks to start the capture.) **Point no1:** If I am right, then let's add a definition of AUC. In the case of audio, the spec currently reads: > The user agent MUST NOT share audio without active user consent. **Point no2:** It's not immediately clear how this applies with respect to the AUC already given to capturing the display surface. Does audio require **additional** AUC? My own opinion on this matter is that we should clarify that: * When sharing a display surface that has natural and clear affinity to a limited display surface, then we should not burden the user with additional AUC. For example, if sharing a tab, and all audio is coming out of that tab, then it's unlikely that the user would accidentally share audio and come to regret it. (Possibly this becomes trickier with workers, though. I'm leaving this issue aside until it becomes evident that it's relevant.) * When sharing a display surface that might have audio associated with it beyond what the user intended, additional AUC should be required. For example, if sharing a screen, it's not clear that the user intends to share audio for the entire system; this would be especially true if the user possesses multiple monitors, and might have a mental model where audio is somehow associated with the one which they are NOT sharing, e.g. if audio normally comes out of speakers built into that other monitor. Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/208 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 February 2022 14:23:02 UTC