RE: noaccess / peerIdentity as constraints

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.  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 13:38:15 UTC