Closed Bug 1869521 Opened 4 months ago Closed 3 months ago

YouTube is capping resolutions to 1080 on Linux aarch64 user agents

Categories

(Web Compatibility :: Site Reports, defect)

Firefox 120
ARM64
Linux
defect

Tracking

(firefox123 fixed)

RESOLVED FIXED
Tracking Status
firefox123 --- fixed

People

(Reporter: marcan, Assigned: denschub)

References

()

Details

(Keywords: webcompat:site-wait)

User Agent: Mozilla/5.0 (X11; Linux aarch64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Websites such are using the CPU architecture in the UA to make stupid decisions about the platform. In particular, YouTube has decided that all ARM/ARM64 systems without hardware video decoding are wimpy and underpowered, and cripples available video resolutions for them, regardless of actual performance.

Firefox already fakes this for Windows (always claims to be x32/x64, even on ARM) and for macOS (always claims to be "Intel Mac OS X 10.15", even on ARM). There is absolutely no reason to report the real CPU architecture only on Linux, and e.g. Chromium on aarch64 Linux claims to be x86_64 too. Firefox should do the same.

  1. Visit YouTube on a powerful Linux ARM64 without hardware video decoding (e.g. a Mac running Asahi Linux)
  2. Watch a 4K video

Actual results:

4K is not available

Expected results:

4K is available

Component: Untriaged → Desktop
OS: Unspecified → Linux
Product: Firefox → Web Compatibility
Hardware: Unspecified → ARM64

Apparently another pattern is websites forcing the mobile version on anything ARM: https://oldbytes.space/@millihertz/111567591627059004

This is technically a duplicate of bug 1556223, but I don't think we were aware about actual WebCompat implications of that and only treated it as a fingerprinting issue.

I'll add that info to the other bug, and re-word this to track the specific issue on YouTube (as we can fix that issue relatively fast right now, even without changing the UA as a whole)

Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1556223
Summary: UNIX platforms should not report the real CPU architecture in the UA → YouTube is capping resolutions to 1080 on aarch64 user agents

(In reply to Dennis Schubert [:denschub] from comment #2)

This is technically a duplicate of bug 1556223

16-minute-ago-me wasn't entirely right, we have a dedicated bug to only freeze the platform info: bug 1861847, but the point still stands, of course.

See Also: → 1861847

Maybe we should add the YT workaround to ua_overrides.js?

(In reply to Hector Martin from comment #0)

There is absolutely no reason to report the real CPU architecture only on Linux

There is a reason: A concern about native app downloads. macOS has Universal Binaries and Windows has x86 stub installers that can then download an x86/x86_64/aarch64 installable.

That said, given that Chromium has already frozen the architecture as x86_64 and not doing so appears to lead to site problems, I think we should freeze the architecture as x86_64.

I've reached out to YouTube folks to check if they are able to deploy a fix here. I'm also checking with Chris to see if we can land the platform freeze this cycle (he mentioned he has a WIP patch in bug 1861847 comment 1), but if we can't, an intervention is the way to go here.

We are a bit close to the soft freeze, but if we ship an intervention, that'd be a good candidate to uplift into beta regardless, so I'm not concerned about the timing right now.

Assignee: nobody → dschubert
Status: NEW → ASSIGNED

On our side we're going to ship a distribution-side prefs.js override for the user-agent as a whole for now, I'll remove it once there's a better fix available.

The YouTube issue seems to be even more bizarre than I first thought: apparently it thinks Firefox on ARM64 specifically is a HiSense TV (and this bit is server-side sniffing so I have no idea how on earth the logic arrives at that conclusion). Messing with the UA string, I think the logic is something like [Gecko && aarch64 && "not something known to pretend to be Gecko (e.g. Chrome)"]. It is that TV platform bit which is triggering the bad resolution limits. Chromium is unaffected even if you change the UA back to say aarch64.

Aside, somewhat offtopic but related: Can ua_overrides.js match on host platform? We have an issue where Netflix on ARM64 Firefox/Chromium with the unofficial Widevine from ChromeOS doesn't work, and needs a CrOS aarch64 user agent spoofed. Obviously you wouldn't want to spoof that across the board (I wouldn't be surprised if it breaks in the other direction too), but if it can be scoped to arm64 Firefox only that might be another good one to add.

Summary: YouTube is capping resolutions to 1080 on aarch64 user agents → YouTube is capping resolutions to 1080 on Linux aarch64 user agents

It's not strictly 1080 by the way, it's... just weird. Sometimes it's 720, sometimes you get up to 1440. Seems to somehow be related to screen resolution/scale and not even fully consistent.

(In reply to Hector Martin from comment #7)

The YouTube issue seems to be even more bizarre than I first thought: [...]

Ah, thanks for that. I'll forward this information to the YouTube folks.

(In reply to Hector Martin from comment #7)

Aside, somewhat offtopic but related: Can ua_overrides.js match on host platform?

We don't have a lot of custom targeting logic, but the uaTransformer is just a function that receives the original UA string and returns a new one. You can do any kind of checks you want within that function, and that includes parsing the platform out of it. Note that ua_overrides.js only sets the UA header and navigator.userAgent and doesn't touch other navigator. properties like navigator.platform. Although we have the ability to inject arbitrary JS into a site, where you can override other properties like we did here, for example. In this case, we'd limit the UA override to only change something on affected platforms, yeah. Changing the UA string in more cases than necessary is... sometimes making our work days a lot more exciting than they need to be.

Drop by our Matrix room (#webcompat:mozilla.org) or poke me on social media (@denschub pretty much everywhere) if you want to know more - this is already a bit too off topic for this bug. :)

(In reply to Hector Martin from comment #7)

We have an issue where Netflix on ARM64 Firefox/Chromium

If this is affecting our (as in, Mozilla's) ARM builds, I'd appreciate if you could file a report for that so we can try figuring that out. We can usually figure something out that's nicer than a UA spoof, but we'd need to know, of course.

Note: Safari also claims to be x86, even on ARM (both through navigator.platform as well as the user agent).

Websites such are using the CPU architecture in the UA to make stupid decisions about the platform.

Similar issue applies to chase bank, works with spoofed x86 Linux UA, doesn't work with aarch64 Linux UA.

I'm starting to wonder. How do websites like https://www.jetbrains.com/pycharm/download/ or the Firefox download page know what binary to provide by default?

(In reply to Luna Nova from comment #11)

Similar issue applies to chase bank, works with spoofed x86 Linux UA, doesn't work with aarch64 Linux UA.

Thanks for reporting. I can reproduce this error. I just filed a webcompat bug for this error: https://webcompat.com/issues/130946

With bug 1861847 landing, we will present as Linux x86_64 in the future, even on aarch64, so this YouTube issue will be resolved in Firefox 123.

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.