RE: Clarification on media capture split between WebRTC and DAP

On 16 augusti 2011 12:10, Rob Manson wrote:

> +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.

I think it will be tricky to have a MediaStream that's restricted to
local usage only, and still be useful. It wouldn't be sufficient to
prevent the stream from being added to a PeerConnection. E.g. we would
have to disable the MediaStreamRecorder as well as ability to render
the video in a canvas because once recorded clips or video frames have
been extracted from the stream it's quite hard to prevent them from
being transmitted somewhere. I.e. once the application can access the
data there's no reasonable way to guarantee local usage only. Then
there wouldn't be too many interesting usecases left.

This has also been discussed in an early device element thread on the
DAP list.
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0197.html

/Adam

Received on Tuesday, 16 August 2011 12:38:08 UTC