- From: Rob Manson <roBman@mob-labs.com>
- Date: Tue, 16 Aug 2011 20:10:18 +1000
- To: Rich Tibbett <richt@opera.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
+1 for finer grained separate authorisation between streaming to a remote server vs. streaming into a <video> or <audio> tag. This is essential. It's also important for Augmented Reality that audio can be handled in this way too...not just the visual aspect of video (e.g. images). roBman On Tue, 2011-08-16 at 11:21 +0200, Rich Tibbett wrote: > Having said that, providing a stream of the camera to a web page is > not the same as authorizing that web page to stream camera content to > a remote server. I'd prefer to keep both aspects separate in the user > authorization model. For example, providing the camera to a web page > could be used to enable Augmented Reality experiences without the user > having authorized any Streaming aspects. Any streaming in that use > case would be a serious violation of that user's privacy. > > > > > I would also argue that both of these points apply just as much to > video > > recording as to still image capture, since many platforms have > native > > camcorder UIs that expose device-appropriate functionality, > > It may be possible to tweak the settings of the Stream via the UA's > interfaces once it has been provided to a web page. However, that > would be out of scope of defining an API, IMO. > > > and > > finer-grained authorization is desirable in both cases. > > Since one of the use cases is to stream the camera only to the web > page for e.g. AR purposes I agree there should be a separate > authorization to stream that data to a remote server if and when that > is required.
Received on Tuesday, 16 August 2011 10:10:47 UTC