W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2013

RE: user permission for recording?

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Wed, 16 Jan 2013 15:30:24 +0000
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, Travis Leithead <travis.leithead@microsoft.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810180E6@GENSJZMBX03.msg.int.genesyslab.com>
I like the idea of a Constrainable interface.  It saves (me) work and would ensure consistency.  

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Wednesday, January 16, 2013 2:45 AM
To: Travis Leithead
Cc: Jim Barnett; public-media-capture@w3.org
Subject: Re: user permission for recording?


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.

Received on Wednesday, 16 January 2013 15:30:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:38 UTC