Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UA Gotta Be Kidding

bkardell.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: UA Gotta Be Kidding

#61

Post by wlesieutre »

donatj wrote: post #46
mike_hearn wrote: post #19

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 Saf…

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…

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.

Re: UA Gotta Be Kidding

#62

Post by Wowfunhappy »

lupire wrote: post #58
jstanley wrote: post #36

Earlier quoted context omitted.

> 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.

Re: UA Gotta Be Kidding

#63

Post by Rychard »

Aissen wrote: post #60

I feel like the 90% use case could be fixed with a clean js feature detection API from browsers. Basically caniuse.com, but programmatically accessible. Any new feature must have a name, and sub-names for granularity. Any difference of implementation between major UAs must be given names. It does not need to be in headers, anyone wanting that could take the latency hit of a pre-detection js page. My 2cts.

There is some portion of the population that has an aversion to providing additional metadata about their browser, as it will be incorporated into your "browser fingerprint", increasing the likelihood that your browser can be (effectively) uniquely identified[0].

If there were some way to assure that this data wouldn't be used against me in some way, I would happily embrace simple solutions such as this. Unfortunately, there is no shortage of hackers/companies/governments that will gobble this data up and attempt to extract as much money from it as possible, without even the slightest consideration as to the impact it will have on end-users.

[0]: https://www.amiunique.org/

Re: UA Gotta Be Kidding

#64

Post by recursive »

lupire wrote: post #57
pjc50 wrote: post #24

Earlier quoted context omitted.

> 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 ther…

> 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.

Re: UA Gotta Be Kidding

#65

Post by donatj »

rollcat wrote: post #52
donatj wrote: post #46

Earlier quoted context omitted.

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…

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.

Re: UA Gotta Be Kidding

#66

Post by robertoandred »

donatj wrote: post #46
mike_hearn wrote: post #19

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 Saf…

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…

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

Re: UA Gotta Be Kidding

#67

Post by gernb »

robertoandred wrote: post #66
donatj wrote: post #46

Earlier quoted context omitted.

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…

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

Re: UA Gotta Be Kidding

#68

Post by colejohnson66 »

Rychard wrote: post #63
Aissen wrote: post #60

I feel like the 90% use case could be fixed with a clean js feature detection API from browsers. Basically caniuse.com, but programmatically accessible. Any new feature must have a name, and sub-names for granularity. Any difference of implementation between major UAs must be given names. It does not need to be in headers, anyone wanting that could take the latency hit of a pre-detection js page. My 2cts.

There is some portion of the population that has an aversion to providing additional metadata about their browser, as it will be incorporated into your "browser fingerprint", increasing the likelihood that your browser can be (effectively) uniquely identified[0]. If there were some way to assure that this data wouldn't be used against me in some way, I would happily embrace simple solutions such as this. Unfortunatel…

The alternative to providing APIs to detect features is to keep using the mess we're currently using. Previously, I would see you're using Chrome version X and know what features are available. All the APIs do is shift from using hacked together string.contains(...)/string.indexOf(...) calls (with bad lookup tables) to a proper format where I can just ask isXAvailable().

Basically, the same information is there, just in a more accessible way. And if you disable a feature in your browser's settings, isXAvailable() will now return false while UA checking says you still have it.

Re: UA Gotta Be Kidding

#69

Post by Aissen »

Rychard wrote: post #63
Aissen wrote: post #60

I feel like the 90% use case could be fixed with a clean js feature detection API from browsers. Basically caniuse.com, but programmatically accessible. Any new feature must have a name, and sub-names for granularity. Any difference of implementation between major UAs must be given names. It does not need to be in headers, anyone wanting that could take the latency hit of a pre-detection js page. My 2cts.

There is some portion of the population that has an aversion to providing additional metadata about their browser, as it will be incorporated into your "browser fingerprint", increasing the likelihood that your browser can be (effectively) uniquely identified[0]. If there were some way to assure that this data wouldn't be used against me in some way, I would happily embrace simple solutions such as this. Unfortunatel…

I understand the fingerprinting angle. It could be mitigated by ensuring a given UA will have all versions across OSes be the same set of feature, and only evolve these feature bits at the same time as version. Developer mode could have more granularity, at the cost of uniqueness.

Re: UA Gotta Be Kidding

#70

Post by mminer237 »

Aissen wrote: post #60

I feel like the 90% use case could be fixed with a clean js feature detection API from browsers. Basically caniuse.com, but programmatically accessible. Any new feature must have a name, and sub-names for granularity. Any difference of implementation between major UAs must be given names. It does not need to be in headers, anyone wanting that could take the latency hit of a pre-detection js page. My 2cts.

I mean, it's not hard to do with just vanilla JS. I built a site that relied on WebRTC, so I simply made a script that simply check `if (typeof RTCPeerConnection !== "function")`: https://packetlosstest.com/assets/test_support.js
Post reply on HN