Re: Proposed new text for noaccess

On 05/11/13 17:39, Jan-Ivar Bruaroey wrote:
> On 10/30/13 2:35 AM, Eric Rescorla wrote:
>> On Tue, Oct 29, 2013 at 10:04 PM, Harald Alvestrand
>> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>>
>>     On 10/30/2013 01:14 AM, Mandyam, Giridhar wrote:
>>     > Referring back to Example 2
>>     (http://www.w3.org/TR/mediacapture-streams/#examples), in existing
>>     implementations the permissions UI is presented as soon as the gUM
>>     call is made.
>>     >
>>     > If I'm to understand you correctly, the permissions call would
>>     instead only be presented when when applyConstraints() is invoked
>>     on the VideoStreamTrack to change "noaccess".
>>     >
>>     > So the user opens up the webpage and gets to see a camera
>>     preview image initially.  But the application is blocked from
>>     invoking canvas.getContext('2d').drawImage() or
>>     canvas.getContext('2d').getImageData() at this point because the
>>     "noaccess" constraint has not been changed.
>>     >
>>     > What other operations need to be blocked until the 'noaccess'
>>     constraint is modified?
>>
>>     According to what Martin said earlier, the call to
>>     canvas.getContext(....) would not be blocked, it would simply
>>     render black.
>>
>>
>>     This is one point that's critical to clarify in the description of the
>>     constraint, if this is what we want; the current text EKR proposed
>>     reads
>>     as if the operation is not permitted, preventing the scenario above.
>>
>>
>> I could live with either, but I think Martin is probably right to suggest
>> black,
>
> I agree as well, on black over blocking.
>
> At this point I'd like to re-iterate my suggestion from 9/6/13 12:20 PM
> to do the same for user-permissions. Modern browsers don't block on
> permission prompts, so neither should our API. What's the difference
> between 'noaccess' and a stream which the user has yet to grant access
> to? - In my mind, very little.
>
> In my mind, a 'noaccess' stream and a stream awaiting user-permissions
> are similar and could work the same:
>
>  1. getUserMedia returns quickly.
>  2. If the website shows the user a local view of their stream at all
>     (and many sites will not), the user sees either:
>       * Black,
>       * Local video, with dimming or water mark or "Relax, not live!"
>         don't-show-me-this-again warning workflow,
>           o (or any other fancy way to communicate audio/video-muting,
>             as browsers are good at innovating UX)
>       * Local video,
>       * "Click to play?"

I don't really understand if there would be a difference in the consent 
dialogue if the app shows a local view or not - is "Click to play" the 
same dialogue on both cases?

>
>         And this would depend on /browser settings/ and user comfort
>         level (let browsers handle defaults here).
>
>  3. If stream is 'noaccess' then stay here. If app ever lifts
>     'noaccess', goto 4.
>  4. If browser ever returns that user-consent has been granted, then
>     unmute/promote stream to full access.

I sort of like this. If it also came with the info that also a 
"noaccess" MediaStream can be attached to a PeerConnection (but would 
never let any RTP packets, or only silence/black-RTP, go out on the net) 
it could be used to get the negotiation going immediately (since gUM 
returns quickly).

>
>
> A one-size wont fit all. I agree with Adam that some (like me) will balk
> at the browser turning on the camera light under any circumstance
> without consent (I don't trust bits, so don't force me to unplug my
> camera or put my tinfoil hat over it).
>
> It bothers me to hear 'noaccess' use-cases where the sole goal seems to
> be to affect the user's permission-dialog experience. Why would we trust
> web-sites with this? The browser is the best shepherd of the user's
> privacy UX experience - The more we decouple it and diversify here, the
> harder it becomes to socially engineer around.
>
> See my original post for other benefits:
>
>   * Synergy with over-constrained and mute/un-mute.
>   * Solves the double permission-dialog sucky UX.
>   * Speeds up call-setup in common cases (by not blocking on user).
>   * Simpler API, because the browser owns the permissions UX piece.
>     Better behaved/non-contorting apps.
>
>
> .: Jan-Ivar :.
>
>>
>> -Ekr
>>
>>     Surveillance is pervasive. Go Dark
>>
>

Received on Tuesday, 5 November 2013 19:11:39 UTC