#837091 firefox-esr: EME DRM extention present and enabled

Package:
firefox-esr
Source:
firefox-esr
Description:
Mozilla Firefox web browser - Extended Support Release (ESR)
Submitter:
Tjeerd Pinkert
Date:
2023-02-22 20:42:04 UTC
Severity:
serious
Tags:
#837091#5
Date:
2016-09-08 18:14:28 UTC
From:
To:
Dear Maintainer,

after reading up a bit (late(ly)) on the W3C EME proposed standard for
embedding of DRM managed content in web pages, I decided to have a
look if it is present in the firefox browser. about:config shows the
following:

media.eme.apiVisible;true
media.eme.enabled;true

I think the presence of code that requires closed source components to
function, might violate the DFSG for the main section? On the other
hand, no package relation is available in the non-free section as far
as I see that is actively depended on. If a decision has been taken on
this already, then please close.

I have not found this in the system for the firefox-esr package, I did
find bug 748342 (iceweasel), and the upstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1011459
and a discussion at:
http://forums.debian.net/viewtopic.php?f=20&t=114687

First of all I disabled the function by setting the above values to:
false.

It would be better to have support for EME removed altogether to be free
of any possible legal issues arising from DRM enabled software.

Yours,


Tjeerd Pinkert


P.S. yes I know, having flash installed as a plugin is as bad as
having EME enabled... Trying to block as much as possible though...

#837091#12
Date:
2017-05-27 12:47:45 UTC
From:
To:
[...]

I don't see a freeness problem here.

Firefox with the EME API enabled at compile time, but no CDM (DRM
implementation) installed, is presumably no less functional than Firefox
with the EME API disabled at compile time - so the CDM is not a
dependency, because Firefox without a CDM is a perfectly acceptable web
browser (just missing an optional feature). If we shipped CDMs in
non-free, I don't think Firefox would have a stronger relationship to
them than Suggests (or more likely, the CDMs would declare an Enhances
relationship on Firefox, which means the same thing). Packages in main
are allowed to have Suggests on non-free or even not-in-Debian packages,
just not (Pre-)Depends or Recommends.

Free CDMs do seem to exist -
https://github.com/fraunhoferfokus/open-content-decryption-module is one
example. It is fairly likely that content publishers will not actually
*use* those CDMs, but that's between you and the content providers whose
products you choose to buy. So from a freeness point of view, this
doesn't seem any worse than any other plugin interface that can accept
both Free and non-Free plugins - for example glibc NSS, PAM, GStreamer,
Firefox NPAPI, kernel modules, and OpenGL/EGL/Vulkan drivers.

I understand your desire to avoid DRM, but I don't think opening
release-critical bugs requesting that features are removed from our
builds of Firefox is an appropriate way to go about it.

In particular, I believe having the Flash NPAPI plugin installed means
your copy of Firefox already loads a DRM implementation, because there's
one in Flash. You might as well use one that is better-sandboxed, which
is the purpose of EME.

    S

#837091#17
Date:
2017-12-17 12:38:41 UTC
From:
To:
Hello!

Complete removing EME support from Firefox can be undesired for some
users, but it would be a reasonable compromise to disable it by default
by adding

    // Disable EME.
    pref("media.eme.apiVisible", false);
    pref("media.eme.enabled", false);

to /etc/firefox-esr/firefox-esr.js

Please consider this solution.

#837091#22
Date:
2018-09-18 01:08:30 UTC
From:
To:
Using the firefox-esr package currently in stable, visiting any page with EME media causes a "you must enable DRM" nag bar to be displayed with an "enable DRM" button. A single click enables DRM and causes the proprietary wildvine plugin to be downloaded, installed, and executed. There is no setting that disables this nag box or prevents it from installing the plugin.

Example page: https://bitmovin.com/demos/drm

There's no way this behavior is appropriate for a package in "main".

#837091#27
Date:
2023-02-22 20:38:56 UTC
From:
To:
Control: severity -1 normal

ACK, so let's downgrade the severity.

Cheers