Closed Bug 1295853 Opened 5 years ago Closed 5 years ago

Don't try to download Widevine by default on Tier3 platforms as well

Categories

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

Unspecified
FreeBSD
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox49 --- fixed
firefox50 --- fixed
firefox51 --- fixed

People

(Reporter: jbeich, Unassigned)

References

Details

Attachments

(2 files)

GMP sandboxing is currently unimplemented on Tier3 platforms, so a DRM vulnerability or DRM vendor going rogue may impose greater risk. Let's not test luck by relying on absence of native code.

Otherwise, bug 1289634 comment 0 applies to BSDs well.
Summary: Hide Widevine from about:plugins on Tier3 platforms as well → Don't try to download Widevine by default on Tier3 platforms as well
Comment on attachment 8781826 [details]
Bug 1295853 - Don't enable Widevine by default on Tier3 platforms as well.

https://reviewboard.mozilla.org/r/72150/#review69750

::: browser/app/profile/firefox.js:1358
(Diff revision 1)
>  // On Linux Widevine is visible but disabled by default. This is because
>  // enabling Widevine downloads a proprietary binary, which users on an open
>  // source operating system didn't opt into. The first time a site using EME
>  // is encountered, the user will be prompted to enable EME, whereupon the
>  // EME plugin binary will be downloaded if permission is granted.
> -#ifdef XP_LINUX
> +#if defined(XP_MACOSX) || defined(XP_WIN)

I like your approach here of whitelisting on EME on Mac/Windows, and other platforms being off by default.

And I totally agree that bug 1289634 comment 0 applies to BSDs well.

However, in bug 1294649 I changed it so that we  instead we preffed off "media.eme.enabled" on Linux. 

This change is still on our integration branches, but should merge to mozilla-central tonight.

So please rebase your patch on top of the patches in bug 1294649, and instead set "media.eme.enabled" to false on non Mac/Windows, rather than just turning off the Widevine CDM.

That way, the "Play DRM Content" checkbox in the about:preference#content will be unchecked by default for you, and the CDM won't be downloaded or used (unless the user activates it when prompted).
Comment on attachment 8781826 [details]
Bug 1295853 - Don't enable Widevine by default on Tier3 platforms as well.

https://reviewboard.mozilla.org/r/72150/#review69754

You can also block EME plugins when the sandbox is not enabled using the MOZ_GMP_SANDBOX #ifdef, like so:

https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/GMPParent.cpp#890

Though I'm not sure if that is defined on BSD.

I'll take the rebased patch which sets media.eme.enabled instead of this one.
Actually, I think that on *BSD you're not likely to be served a Widevine CDM URL from which to download a CDM from Mozilla's GMP update servers.

So Firefox is actually not likely to download a Widevine CDM on *BSD by default.

Firefox polls the GMP update server once per day, and we serve a list of URLS from which to download the latest version of each GMP or CDM we support.

For example, Firefox on my MacBook Pro pings our update server on this URL:

https://aus5.mozilla.org/update/3/GMP/49.0/20160802125837/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/beta/Darwin%2015.6.0/default/default/update.xml

Given that, it seems unlikely that you'd actually be able to get a Widevine CDM downloaded and installed on *BSD, unless either you overrode the media.gmp-manager.url pref so that you downloaded the Linux CDM and you can load Linux shared libraries and you're happy doing that without a sandbox.

So you probably don't need to worry about the CDM being downloaded without your users' knowledge. But you would get UI shown about DRM and the Widevine CDM, which would be confusing.

The UI in question would be the Widevine CDM appearing in the Add-ons > Plugins page, and a "Play DRM Content" checkbox appearing in the Preferences > Content page.

So a better solution here for Tier 3 platforms would be for the Mozilla build system to whitelist the platforms for which we by default enable Widevine EME in the build, so that they match the platforms that our update server serves GMP updates to. That is, for Windows, Mac, Linux. If Widevine isn't enabled in the build, the UI doesn't appear at all.

