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

Re: user permission for recording?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 16 Jan 2013 12:39:01 +0100
Message-ID: <50F69155.1010002@alvestrand.no>
To: public-media-capture@w3.org
On 01/15/2013 09:25 PM, Jim Barnett wrote:
>
> We haven’t discussed whether user consent is required for recording.   
> In general, I would think that users would want to know when they are 
> being recorded and would want to be able to block recording.  (Of 
> course, the user can’t be guaranteed that the other end isn’t 
> recording the call, but that’s the case on phone calls today.)
>
> So:
>
> 1. Should user consent be required for recording?
>
> 2.If so, when should it be given? As part of the initial call to gUM?  
> When recording actually starts? (via another call to gUM or in the 
> Recorder constructor?).
>
I think this ties in with the thinking we had earlier about the tying of 
identity with getUserMedia - if we want the ability for getUserMedia (or 
other means of producing a MediaStream) to produce a stream that is only 
authorized for certain destinations, then we should think about whether 
"local recording" is one of the possible destinations to authorize for.

I don't see at the moment how to apply this logic to a remote media 
stream - when it is sent from the other side, it's authorized to an 
identity - but we haven't made any way to encode restrictions on what 
the recipient can do with the media stream once he has it.

My default position would be "no, user consent is not required".

> Also, we have identified 3 settable parameters for recording so far:  
> the Mime type, video height, and video width.  None of these function 
> as constraints that can be used to select the appropriate ‘device’,  
> so does it make sense to use the constraint structure to specify them? 
> Wouldn’t it be simpler to let them be settable attributes of the 
> Recorder class?  (We would still need a getCapabilities call to 
> determine what the legal values are, and we wouldn’t allow the values 
> to be changed while recording was going on.)
>
I would prefer to keep a constraints structure - we can easily need to 
do things like bitrate limitations, quality controls and so on; just 
dump the command line for any popular video encoder tool to get plenty 
of ideas.

Height and width may also be useful to specify as constraints, in the 
case where the recording codec functions better with slight tunings of 
the parameters. I don't see any huge disadvantages in doing so.
Received on Wednesday, 16 January 2013 11:39:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:03 GMT