Do not allow recording the contents of a remote media stream

RESOLVED WONTFIX

Status

()

Core
WebRTC: Audio/Video
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: u459114, Assigned: slee)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webrtc])

(Reporter)

Description

5 years ago
Before we make a decision of allowing recording webrtc audio call, and construct a permission for it, we should disable record a remote media stream in media recorder.
1. If a media stream is a remote media stream, disable recording
2. Not allow a remote media stream as a source node of WebAudio
1. Should we have some preferences to control if partners want to enable this function on their devices?
2. How do we want UA to handle this error? By Security exception?
(Reporter)

Comment 2

5 years ago
(In reply to Randy Lin [:rlin] from comment #1)
> 1. Should we have some preferences to control if partners want to enable
I would say, if they want to to that, they can do whatever they want by change the source code in their repository. But we should not provide a way for them to do it.
> this function on their devices?
> 2. How do we want UA to handle this error? By Security exception?
It need discussion. Possible ways are
a. Do it silently in media module, record blank audio sample.
b. Trow exception while construct a MediaRecorder object with the media stream, or a destination node with that media stream source.
(Reporter)

Updated

5 years ago
Summary: Not allow to recode a remote media stream → Not allow to recode the content of a remote media stream
I'll note that using WebAudio is an expected use-case for WebRTC applications.  Chrome allows WebRTC and WebAudio to be mixed.  However, I don't think many are using the combination yet.  This may change in the near future.  

The framework for what to do/allow here should be developed in the working group(s).  As with anything that touches on telecom law, it's highly location-dependent and hard to map to a browser and independent (and not location-specific) webapps.  For that matter, even a local recording can violate laws since they often state that recording without consent (or without beeps, or some such) of anyone is illegal.  Usually (at least in the US) the onus to comply is on the user, not the equipment provider (or software app).  However, there are many different rules even within the US, and I imagine even more varied across the globe.

Doing this may push off the problem, but will both be somewhat painful as we extend MediaStreams and problematic for WebRTC apps that want to use webaudio for other reasons.  Also, disabling recording and WebAudio will still leave ways an app could bypass the restrictions (video.srcObject = remote_mediastream; local_mediastream = video.captureStreamUntilEnded();)  To block that we'd have to re-invent (or somehow re-use) tainting/cross-domain-restrictions, or consider captureStreamUntilEnded streams to be remote (always or if the source is remote).

needinfo to roc for opinions
Flags: needinfo?(roc)
Summary: Not allow to recode the content of a remote media stream → Do not allow recording the contents of a remote media stream
Whiteboard: [webrtc]
This doesn't make any sense to me. Are we required to prevent an app from getting direct access to any audio (or video?) samples that might be considered a phone call for the purposes of some country's laws? That would be extremely bad.

CJ, what's driving this? Are partners demanding something?

I agree with Randell. This is really a spec issue that needs to be solved by one of the working groups, since it will affect interop.
Flags: needinfo?(roc)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> This doesn't make any sense to me. Are we required to prevent an app from
> getting direct access to any audio (or video?) samples that might be
> considered a phone call for the purposes of some country's laws? That would
> be extremely bad.

It would probably worthwhile to get legal's take on this situation. The phone call considerations you are mentioning motivated the filing of bug 918054 for getUserMedia in general. I'd look at the discussion in that bug to gain an additional perspective from the getUserMedia side and compare it to this bug.

Comment 6

4 years ago
FWIW I agree with Roc. There are going to be a lot of avenues for recording phone calls.
It's on the app to do the right thing.
(Reporter)

Comment 7

4 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> This doesn't make any sense to me. Are we required to prevent an app from
> getting direct access to any audio (or video?) samples that might be
> considered a phone call for the purposes of some country's laws? That would
> be extremely bad.
> 
> CJ, what's driving this? Are partners demanding something?
No, it is only for developer's discussion only.

> I agree with Randell. This is really a spec issue that needs to be solved by
> one of the working groups, since it will affect interop.
understand, and agree. Thanks.
(Reporter)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.