widevine CDM downloaded despite media.eme.enabled being set to false
Categories
(Core :: Audio/Video: GMP, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | ? |
firefox75 | --- | wontfix |
firefox76 | --- | wontfix |
firefox77 | --- | fix-optional |
firefox78 | --- | ? |
People
(Reporter: n+moozilaboogzila, Unassigned)
References
Details
Attachments
(1 file)
20.37 KB,
application/octet-stream
|
Details |
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.
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
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?
Reporter | ||
Comment 3•4 years ago
|
||
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)
Reporter | ||
Comment 4•4 years ago
|
||
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.
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.
Reporter | ||
Comment 7•4 years ago
|
||
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.
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.
Reporter | ||
Comment 9•4 years ago
|
||
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?
Reporter | ||
Comment 11•4 years ago
|
||
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.
Updated•4 years ago
|
The code that governs the download of these plugins lives in toolkit, are you sure this should be in the GMP component?
Comment 13•4 years ago
|
||
(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?
(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.
Comment 15•4 years ago
|
||
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?
Comment 16•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 17•2 years ago
|
||
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.
![]() |
||
Updated•2 years ago
|
Description
•