RE: Proposed new text for noaccess

> What do others think?

Consider an application where there is no WebRTC involved (i.e. no addStream being invoked).  An example would be a camera application that implements Example 2 in the current spec (http://www.w3.org/TR/mediacapture-streams/#examples), but could also be relevant to applications for ImageCapture when that API is supported.

Borrowing from Harald's example:

- User starts application
- Application grabs camera with "noaccess=true", shows user a self-picture along with a "snapshot" button to take a picture
- User checks hair
- User may or may not press "snapshot", but the app is fully capable of grabbing a frame from the canvas and doing whatever it wants with it.  Maybe the app grabs an image before the user has finished checking hair, then grabs another after the user presses "snapshot".  

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?

-Giri


-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, October 29, 2013 11:37 AM
To: public-media-capture@w3.org
Subject: Re: Proposed new text for noaccess

On 10/29/2013 07:04 PM, Martin Thomson wrote:
> On 29 October 2013 04:45, Harald Alvestrand <harald@alvestrand.no> wrote:
>> If a stream is opened "noaccess", and the site changes it to "full", 
>> and then immediately back to "noaccess", the site can get a picture 
>> of the user without the user noticing anything, even if he watches 
>> the indicator that says whether he's authorized outgoing video or not.
> That scenario smells more like conspiracy theory than a genuine 
> attack, if you ask me.  If you are on the whitelist, then this sort of 
> posturing isn't necessary.  This aggressor can also open a separate, 
> unconstrained stream that doesn't display in a <video> tag.
>
>> Can you write up a complete
>> use case where you will want to use the "noaccess" constraint
> "Hair Check"
>
> A real-time application provides users with the ability to check what 
> is being displayed on the camera prior to granting consent for use of 
> the camera.  (The same applies to use of a microphone.)
>
OK, so going into details, I expand this scenario to be:

- User starts application
- Application grabs camera with "noaccess=true", shows user a self-picture
- User checks hair
- User hits "call" button
- Application changes track constraints to remove "noaccess"
- UA prompts for permission to use camera, if app not pre-whitelisted
- Call gets set up, recorded, reindeer horns get painted, and all the other
  things we've come to expect from media processing.

Is that a correct expansion of your use case?

This, to my mind, requires that the description that EKR presented on Oct 26 be expanded to say:

- How "noaccess" interacts with the permissions prompt (I don't think the present MAY text is enough - we should expect some consistency between browsers here)

- says that "noaccess" can be changed at any time

- define what happens to non-<video> destinations when a stream with
  "noaccess" is added, or an existing stream has "noaccess" applied to it
  (behaviour equivalent to "muted" or "enabled=false", or something else?)

What do others think?



--
Surveillance is pervasive. Go Dark.

Received on Tuesday, 29 October 2013 23:48:45 UTC