Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active User Consent #208

Open
eladalon1983 opened this issue Feb 2, 2022 · 0 comments
Open

Active User Consent #208

eladalon1983 opened this issue Feb 2, 2022 · 0 comments
Assignees

Comments

@eladalon1983
Copy link
Member

eladalon1983 commented Feb 2, 2022

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.

(Full disclosure: I have recently changed the implementation of Chrome to match that model which I advocate for here.)

@jan-ivar jan-ivar self-assigned this Mar 10, 2022
@jan-ivar jan-ivar added this to the Candidate Recommendation milestone Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants