- 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