RE: noaccess / peerIdentity as constraints

The no-access constraint is starting to sound a lot like the peer-identity constraint that was proposed a while back. If Stefan is right and a no-access stream can only be sent to an identified peer, then the only difference is that with a peer-identity constraint the identity of the peer is specified at the time the constraint is applied, while with no-access the peer is identified later.  

So 1) is my understanding correct  2) if it is, will we need a separate peer-identity constraint?

- Jim

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

On 2013-07-10 18:28, Martin Thomson wrote:
> On 9 July 2013 23:33, Stefan Håkansson LK 
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 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.
>
> No for local use, "noaccess" makes a very big difference.  Without it, 
> the JavaScript provided by the application can do anything it likes 
> with the data.  With it, the only option available is to render it in 
> a frame that consequently becomes inaccessible to the script.

I get that, but if the end user can not verify that the app has only "noaccess" access to the media, this has little value. The app can just omit the "noaccess" constraint and do whatever it wants - the user would not know.

>
> Of course, that has no intrinsic value until the stream transits the network.

Right.

>
> The constraints around this are such that a remote party who receives 
> the stream and the appropriate supporting signaling can make 
> assertions about where the data came from.  That is, the receiver of 
> such a stream, if they also protect the stream from modification (I 
> believe that we need to require this behavior, but can't find the 
> specific text that says as much...I'll raise an issue), can inform the 
> user with some confidence that the stream has not been modified by the 
> application.

I agree fully to this part. And I assume that the condition on sending a "noaccess" stream to a remote peer is that Identity of the remote user is asserted and presented to the user - otherwise the (malicious) local app could also sent it to another peer (using a separate PeerConnection) where it is e.g. recorded.

>

Received on Thursday, 11 July 2013 14:28:40 UTC