Open Bug 1634894 Opened 4 years ago Updated 2 years ago

widevine CDM downloaded despite media.eme.enabled being set to false

Categories

(Core :: Audio/Video: GMP, defect, P3)

68 Branch
defect

Tracking

()

Tracking Status
firefox-esr68 --- ?
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fix-optional
firefox78 --- ?

People

(Reporter: n+moozilaboogzila, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:4.5) Goanna/20170101 PaleMoon/28.9.2

Steps to reproduce:

In Firefox 68.7.0esr on a Debian GNU/Linux.

Disabled a "Play DRM-controlled content" in "General" preferences.

Actual results:

DRM related binary libraries are still being downloaded. (openh264 and widevine-cdm libraries were downloaded in my case)

Expected results:

Firefox should not try to download binary DRM libraries, when DRM is disabled in preferences.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Can you navigate to about:support and copy the information from that page to here using one of the buttons provided?

How are you checking that the binaries are downloaded?

Assignee: nobody → bvandyk
Severity: normal → S3
Flags: needinfo?(n+moozilaboogzila)

Hi,
It should be default firefox-esr install on debian 10.3.

I installed firefox-esr, went offline, tried to disable all possible network interaction settings (inspiration from http://brmlab.cz/user/jenda/spyzilla).

Then I set proxy to local OWASP ZAP proxy, imported certificate to firefox, and browsed to some webpage, to see if anything survived.

I left browser running over the night, and found two .so DRM libraries downloaded in the proxy history. (checksums seems to be correct:)

about:support attached. (but please note, that I already hard-killed DRM downloading in my about:config by removing URL paths to libraries)

Flags: needinfo?(n+moozilaboogzila)
Attached file log_ffesr_debian10.txt

Thanks. Did/do you see any of the files being persisted in /tmp/tmpaddon or your user profile dir under gmp-* dirs?

Can you confirm that the media.eme.enabled is set to false?

Moving to toolkit as it sounds like it's downloading the Widevine addon even when EME is off.

Component: Audio/Video: Playback → General
Product: Core → Toolkit
See Also: → 1573650

On further thought, are you sure that the files you noticed being downloaded were .so files? Firefox should download an archive when fetching those libs, rather than the .so files.

Flags: needinfo?(n+moozilaboogzila)

Hi,
I found two files in tmp:
/tmp/tmpaddon and /tmp/tmpaddon-XXX (where XXX is some id)
The files are in fact both downloaded zip archives, openh264 and widevine-cdn.
Inside a zip archives, there are .so libraries, and some license files/manifest.

I can confirm that media.eme.ebabled is set to false.

The downloaded files were zip archives, libraries were packed inside, sorry for confusing description.

Flags: needinfo?(n+moozilaboogzila)

Thanks for confirming that. Could you also check in your profile dir (you can find the location by navigating to about:support) for gmp-* dirs and let me know if it looks like the archives were extracted there?


For other moz folks:

Poking around I wonder if we need to look at the paths that update via https://searchfox.org/mozilla-central/rev/dc4560dcaafd79375b9411fdbbaaebb0a59a93ac/toolkit/mozapps/extensions/internal/GMPProvider.jsm#362 -- it seems they lack some of the pref checks used in other GMP update paths.

Searching in a user profile, i did not found any gmp-related files. (filename, filesize, ...)

Note, with DRM off we wouldn't expect the Widevine file to be downloaded. OpenH264 isn't drm related, so it may still be processed, but can be stopped via other prefs.

To confirm, Play DRM-controlled content" in "General" preferences was off when the widevine download was done. I.e. it's not the case that the file in /tmp may have been downloaded and not removed from before that option was set?

Assignee: bvandyk → nobody

I can confirm, that /tmp files are related to the download.
( 1. I was running ff-esr disconnected from internet when setting preferences.
2. Timestamps of /tmp files seems to match times at the proxy
3. Even if I was wrong "somehow", I have a proxy log catching downloads happening, which would be still a bug )

I can confirm, that "Play DRM-controlled content" in "General" preferences was turned off, when download occurred.

Component: General → Audio/Video: GMP
Product: Toolkit → Core

The code that governs the download of these plugins lives in toolkit, are you sure this should be in the GMP component?

Flags: needinfo?(florian)

(In reply to Bryce Seager van Dyk (:bryce) from comment #12)

The code that governs the download of these plugins lives in toolkit, are you sure this should be in the GMP component?

I'm not sure, no. But I felt this bug is more likely to receive attention in the GMP component than in Toolkit::General. Is there another more specific Toolkit component that would be a good fit?

Flags: needinfo?(florian)

(In reply to Florian Quèze [:florian] from comment #13)

(In reply to Bryce Seager van Dyk (:bryce) from comment #12)

The code that governs the download of these plugins lives in toolkit, are you sure this should be in the GMP component?

I'm not sure, no. But I felt this bug is more likely to receive attention in the GMP component than in Toolkit::General. Is there another more specific Toolkit component that would be a good fit?

I'm not sure. These kinds of bugs seem to be shared across Core: AV GMP, Toolkit: General, and Core: Plugins. The reason I moved this to toolkit is I could use help looking at the installation code paths in the toolkit code (like the one in comment 5) . I've walked the code and attempted to repro myself, but have had no luck so far.

Without clear steps or an idea of how this is happening, it's not clear how to make progress here. I tried to reproduce this and could not, as did Bryce.

If you set extensions.logging.enabled to true, and run an add-on update cycle (reset/clear prefs app.update.lastUpdateTime.addon-background-update-timer and media.gmp-manager.lastCheck in about:config, then restart the browser ) , can you copy/paste the entirety of what gets logged to the browser console (not the regular devtools console, the browser one - open with ctrl-shift-j on Linux) , and confirm that that redownloads the file from gvt to tmp?

Flags: needinfo?(n+moozilaboogzila)
Summary: DRM preferences ignored → widevine CDM downloaded despite media.eme.enabled being set to false

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bryce, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(n+moozilaboogzila) → needinfo?(brycebugemail)
Flags: needinfo?(brycebugemail) → needinfo?(jmathies)
Severity: S3 → S4
Flags: needinfo?(jmathies)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: