W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2013

Re: Proposed new text for noaccess

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 Oct 2013 19:36:58 +0100
Message-ID: <5270004A.5030202@alvestrand.no>
To: public-media-capture@w3.org
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 18:37:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:20 UTC