CDM still downloaded after opt out
Categories
(Core :: Audio/Video: GMP, defect, P3)
Tracking
()
People
(Reporter: b7798899, Unassigned)
References
Details
Attachments
(1 file)
|
56.29 KB,
image/png
|
Details |
about:config gmp entries
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- Uncheck "Play DRM-controlled content" in preferences
- Wait about a day. (the download happens around noon each day in CEST timezone.)
- widevine zip is downloaded from redirector.gvt1.com
Actual results:
widevine download
Expected results:
no spurious downloads of binaries
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
Bryce, is this something you could do a first pass on triaging?
b7798899 has disabled their account, and I assume the email is a throw away.
If they happen to check back, it would be useful to know the following:
- What mechanism did you use to verify that another download of the CDM took place?
- Could you please navigate to
about:configand copy the info there to the clipboard and paste it into this bug?
Hi,
- The zip files were left in /tmp
- Which key from about:config do you need? (attached gmp entries)
Apologies, I meant about:support.
Are you sure it's Firefox placing the zip files in tmp? I believe that the code to download the CDM should save it directly into the current user's Firefox profile directory before extracting it (then remove the temp file).
|
||
Comment 5•5 years ago
|
||
I have a setup where firefox runs under its own user (and that user is not used for anything else), and this user owned the files in tmp, so I'm pretty sure.
about:support has a bunch of unique identfiers which I'd rather not disclose, what part are you interested in?
The media* prefs under important modified prefs. The location of the profile dir would also be useful.
|
|
||
Comment 7•5 years ago
|
||
media.decoder-doctor.MediaCannotInitializePulseAudio.formats *
media.getusermedia.screensharing.allowed_domains
media.gmp-gmpopenh264.autoupdate false
media.gmp-gmpopenh264.enabled false
media.gmp-manager.buildID 20190719015109
media.gmp-widevinecdm.enabled false
media.gmp.storage.version.observed 1
media.peerconnection.enabled false
There's no media.gmp-manager.lastCheck or media.gmp-widevinecdm.lastUpdate? I'd expect to see these if Firefox is fetching the CDM. If you delete the file from /tmp do you see it return?
|
|
||
Comment 9•5 years ago
|
||
No such keys in about:config.
I've been blocking the server since the discovery. But I unblocked it now, let's see if there'll be a file tomorrow.
|
|
||
Comment 11•5 years ago
|
||
The archive is back:
768ffe64a8efca991fce37d4cf35eb15b1cf2fdb2fa4773278a1bfce1e620046 /tmp/tmpaddon
Modification time: 15:56 CEST (it's little later than usual)
|
|
||
Comment 12•5 years ago
|
||
Actually, as I remember, if the archive already exists, the next day it will name the new one as /tmp/tmpaddon-0, /tmp/tmpaddon-1, etc.
|
|
||
Comment 13•5 years ago
|
||
And now that I do the googling I should've done before, found:
https://bugzilla.mozilla.org/show_bug.cgi?id=1385303
If the other bug were fixed, I probably wouldn't have noticed this one.
I hope there are no other binaries firefox downloads... Or better yet, just make one flag, that stops all this https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections (Which doesn't even include this download, ew.)
|
|
||
Comment 14•5 years ago
|
||
I forgot to answer what the location of the profile dir was: it's on the home partition, in a subdirectory of my main user's homedir.
|
||
Comment 15•4 years ago
|
||
bug 1385303 is fixed now. Does that mean this isn't an issue anymore?
Setting media.eme.enabled to false (which is what preferences does) definitely turns off downloaded EME.
|
||
Updated•2 years ago
|
Description
•