Re: noaccess / peerIdentity as constraints

On 7/10/13 4:40 PM, Jim Barnett wrote:
> 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.

I agree, but I understood Martin's reply as saying the user should not 
be able to know whether the access was of type "noaccess" or not. And 
then it seems pretty useless to me.

I probably got it all wrong - what I am basically asking for is some 
text detailing this out that could be part of the spec.

>
> - 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:43:49 UTC