Re: user permission for recording?

Hi all,

We tackled the recording issue at TokBox about a year ago. We found that 11
states require all parties to know and consent to being recorded, which is
different from consenting to use the camera for a live conversation. The
safest approach is to have a pop-up that specifically requests permissions
for recording. I think allowing developers to freely record without consent
will lead to legal problems for well intentioned developers who are unaware
of the laws they are dealing with. Asking consent for the camera, but not
to record, seems to imply that recording is acceptable when that may not be
the case.

With regards to when to ask permission, we found it was better to ask
before a call was started because it was disruptive to pop up a consent
dialog during the flow of conversation. If an application transitions to
start recording at the same time it connects two people in a call, you may
miss the beginning of the conversation while both people are dealing with
the consent dialogs, and it may complicate syncing multiple recordings if
they start at wildly different times. You may also only want to allow
people to use the application if they are willing to be recorded.

Ben


On Wed, Jan 16, 2013 at 7:30 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

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