You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The discussion opens with when AUC would be sufficient. I think it would be better to start with a definition.
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.
(Full disclosure: I have recently changed the implementation of Chrome to match that model which I advocate for here.)
The text was updated successfully, but these errors were encountered:
Section 9.2.1 refers to "Active User Consent" (henceforth: AUC). As of the time of this writing, it reads:
I see a few issues here.
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:
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:
(Full disclosure: I have recently changed the implementation of Chrome to match that model which I advocate for here.)
The text was updated successfully, but these errors were encountered: