Re: Proposed new text for noaccess

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.

>  
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com] 
> Sent: Tuesday, October 29, 2013 4:53 PM
> To: Mandyam, Giridhar
> Cc: Harald Alvestrand; public-media-capture@w3.org
> Subject: Re: Proposed new text for noaccess
>
> On 29 October 2013 16:48, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
>> Problem:  As far as I can tell, no permissions UI was ever presented to the user in the above scenario, because the "noaccess" constraint was never changed.  Is this the desired behavior?
> This would be expressly prohibited.  Any pixel on the screen that is altered by the "noaccess" stream cannot be captured by the application.  The intent is that anything constrained as "noaccess" is inaccessible to applications.


-- 
Surveillance is pervasive. Go Dark.

Received on Wednesday, 30 October 2013 05:04:54 UTC