Re: user permission for recording?

On 2013-01-16 08:45, Adam Bergkvist wrote:
> 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.

I don't think we need user consent. Even without the recording API the 
UA could ship (via a PeerConnection) the media off to a server which 
records.

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

I think this is a good idea. I guess it would not only help spec writers 
and app developers, but also implementers.

>
> /Adam
>
>

Received on Wednesday, 16 January 2013 13:45:43 UTC