Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy. They would be criticized for that too. There's just no winning lol
Asahi Linux is a comparatively small project with few real users. It's pretty arrogant to assume Google is intentionally targetting them specifically.
If anything, the bug here is that Chromium uses x86 on arm systems, although for Asahi specifically that's probably the right choice, it's a lot less clear to me that's the right choice for all systems.
(I'm guessing those report aarch64 correctly.)
The Asahi Linux developers have a history of taking everything personally. If Apple adds a new way to start an ELF in macOS 12.3, it's because of them. If someone criticizes them publicly on Hacker News and isn't immediately shamed, it's because the actual leadership at Hacker News hates them (not an exaggeration considering their public stunt here where they blamed @dang for everything). If someone doesn't quite agree with their politics in perfect lockstep, they will publicly try to force you to resign (look at what happened with Dlang). And, more recently, threatening to keep changes downstream and out of the mainline Linux kernel as retaliation for what they call inappropriate conduct (which, well, if the COC of Linux hasn't been violated, I'm guessing it's probably them). And of course, if it's found out that the M2 has a technical bug with audio processing that literally nobody noticed until now, it's proof that Apple is full of incompetent idiots, unlike them.
It's also why, if I were running a corporation, I would almost require that anyone using Asahi on their Mac use a corporate fork for their own protection. I wouldn't rule out retaliation.
Just in general it's hard... for many things I find. There's perpetually a bunch of seemingly reasonable "yeah but" for almost every default once you hit a certain number of variables / use cases / differing users / customers and etc.
It sounds less like "let's help the poor Raspberry Pi users" or "let's make Asahi's experience worse" and more like "workaround for a buggy TV that nobody bothered to implement correctly".
Depending on the implementation, what it returns can be based on the presence of optimized software decoders for a platform, presence of hardware, resolution and other characteristics of the video, it can also be based on a decoding benchmark that the web browser runs, etc.
https://w3c.github.io/media-capabilities/
https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
> Why does this not affect Chromium? Because chromium on aarch64 pretends to be x86_64
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...
> Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy.
What he claims though is that they do already do that at least if it's not aarch64:
> Quality 1080 by default. If your machine has 2 or fewer cores, quality 480. If anything ARM, quality 240.
Probably, but it's pretty poor UX if videos start super-choppy by default and slowly downscale to a playable resolution over several seconds. Having a good default is still important.
https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
That way you can fall back for anything too old or weird to support that API, and if the vendor complains there’s a simple response: implement the standard.
This was a well understood problem in the 80s if two sides need to establish a commonality one offers options and the other picks. Google controls both YouTubers and the most common browser making it uniquely positioned to handle this well.
For instance, the RPi5 cut out the H.264 decoders versus previous gens, and now only do H.265 decoding in hardware.
If spoofing the user agent fixes the issue despite being on ARM, then this does sound like a legitimate issue.
> Chrome is not affected even if it claims to be aarch64.
Disclosure: currently (as a personal project) slowly building an alternative to Android
I can't imagine someone @-ing me because when they were 18 years old and status insecure, someone sold them a corporate identity and feel entitled to maintain their edge case.
I need to stop giving away my stuff for free.
To be fair, there are a lot of ARM Chromebooks and SBCs that can't really handle 4K video.
Raspberry Pi et. al. has been there many many years.
I would've preferred a higher bitrate 1080p stream, but Youtube only offers that on a limited amount of videos (assuming you have Premium of course).
https://bbs.archlinux.org/viewtopic.php?id=289645 https://www.reddit.com/r/Twitch/comments/1118xgz/unsupported...
Someone solved it by disabling fingerprinting resistance https://www.reddit.com/r/archlinux/comments/100t2q3/comment/...
YouTube, however, did stop working on me this morning. It’s now demanding I sign in, which it didn’t before.
Similar issue happens also in some Google services, e.g. Google Docs. It does not work at all (or everything is in wrong resolution) if you have fingerprint resistance enabled.
In most cases this detection is "good enough", but with Asahi a new edge case has emerged. Ideally the device would be able to tell the server about it's capabilities, but that could be seen as an invasion of privacy and could quickly turn into a new metric for profiling internet users across sites.
It is not technically privacy issue if it "tells" about them, by having freedom to tell what it wants.
If the information is mandated with remote attestation and server can force it and otherwise not work properly, then it becomes privacy issue.
It's more like that guy plays the victim card to build some PR.
I don't even bother trying to watch YouTube on Firefox, my main browser on Windows. I switch to Chrome for this task.
If I were them, I would make a neural network to predict which video quality a user is least likely to switch away from. Then default to that.
Inputs to the network should be country, detected network speed, CPU speed, browser, screen resolution, etc. also include the users history of changing resolutions - a user who frequently decreases the resolution is probably conscious of bandwidth and therefore doesn't want to default to HD even if their device is capable.
The network can probably be tiny (perhaps just a few thousand weights), so could run on either the client or the server.
> Why does this not affect Chromium? Because chromium on aarch64 pretends to be x86_64
Can't he just change the default? It's not locked in to a maximum resolution of 240 is it, he could click the video settings and switch up the quality to 1080 or similar.
Seems a bit excessive for him to refer to this as "crippling Firefox" when it only takes a couple of clicks to sort it out.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1.2 Safari/605.1.15It's in Firefox but it happens with Chrome user agent too and it just stopped working without an update inbetween.
e.g. for steamcommunity.com https://bugzilla.mozilla.org/show_bug.cgi?id=1570108
> Add the following UA override for desktop Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
It greatly simplifies the bugs in a sea of badly written JavaScript on the web.
Best of luck =)
> Why are web services like this? Just let the client or user decide, dammit!
1) because YT is paying real $$ to show me videos of cats (especially when I have a bunch of ad-blockers and haven't see a YT ad in 15 years) 2) because "it's your phone dude, you don't need to watch a cat-video in 4k!! your friggin' screen doesn't have 4k to begin with 3) because we can
(the last one.. it's the last one)
For the same reason all browser's user agents are prefixed Mozilla/5.0, all browsers end up all lying anyway.
Let's all machines be an iphone or windows NT/10 device and forget about this shit.