RE: noaccess / peerIdentity as constraints

Stefan,
  I'm probably confused, but I assume that if 'noaccess' is set as a constraint passed in to gUM, then it is the UA's  responsibility not to allow the application to touch the media.  So the question is how the UA informs the user that the 'noaccess' constraint has been requested.  However, given that the constraint has been set, the user can trust the UA to enforce it.

- Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Wednesday, July 10, 2013 10:35 AM
To: Jim Barnett
Cc: Martin Thomson; Dominique Hazael-Massieux; public-media-capture@w3.org
Subject: Re: noaccess / peerIdentity as constraints

On 7/10/13 3:37 PM, Jim Barnett wrote:
> I thought that these constraints had the effect of setting the origin 
> for the purpose of cross-origin constraints.  In that case, the 
> constraints are enforced by the UA.  'noaccess' would mean that the UA 
> will not allow the application to touch the  media except to display 
> it locally or to send it via a PeerConnectionn.  So there's no need to 
> trust the application.

This is where I get lost. If the user can't verify that all media generated is put as "noaccess", then the user would have to trust the app to use that constraint - right? And then the user could just as well trust the app to not record (or do anything nasty) with the media anyway (so "noaccess" would not be needed).

> It's hard to constrain what the
> remote side can do with the media, but if the remote UA treats the 
> media as having the originating UA as the origin, then cross origin 
> constraints will keep the remote app from touching the media (except 
> to display it).
>
> - Jim
>
> -----Original Message----- From: Stefan Håkansson LK 
> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Wednesday, July 10,
> 2013 2:33 AM To: Martin Thomson Cc: Dominique Hazael-Massieux; 
> public-media-capture@w3.org Subject: Re: noaccess / peerIdentity as 
> constraints
>
> On 7/9/13 8:39 PM, Martin Thomson wrote:
>> On 9 July 2013 00:48, Stefan Håkansson LK 
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> * Are noaccess streams intended for hair checks only?
>>
>> No, the intent is that they can be sent to others.  The 'no access' 
>> part applies to the web application only.
>
> OK, I think I start to get this: the main functionality is to ensure 
> that a remote application can't touch the media. Right?
>
> For the local use "noaccess" does not make a difference. The user 
> can't in any way verify that all access to media is limited, the app 
> does not get a shortcut to access microphone and camera. Basically the 
> user has to trust the application used to apply "noaccess", and that 
> would protect the media from being misused at any remote receiver.
>
>
>
> Stefan
>
>>
>>> * Should there be some kind of indication (in the browser
>>> chrome) that all access to cameras/microphones is of type 
>>> "noaccess"?
>>
>> The indicators would be roughly the same as normal: yes the camera is 
>> on, and (if sending) the identity of the receiver of that stream.
>>
>>> * Would "noaccess" mean that the user would not have to give consent 
>>> (since the app can do no harm with the media) to accessing input 
>>> devices?
>>
>> Consent would still be required.
>>
>
>
>
>

Received on Wednesday, 10 July 2013 14:40:28 UTC