Re: Proposed new text for noaccess

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?"

        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.


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
>