Should getDisplayMedia be functional in SecureContext only?

[youennf]

Following on w3c/webrtc-pc#1945, the question is whether to mandate secure origins for getDisplayMedia.
We could:

• Mandate to reject getDisplayMedia promise for non secure origins
• Make getDisplayMedia SecureContext

[alvestrand]

Are these two alternatives?
I think I'd prefer the second, because it's simpler, and corresponds to a lot of other API behaviors.

[youennf]

These are alternatives.
I also tend to prefer the second although the first is consistent with existing getUserMedia behavior.
In a perfect world, we could envision moving back getDisplayMedia to navigator.mediaDevices and make mediaDevices SecureContext.

[martinthomson]

I also prefer the second.

[jan-ivar]

What are the behavioral differences from this choice?

1. ("getDisplayMedia" in navigator) is false, e.g. throws TypeError: ... not a function vs.
2. Rejects promise with some error? vs.
3. something else?

Where "some error" is what, SecurityError, NotAllowedError, NotSupportedError?

Neither Feature Policy nor the Permissions spec seem to mention specific errors.

[jan-ivar]

It's 1.

"An interface, namespace, or member construct is exposed" in an insecure context if it's available in both secure and non secure contexts, which boils down to [SecureContext] in WebIDL.

[jan-ivar]

Make getDisplayMedia SecureContext

Makes sense to me. This is a new powerful method.

[cynthia]

Ping if there was any consensus/decision on this.

[jan-ivar]

Yes, see w3c/mediacapture-main#540 (comment).