STR:

1. On Ubuntu 19.10, start Firefox with privacy.resistFingerprinting enabled.
2. Go to the Netflix test pattern (no account required). EDIT: Must be logged out.
3. Enable DRM, wait for it to install.
4. Play video.

Black screen with no video playback.

Useragent before regression: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Useragent after regression: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0

Workaround is to install an extension that allows changing the useragent to Linux.

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8e746f670f430ceb0cb85fa8eebfe97cbe42ff01&tochange=ed68c008e5d8db0940a1fbc31bfc24efccba6c26

Regressed by Bug 1509829.

Useragent before regression: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Useragent after regression: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0

This looks strange, I think it's outdated. With Firefox >= 68 you should get
Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0.

Netflix mentions on their help page [1] that they require Firefox >= 65, which is of course greater than the version number in your user agent. I also did a quick test with Firefox 72 (from Arch Linux, not the official Mozilla build) and it works for me.

[1] https://help.netflix.com/en/node/23742

Those useragents are immediately before and after the regression on 2019-02-28 when Firefox 60 was the ESR. Video playback works with that Nightly build while reporting as Firefox 60 as long as the OS is reported as Linux.

Current useragent with RFP on 72 and Nightly 74 (official Mozilla builds) is Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0 and video playback does not work unless the reported OS is changed to Linux.

Browser Console output with RFP spoofed useragent:

navigator.requestMediaKeySystemAccess promise rejected 0x80530009 'Key system is unsupported'

Okay, now I can reproduce this bug with a fresh profile and Firefox 72 (official Mozilla build). But when I log in, I can play videos. Have you tried with an account?

Just tried it with an account and it works so this appears to be limited to videos accessible when logged out which is not many, the test pattern is the only one I can find publicly indexed. The video player seems to be the same version when logged in and out (cadmium-playercore-6.0020.327.051.js) but the user interface is arranged differently when logged out suggesting a different treatment.

Tom, do we have a policy around resist fingerprinting and bustages such as this?

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

Tom, do we have a policy around resist fingerprinting and bustages such as this?

We keep them open to track them, but most we don't really have any real expectation of being able to fix or find a way to mitigate. If you want to assign it out of your Component; that's fine.

some update to date information

It's not the version (at least not anymore), it is the spoofing as windows in the OS in the HTTP Header (when on Mac or Linux)

• you can read some of the hi-jinks going on in here and the initial mis-diagnosis re v100- https://github.com/webcompat/web-bugs/issues/82913

This also happens with Disney+

when I try to login to https://soundcloud.com/ while having privacy.resistFingerprinting enabled, I get a message saying "Our robots think you are a robot. " and the Google reCaptcha fails to load, preventing me from logging in.

from my testing:

• if I leave RFP enabled and I spoof the user agent to Firefox 99 using an extension the captcha is loaded and I can login.
• I am on macOS but it doesn't matter if I spoof to Firefox 99 Mac or Win. spoofing to Firefox ESR on Windows did not help, so likely it isn't tightly related to the HTTP-header spoofing.
• this only happens when RFP is enabled, stock Firefox Nightly and also stock Firefox ESR are not affected.
• I see a POST https://api-auth.soundcloud.com/web-auth/sign-in/... failing and returning action_denied whenever the captcha fails to load.