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 06:25:21 UTC