- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 9 Jul 2013 07:48:50 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Dominique Hazael-Massieux <dom@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 7/5/13 6:57 PM, Martin Thomson wrote: > On 5 July 2013 01:26, Dominique Hazael-Massieux <dom@w3.org> wrote: >> Based on my understanding, we want them as constraints for the whole >> MediaStream. > > MediaStreams are a terrible place for this sort of thing, but they are > better than the alternative ;) > > As long as this is the direction, then I think that there needs to be > some text regarding how the track that comprise a noaccess- or > peerIdentity -constrained stream can be used. > > Primarily, this relates to adding the track to other MediaStreams. A > flat prohibition seems appropriate here. I considered the option > where you could move tracks between streams that had identical access > restrictions, but decided that noaccess isn't that simple. I agree that prohibition seems like the logical alternative. I also think we need more text on explaining how it is supposed to work. E.g.: * Are noaccess streams intended for hair checks only? * Should there be some kind of indication (in the browser chrome) that all access to cameras/microphones is of type "noaccess"? * 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? etc. Stefan > >
Received on Tuesday, 9 July 2013 07:49:15 UTC