Our build system configuration function which figures out whether to enable Widevine is here:

https://dxr.mozilla.org/mozilla-central/source/toolkit/moz.configure#349

To get it to check the build's target platform against a whitelist, you'd need to pass the "target" variable to that function, but for reasons I don't understand that's hard. I'm not an expert in our build system.

Mike: Is there an better way to whitelist the platforms for which we enable Widevine by default on?
Flags: needinfo?(mh+mozilla)
> That is, for Windows, Mac, Linux.

worse than that: for Windows, Mac, Linux, on x86 and x86_64.

> Mike: Is there an better way to whitelist the platforms for which we enable Widevine by default on?

There is currently no really satisfactory way to do it in python configure, and that's something that will need to change. But even when that becomes possible, that won't solve your immediate problem because you'll need to uplift it. So I'd suggest doing something kind of not really great, but not entirely bad either:

after the option('--enable-eme'), add:

@depends('--enable-eme', target):
def enable_eme(value, target):
    if your_test_on_target:
        return value

then replace '--enable-eme' in @depends following that with enable_eme.

You can even make that a little less bad with an additional:

elif value and value.origin != 'default':
    die('%s is not supported on %s' % (value.format('--enable-eme'), target.alias))
Flags: needinfo?(mh+mozilla)
(In reply to Chris Pearce (:cpearce) from comment #6)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=a9e5f98a7608

This tests Mike's suggestion.

Jan: can you test this patch, and try running `./mach configure` with this patch applied:

https://hg.mozilla.org/try/raw-rev/a9e5f98a7608e8c27a5a8e3c94965274fe6557a3

You should *not* see any lines such as "EME key system WIDEVINE enabled" logged while running `./mach configure`, and we should see that on our tier 1 platforms in the treeherder push results above.
Gah! 'GNU' is not 'Linux' it seams. Trying again:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1e3517c370a

Jan: Can you test this patch instead, the one above has an error:

https://hg.mozilla.org/try/raw-rev/2bfe9b1e367a8265c0510b43a825b8262a0c121c
You'll want to restrict on target.kernel == 'Linux' when target.os == 'GNU'. Or turn the test around and make it test target.kernel in ('Darwin', 'WINNT', 'Linux'), but then that includes iOS and Android, which you can exclude with target.os not in ('Android', 'iOS')
(In reply to Chris Pearce (:cpearce) from comment #3)
> https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/GMPParent.cpp#890

I'm more confused why Windows and OS X allow CDM without GMP sandbox.

(In reply to Chris Pearce (:cpearce) from comment #9)
> https://hg.mozilla.org/try/raw-rev/2bfe9b1e367a8265c0510b43a825b8262a0c121c

It seems to work as intended. Widevine disappears from about:addons (Plugins) and "Play DRM content" disappears from about:preferences#content.

--- objdir/config/autoconf.mk	before
+++ objdir/config/autoconf.mk	after
@@ -132,7 +132,6 @@ MOZ_DOC_INCLUDE_DIRS = ./dist/include ./
 MOZ_DOC_INPUT_DIRS = ./dist/include ./dist/idl
 MOZ_DOC_OUTPUT_DIR = ./dist/docs
 MOZ_EME = 1
-MOZ_EME_MODULES = widevine
 MOZ_ENABLE_GIO = 1
 MOZ_ENABLE_SIGNMAR = 1
 MOZ_ENABLE_SKIA = 1

(In reply to Chris Pearce (:cpearce) from comment #4)
> Given that, it seems unlikely that you'd actually be able to get a Widevine
> CDM downloaded and installed on *BSD, unless either you overrode the
> media.gmp-manager.url pref so that you downloaded the Linux CDM and you can
> load Linux shared libraries and you're happy doing that without a sandbox.

Actually, some FreeBSD users do want CDM similar to Adobe Flash via nspluginwrapper (Linux) or pipelight (Windows). If GMP sandbox isn't standalone but depends on Gecko libs this is going to be tricky.
(In reply to Jan Beich from comment #11)
> (In reply to Chris Pearce (:cpearce) from comment #3)
> > https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/GMPParent.cpp#890
> 
> I'm more confused why Windows and OS X allow CDM without GMP sandbox.

It's enabled by default, and it's always provided by the OS on Mac/Windows.

On Linux, we can't rely on the sandbox being installed or available in older kernels. That's why the check is there for Linux but not other platforms.

> 
> (In reply to Chris Pearce (:cpearce) from comment #9)
> > https://hg.mozilla.org/try/raw-rev/2bfe9b1e367a8265c0510b43a825b8262a0c121c
> 
> It seems to work as intended. Widevine disappears from about:addons
> (Plugins) and "Play DRM content" disappears from about:preferences#content.
> 
> --- objdir/config/autoconf.mk	before
> +++ objdir/config/autoconf.mk	after
> @@ -132,7 +132,6 @@ MOZ_DOC_INCLUDE_DIRS = ./dist/include ./
>  MOZ_DOC_INPUT_DIRS = ./dist/include ./dist/idl
>  MOZ_DOC_OUTPUT_DIR = ./dist/docs
>  MOZ_EME = 1
> -MOZ_EME_MODULES = widevine
>  MOZ_ENABLE_GIO = 1
>  MOZ_ENABLE_SIGNMAR = 1
>  MOZ_ENABLE_SKIA = 1
> 
> (In reply to Chris Pearce (:cpearce) from comment #4)
> > Given that, it seems unlikely that you'd actually be able to get a Widevine
> > CDM downloaded and installed on *BSD, unless either you overrode the
> > media.gmp-manager.url pref so that you downloaded the Linux CDM and you can
> > load Linux shared libraries and you're happy doing that without a sandbox.
> 
> Actually, some FreeBSD users do want CDM similar to Adobe Flash via
> nspluginwrapper (Linux) or pipelight (Windows). If GMP sandbox isn't
> standalone but depends on Gecko libs this is going to be tricky.

Widevine EME can be turned on by having "ac_add_options --enable-eme=+widevine" in your .mozconfig. So then you'd just need to get past the issue of downloading and then loading the Linux/Windows CDM.
  
I thought FreeBSD could execute Linux binaries? Or does that not allow you to load and run a Linux binary into a FreeBSD native code process?

The CDM is a shared library which conforms to Chromium's content_decryption_module.h header:
https://cs.chromium.org/chromium/src/media/cdm/api/content_decryption_module.h

Firefox has an adapter which Adapts the CDM.h interface to a GeckoMediaPlugin interface.
https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/widevine-adapter

The CDM shared library is loaded inside Gecko's plugin-container executable, which is a child process of Firefox, and which is linked against libxul.

I don't know how Pipelight works, but potentially someone could write another adapter which implements the Chromium CDM.h interface which Firefox talks to, and that adapter talks across to a Wine etc process that runs the Windows or Linux plugin.
Comment on attachment 8782265 [details]
Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.

https://reviewboard.mozilla.org/r/72460/#review70482

::: toolkit/moz.configure:359
(Diff revision 1)
>         nargs='*',
>         choices=('adobe','widevine',),
>         default=eme_default,
>         help='Enable support for Encrypted Media Extensions')
>  
>  @depends('--enable-eme', fmp4)

This one should be using the new enable_eme function too.

::: toolkit/moz.configure:374
(Diff revision 1)
> +    if target.kernel in ('Darwin', 'WINNT', 'Linux') and \
> +       target.os not in ('Android', 'iOS') and \
> +       target.cpu in ('x86', 'x86_64'):

I tend to prefer the form:

if (foo and
    bar and
    baz):
Comment on attachment 8782265 [details]
Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.

https://reviewboard.mozilla.org/r/72460/#review70486
Attachment #8782265 - Flags: review?(mh+mozilla)
Comment on attachment 8782265 [details]
Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.

https://reviewboard.mozilla.org/r/72460/#review71938

::: toolkit/moz.configure:369
(Diff revision 2)
> +        target.os not in ('Android', 'iOS') and
> +        target.cpu in ('x86', 'x86_64')):
> +        return value
> +    elif value and value.origin != 'default':
> +        die('%s is not supported on %s' % (value.format('--enable-eme'), target.alias))
> +

You should just `return value` here, and the eme and eme_modules functions won't need modification.

::: toolkit/moz.configure:382
(Diff revision 2)
>  def eme_modules(value):
>      # Theoretically, we could pass `value` directly when it is a
>      # PositiveOptionValue, but somehow, the JSON serialization in configure.py
>      # outputs inconsistent data in some cases when we do (a closing bracket
>      # without an opening one).
>      return list(value) if value else []

You've been bitrotted.
Attachment #8782265 - Flags: review?(mh+mozilla) → review+
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/55ca661e2723
Only enable Widevine on whitelisted Tier-1 build targets. r=glandium
Comment on attachment 8782265 [details]
Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.

Approval Request Comment
[Feature/regressing bug #]: Widevine EME on Linux
[User impact if declined]: Tier 3 builds, such as FreeBSD, NetBSD, OpenBSD, etc, will have Widevine enabled in their UI, even though Widevine won't work there.
[Describe test coverage new/current, TreeHerder]: This is a build only fix.
[Risks and why]: None; this is a build only fix.
[String/UUID change made/needed]: None.
Flags: needinfo?(cpearce)
Attachment #8782265 - Flags: approval-mozilla-beta?
Attachment #8782265 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/57dd53067539
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Comment on attachment 8782265 [details]
Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.

OK to uplift, build only fix.
Attachment #8782265 - Flags: approval-mozilla-beta?
Attachment #8782265 - Flags: approval-mozilla-beta+
Attachment #8782265 - Flags: approval-mozilla-aurora?
Attachment #8782265 - Flags: approval-mozilla-aurora+
Hmm, I still see the following by default in config/autoconf.mk after 57dd53067539 

  MOZ_EME_MODULES = widevine

but --enable-eme=+widevine fails as expected

 ERROR: --enable-eme=widevine is not supported on x86_64-unknown-freebsd12.0
Landry, do you also still see Widevine in about:addons#plugins ? enable_eme() checks against whitelist only to discard it later with |return value| when |value.origin == 'default'|.
Flags: needinfo?(landry)
Comment on attachment 8782265 [details]
Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.

f- per comment 30. 

Not sure why comment 5 morphed comment 0 intent from altering default behavior to blocking undesireable options as well. --enable-eme=+widevine can be useful for emulated plugin-container or custom-built CDM binary.
Attachment #8782265 - Flags: feedback-
(In reply to Jan Beich from comment #34)
> Comment on attachment 8782265 [details]
> Bug 1295853 - Only enable Widevine on whitelisted Tier-1 build targets.
> 
> f- per comment 30. 
> 
> Not sure why comment 5 morphed comment 0 intent from altering default
> behavior to blocking undesireable options as well. --enable-eme=+widevine
> can be useful for emulated plugin-container or custom-built CDM binary.

Maybe for the former, but certainly not the latter. The latter only needs --enable-eme.
... which likely doesn't work. There would need to replace `value` with `len(value)` in the `elif value and value.origin != "default"`

Anyways, please file a followup bug.
Depends on: 1299694
(In reply to Jan Beich from comment #33)
> Landry, do you also still see Widevine in about:addons#plugins ?
> enable_eme() checks against whitelist only to discard it later with |return
> value| when |value.origin == 'default'|.

In which branch ? nightly, release ?
Flags: needinfo?(landry)
Yes i see it in a nightly on OpenBSD.

"Widevine Content Decryption Module provided by Google Inc. will be installed shortly"

same thing for "OpenH264 Video Codec provided by Cisco Systems, Inc."
You need to log in before you can comment on or make changes to this bug.