1866638 - Firefox now allows Windows to block DRM-protected content from capture.

Status: REOPENED

(Core :: Audio/Video: Playback, defect, P1)

Description

[limeclipse]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

1. Enable Nvidia Shield GameStream -or- Sunshine Server (what I did).
2. Ensure you're on Firefox 120 or later, and Hardware Acceleration is enabled.
3. Open up media that only works when DRM WideVine plugin is enabled.
4. Connect to the host computer with another device using Moonlight.

Actual results:

Since Firefox 120, guest devices are presented with a black screen while the host can watch just fine. Sunshine Server console spews out the following error:

Warning: Windows is currently blocking DRM-protected content from capture. You may see black regions where this content would be.

Expected results:

Guest devices should be able to watch the DRM protected content just fine.

Workaround:
Disable hardware acceleration.

Advocacy:
The impact of screen sharing through this method is very limited and at most one other remote person can also watch the DRM protected content. It is absolutely not mass-sharing, and more equivalent to watching content with two friends in the same room. DRM should not govern this, or even limit this freedom. It should go back to the way it was before Firefox 120.

Comment 1

[limeclipse]

Issue confirmed not to be present in the Firefox 119.0 release.

Comment 2

[Robert Longson [:longsonr]]

Correct, this is by design per bug 1856520

Comment 3

[limeclipse]

I read through it. It doesn't seem like a bug, but more that it was lobbied to be implemented? Can we get a setting to disable this? It is limiting in freedom, especially in the many jurisdictions around the world where viewing copyrighted content in small circles is allowed.

Comment 4

[Robert Longson [:longsonr]]

See also bug 1819809 and bug 1781122 (that was the Mac implementation of this).

Comment 5

[limeclipse]

Something that was possible before, no longer is. I must now either run Firefox 119, turn off Hardware acceleration as a workaround, consider compiling Firefox myself with the patch patched out, or NOP out the jump in the binaries.

I understand Google/Apple would want to prohibit the capture of DRM content in their Chrome/Safari browser due to their partners. But Mozilla should have no such obligation. So my question is... Why?

Comment 6

[Alastor Wu [:alwu]]

Sotaro, I know we want to prevent DRM video from capturing. I would like to reopen this bug for more discussion, because the remote sharing is an important feature for remote playback, breaking that seems also affecting user experience a lot for our users.

Ashley, does the open screen thing you're working on mention anything about DRM playback? I wonder if we could have a standard way to allow DRM playback to project to the remote devices, but still keep it away from being captured.

Comment 7

[Jim Mathies [:jimm]]

(In reply to Alastor Wu [:alwu] from comment #6)

Sotaro, I know we want to prevent DRM video from capturing. I would like to reopen this bug for more discussion, because the remote sharing is an important feature for remote playback, breaking that seems also affecting user experience a lot for our users.

Ashley, does the open screen thing you're working on mention anything about DRM playback? I wonder if we could have a standard way to allow DRM playback to project to the remote devices, but still keep it away from being captured.

There is a way to do this through flinging, which involves handing the drm protected stream off too the chromecast device for decryption and playback.

Comment 8

[Jim Mathies [:jimm]]

We'll keep this open to document the known workaround. At this point though we do not plan on changing the current implementation, which matches behavior in other browsers.

Comment 9

[limeclipse]

(In reply to Jim Mathies [:jimm] from comment #8)

We'll keep this open to document the known workaround. At this point though we do not plan on changing the current implementation, which matches behavior in other browsers.

This stance gets in the way of a couple of use cases.

1. A person utilizing remote sharing across their own devices, must now exit remote sharing, in order to view the DRM content. The obvious negative impact on user experiences are:

a) Users that have a powerful desktop machine at home, and utilize remote sharing to work via a weaker mobile device, now has a downside. Sometimes, these powerful desktop machines may not even have a monitor themselves and are meant solely for Remote Sharing, and utilize a virtual monitor or dummy cable to achieve this.

b) Users that use remote sharing as a form of remote control for media on the bigger screen no longer can. I must personally now get out of bed in order to control the DRM content on the media PC that has a big screen.

d) Users opting to use remote sharing over the use of a VPN when on holiday are negatively impacted. Especially because setting up a home VPN server requires more knowledge over setting up remote sharing.

2. Two people that utilize remote sharing as a means to watch media together, can no longer do so.

a) Live streamed content is never in sync when watching separately. Especially if that stream is RTMP or other slow protocols, the difference can easily be up to half a minute, depending on the network routing and CDN nodes used. Watching the same content from the same device ensures both people see the content pretty much at the same time (negligible millisecond delays).

b) The experience of watching videos together from one machine is a lot smoother. It cuts out a significant amount of communication and link sharing, and both users have control over the video (play, pause, seek, next, prev).

c) Additionally (for both videos and live streams), due to differences in CPU clocks, videos can play faster or slower on different machines: I personally have witnessed about a four second difference after 10 minutes of watching on my laptop vs. desktop.

The desire to match behavior with other browsers should be reconsidered for this issue. I also understand the wishes of media partners of the other browsers to prevent the capturing of their copyrighted content, but these measures are going too far and are getting in the way of legitimate uses. I would kindly ask for reconsideration of the current implementation and to find a different way.

Comment 11

[matt]

(In reply to limeclipse from comment #9)

(In reply to Jim Mathies [:jimm] from comment #8)

We'll keep this open to document the known workaround. At this point though we do not plan on changing the current implementation, which matches behavior in other browsers.

This stance gets in the way of a couple of use cases.

1. A person utilizing remote sharing across their own devices, must now exit remote sharing, in order to view the DRM content. The obvious negative impact on user experiences are:

a) Users that have a powerful desktop machine at home, and utilize remote sharing to work via a weaker mobile device, now has a downside. Sometimes, these powerful desktop machines may not even have a monitor themselves and are meant solely for Remote Sharing, and utilize a virtual monitor or dummy cable to achieve this.

b) Users that use remote sharing as a form of remote control for media on the bigger screen no longer can. I must personally now get out of bed in order to control the DRM content on the media PC that has a big screen.

d) Users opting to use remote sharing over the use of a VPN when on holiday are negatively impacted. Especially because setting up a home VPN server requires more knowledge over setting up remote sharing.

2. Two people that utilize remote sharing as a means to watch media together, can no longer do so.

a) Live streamed content is never in sync when watching separately. Especially if that stream is RTMP or other slow protocols, the difference can easily be up to half a minute, depending on the network routing and CDN nodes used. Watching the same content from the same device ensures both people see the content pretty much at the same time (negligible millisecond delays).

b) The experience of watching videos together from one machine is a lot smoother. It cuts out a significant amount of communication and link sharing, and both users have control over the video (play, pause, seek, next, prev).

c) Additionally (for both videos and live streams), due to differences in CPU clocks, videos can play faster or slower on different machines: I personally have witnessed about a four second difference after 10 minutes of watching on my laptop vs. desktop.

The desire to match behavior with other browsers should be reconsidered for this issue. I also understand the wishes of media partners of the other browsers to prevent the capturing of their copyrighted content, but these measures are going too far and are getting in the way of legitimate uses. I would kindly ask for reconsideration of the current implementation and to find a different way.

FWIW, this functionality still works for me in Chromium-based browsers. At least, consuming DRM-locked streamed content (Netflix, Hulu, etc.) works in Chrome, Brave, and Opera. It sucks to have to use something other than Firefox for this purpose, but so long as those browsers still offer this basic functionality, and so long as Mozilla kowtows to these draconian DRM measures, it's what I'm forced to do.