Hacker News Reader

Comment by mike_hearn | Hacker News Reader

The whole privacy-through-UA thing maybe gone too far though. Safari on M1 Mac identifies itself as Intel Safari. A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps. For download size reasons you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Safari users (much slower downloads), or give up and ask the user which to pick. Chrome has an API that lets you determine the CPU arch using JavaScript.

Really there's nothing wrong with having a UA header but it gets abused because HTTP never had any standardized way to communicate feature sets. It should have had both. A way to identify specific apps for bug workarounds etc, and a way to communicate what versions and parts of the specs are implemented.

View on HN

I'll bet that the Intel moniker was kept around because websites saw *Safari" combined with "ARM" and started serving iOS-specific cases. The sad truth is that user agent strings are being parsed through the crappiest regexes imaginable.

Web browsers are too big to send feature sets to every websites. You'd end up with kilobytes of flags that almost nobody is going to use.

If you want to keep a bug database, there's client side detection and exact UA strings to match (for now). Matching ranges of user agent versions simply doesn't work right (see the Chrome/Firefox 100 issue for an example why) and often leads to broken workaround code being sent to browsers years after a fix was made.

> I'll bet that the Intel moniker was kept around because websites saw Safari" combined with "ARM" and started serving iOS-specific cases.*

Sometimes just the keyword "Safari" will get you the mobile site (looking at you arista.com).

I've noticed something similar on some websites where "Linux" is assumed to mean "Android" because most user agent strings identifying as Linux are secretly Android devices. It's really frustrating, especially with websites that think responsive design means your site switches to phone/tablet mode the moment its magic detection methods think they found a handheld.

> Really there's nothing wrong with having a UA header but it gets abused because HTTP never had any standardized way to communicate feature sets. It should have had both. A way to identify specific apps for bug workarounds etc, and a way to communicate what versions and parts of the specs are implemented.

The problems with this is that it's an adversarial market. It's not quite as bad as it used to be, now that there's almost no cases where the same company controls both the server and the browser (with the very big exception of visiting google.com). But there's still incentives to not treat different browsers the same way, or for the browser to lie about capabilities.

One silver lining of moving so much CPU-intensive site building work to clients is that feature/bug detection can be done there, live, where it has more chance of actually testing the thing you want to check for.

> incentive for browser to lie about capabilities

Such as?

Site authors requiring capabilities that aren't really required. And only testing on the one browser that advertises them.

> HTTP never had any standardized way to communicate feature sets

Except for the "Accept", "Accept-Language", "Accept-Encoding" and "Accept-Charset" headers (the last is phased out because UTF-8 is now used universally).

I don't think extending it much further than that is reasonable without introducing some binary encoding for a giant bitmap, and even that would eat more bandwidth than it's worth.

The alternative is shipping a packet of sketchy JS, which is much more bandwidth.

It doesn't have to be giant. If HTML5 were actually versioned then you could just roll extensions into the base standard every few years. In practice people do that anyway in an ad-hoc manner. After a while enough browsers have implemented something for long enough that people stop feature testing.

> you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Safari users (much slower downloads), or give up and ask the user which to pick.

But the computer they download the application on isn't necessarily the computer they'll run it on anyway, so you still need to give the user the option to pick.

Fine, but 99% of the time the user does want the locally compatible version, and this is especially true for naive users who don't understand the differences and need more help to make a good choice. So they benefit from a well-chosen prominent default.

I agree, but I suspect GP is reacting to something else: a surprising number of sites outright will not let you download software for a platform that doesn't match your user agent.

In the most egregious case, companies that don’t even support your platform will throw up a message like: “we’re still working on [platform] support, sign up for our mailing list to get notified when we launch!” The only way to download anything is to fake your browser’s user agent.

This is bad. There should always be an override link.

That's often true when people are downloading stuff for servers but how many are downloading on an M1 Mac and then moving it to an Intel Mac? It seems like an extreme edge case.

I think it's an edge case, but not necessarily an extreme edge case. Lots of people have both Intel and Apple Silicon Macs, and app bundles make it easy/natural to move apps between computers.

Its pretty shitty that you are forced to use javascript to know something basic like this. I get the purpose of redacting some information to improve privacy, fighting the fingerprinting, etc... but the basic utility of the user agent string is to help facilitate simple things like showing users the right content for their platform, macOS vs Windows, x86 vs Arm, etc... making this not work is just such a disappointment.

You can’t even tell iPadOS from macOS anymore, which was a major problem for us.

Our mobile website is full of essentially “Do this in the mobile app” buttons that only show up on mobile devices. Suddenly we had to rewrite it all to be done with JS rather than server side because there’s no way to detect iPads server side anymore. Even then our JS test for iPad is essentially “Is a Mac” && “Supports Multitouch” which if Apple ever releases a touch screen Mac will be trouble.

Similarly the new Edge on Xbox One just claims to be Edge on a Windows PC whereas it used to previously advertise you were on Xbox. Makes it difficult to do Xbox specific enhancements.

The ARM Macs are pretty decent at running iPad apps. I think there's less and less valid reasons to distinguish the two.

As stated elsewhere though, you also can't distinguish ARM Macs from Intel Macs. Same UA. As long as the vast majority of Macs are still Intel, we really don't want to clutter our UI with non-functional app callouts.

The market reaction to having iPads distinguishable from Macs via UA was to serve 4" phone screen layouts to 12.9" iPads for years, so I can understand why Apple changed that. Sucks for the handful of websites that were doing it right.

Why not show/hide those buttons with a window width css media query?

how would that help? The window width of my iPad is larger than my desktop

What can the website do on your desktop that it can't do your iPad? Why does it need these buttons?

There is the Accept header which isn't perfect but would be a better thing to abuse.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

> give up and ask the user which to pick

Isn't this the better choice, though? The cost of computer haruspicy when it goes wrong is far greater than the inconvenience of having to declare what you want when you're downloading something.

Android chrome sends the manufacturer and build. Might as well send my serial number.

> For download size reasons

How important is that nowadays? Aren't we talking about just executable code? Just how large is your binary?

Universal binaries are very convenient.

Many people don't have gigabit connections and the longer a download takes, the more likely it is to fail or users are to get bored and give up.

> A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps.

Developers should be publishing universal binaries wherever possible. Just because I'm on an Intel Mac today, doesn't mean I won't migrate the system to a new machine tomorrow, etc.

Your Web page should not need to know the CPU architecture and should not be allowed to know the CPU architecture. Any "feature" that supports that in any way is a bad idea.

Software distribution is a trivial corner case that does not justify either the complexity or the security risk of giving that out.

>> Software distribution is a trivial corner case that does not justify either the complexity or the security risk of giving that out.

Yes, we already have to choose between OSX, Windows and Linux. We could just as well point at Apple and say it's not right to call Intel and ARM versions of their OS the same thing. No no, just make the user select the right one. Automating this decision is a very minor convenience thing we can live without.

Software distribution is a rather critical task in general purpose computing!

Our "trivial corner case" is somewhere north of 1M downloads per month. We offer packages for several OS+architecture combinations, and being able to highlight the appropriate download link adds a non-trivial bit of convenience for our users.

Reply on news.ycombinator.com