- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 6 Sep 2013 15:34:38 -0700
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 6 September 2013 15:00, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: > If getUserMedia returned muted streams which may contain something valuable > later, then browsers can defer bothering the user until there's a need. > > This untangles the UX from the API, and lets browsers manage their users > without encumbering the web-developer. I think that you are describing something very much like what was in the settings API proposal Sadly, https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/SettingsAPI_proposal_v6.html is 404. Here's the basic idea: var video = new VideoMediaStreamTrack(videoConstraints); var audio = new AudioMediaStreamTrack(audioConstraints); var stream = new MediaStream([video, audio]); // -> go and use the stream for signaling setup etc... navigator.getUserMedia(stream, callback, err); // this just connects the tracks to active sources Of course, it's trivial to support the old API style if you don't care for the extra work: var constraints = { video: videoConstraints, audio: audioConstraints }; navigator.getUserMedia(constraints, callback, err); There are two key aspects to this arrangement: the consent dialog is directly connected to an application need and the consent dialog is only invoked once there are user visible consequences. Remove either and the value of the consent degrades. As roc observes, this doesn't prevent greedy applications from being greedy, but we have other measures to control that. There are other interaction models that produce better consent, but those are probably overkill for this particular use case. (They might not be for something like screen capture though.)
Received on Friday, 6 September 2013 22:35:05 UTC