Per https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts it seems browsers are moving in that direction. I'm not sure if [SecureContext] will work (e.g., perhaps there are sites assuming that interfaces exist), but restricting it to secure contexts in prose should be doable at least.

@dontcallmedom your feedback is solicited on this topic. Yves will follow up with context.

TAG doesn't really have objections to asking WebRTC to make it [SecureContext]. Implementations have already started moving the feature to [SecureContext]… See https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts. (Note Safari does restrict getUserMedia to [SecureContext].

From my testing, at least getUserMedia() seems to be secure context in at least three implementations, but the spec seems to disagree.

We should probably specify when we're talking about RTCPeerConnection vs. getUserMedia, vs. long tail of other mediacapture-* specs, as "WebRTC" is often an umbrella term for all of the above.

See w3c/mediacapture-screen-share#77 and w3c/mediacapture-main#540

And https://github.com/w3c/mediacapture-output/issues/78.

Thanks a lot for following up on this. We have checked all the PRs on the spec side and yes, we are very happy to see this change.

Thank you for flying TAG! We are excited to see how the next generation comes out.