- From: Eric Rescorla <ekr@rtfm.com>
- Date: Tue, 29 Oct 2013 23:35:21 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "Mandyam, Giridhar" <mandyam@quicinc.com>, Martin Thomson <martin.thomson@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CABcZeBMV=w=DsU4nV4c4JKpPb_=cSn7=N-USXyYReXAw6OMvQQ@mail.gmail.com>
On Tue, Oct 29, 2013 at 10:04 PM, Harald Alvestrand <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] > > 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 06:36:28 UTC