RE: Proposed new text for noaccess

Thanks for the explanation, but this only leads to more questions.  If I'm to summarize only with respect to Example 2 of the spec as it stands, canvas.context operations on content derived from a {"noaccess" = true} VideoStreamTrack will not be blocked but will result in data corresponding to black pixels.

On the other hand, if the webpage has other canvas elements with content derived from "safe" sources the UA should allow canvas.context operations to proceed as expected (i.e. no black rendering).

If I'm correct in trying to discern what the desired behavior is for canvas.context operations, then my next question is where does this get spec'ed?  Does this need to be specified in http://www.w3.org/TR/2dcontext/?

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Tuesday, October 29, 2013 11:35 PM
To: Harald Alvestrand
Cc: Mandyam, Giridhar; Martin Thomson; public-media-capture@w3.org
Subject: Re: Proposed new text for noaccess



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,

-Ekr



>
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>]
> Sent: Tuesday, October 29, 2013 4:53 PM
> To: Mandyam, Giridhar
> Cc: Harald Alvestrand; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
> Subject: Re: Proposed new text for noaccess
>
> On 29 October 2013 16:48, Mandyam, Giridhar <mandyam@quicinc.com<mailto: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.