W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2013

Re: noaccess / peerIdentity as constraints

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 10 Jul 2013 14:35:21 +0000
To: Jim Barnett <Jim.Barnett@genesyslab.com>
CC: Martin Thomson <martin.thomson@gmail.com>, Dominique Hazael-Massieux <dom@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30E23B@ESESSMB209.ericsson.se>
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:35:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC