Re: Proposed new text for noaccess

On 29 October 2013 11:36, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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?

That is correct, though I would prefer it the application chose the
peeridentity option, rather than the full access option :)

> 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?)

That all sounds good.  (agree on the use of "MAY")

I would add a requirement to include a state diagram for the various
access levels, so that the various options are properly understood. I
found that going through the process of building one was quite
illuminating.

What is perhaps interesting here is the implication that something
other than a call to navigator.getUserMedia can trigger a consent
interaction.  That is, changing constraints can also trigger the
dialog.

> What do others think?

Received on Tuesday, 29 October 2013 18:55:29 UTC