Re: user permission for recording?

Hi

On 2013-01-16 01:08, Travis Leithead wrote:
> I'm still thinking about the user consent question.

I think rendering frames on a canvas and grabbing them is as big of a 
privacy issue as recording a stream with the recorder. So if we require 
consent for one type of frame grabbing, we should do it for all.

If I remember correctly, we talked about "tainted" streams. I guess we 
could say that such streams are not recordable. The same goes for a 
stream that has been created and associated with a specific receiver 
identity.

> For the settable parameters, I think it makes sense to follow the
> constraints pattern in the other spec—readable properties on the
> Recorder with a mechanism for overlaying constraints on top of that.

I agree. We should use the pattern we've worked out consistently 
whenever we have settings of this kind (i.e. non-trivial settings that 
may not be supported, may fail or may not be combinable with other 
settings). It's not the easiest pattern for developers to learn so they 
should only have to learn one variant of it.

In v6 of the settings proposal the methods: getConstraints(), 
setConstraints(), applyConstraints(), and the rest of the constraints 
methods belong to a "partial interface MediaStreamTrack". Perhaps we 
should extract those methods into a separate interface 
"Constrainable"/"ConstraintTarget"/"or something". That interface could 
be implemented by MediaStreamTrack objects, the recorder, the dtmf 
sender, the transport handler and any other objects that needs this 
functionality.

So an object using this would still list all its constraints as 
attributes, but the functionality to modify them would be imported by a 
single "InterfaceName implements Constrainable" statement. I think it 
would save us a lot of work not having to duplicate spec text (and code) 
and make sure the constraint mechanism stays consistent for all objects 
that implement it.

/Adam

Received on Wednesday, 16 January 2013 07:45:49 UTC