UA Gotta Be Kidding
bkardell.com
bkardell.com
This is the beginning of the end for the UA string. As more and more UA reductions are deployed, the UA hints will become more useful and eventually depreciate the UA string entirely.
I can't imagine Google would be doing this without some sort of back-channel method of tracking this exact info. They're likely just removing this info from visibility to other websites, giving themselves a competitive advantage. Man, that sounds a little paranoid, but...
And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices.
> Sites that wish to serve mobile-specific sites using UA-CH can do that using the Sec-CH-UA-Mobile headers that are sent by default on every request.
What am I missing?
My experience is generally (though not always) the exact opposite. It’s usually the case that when designers and implementers took the care to ship a properly responsive design, they’ve produced a design that adapts well to many factors. Designs which treat different device classes differently tend to be rigid, and fail to anticipate subtle differences or factors within those device classes.
I hesitate to link to the snotty site most commonly used to point this out (though I will if anyone asks), but HTML is responsive by default. Knowing this, and building upon it, is a great way to start learning how to build responsive pages that work really well.
Here's an example from my own project: same post, different layouts. https://imgur.com/a/7uOy7II
If you must make the distinction, it’s a media query away:
@media (any-pointer: coarse) {
/* this is a touch screen or other device which would benefit from larger tap targets */
}
@media (any-pointer: fine) {
/* this is a device with a mouse, trackpad, or other similar high precision pointer input */
}
@media (any-pointer: coarse) and @media (any-pointer: fine) {
/* this is both */
}
> Moreover, phones are mostly vertical and computer screens are mostly horizontal.
These are wild assumptions which also would better be served by a media query (aspect-ratio, min-aspect-ratio, max-aspect ratio, min-height, min-width). This will also better support other devices like tablets, as well as users like me who browse on desktop with a window much taller than it is wide.
> There's much difference between the two interaction paradigms if you want to provide a fitting UX for both.
Of course. But there’s no need to serve different markup to accommodate them. Besides the aforementioned media queries, you can do quite a lot to accommodate different viewport sizes and quite a lot else with eg grid or flexbox. You just have to know which tools to use for your use case, or how to discover them.
More often than not, I immediately go and switch out of Mobile site for pretty much everything I visit on mobile.
Features are missing, functionality is broken or gone, they force text/page sizes that don't work for me and block zooming (Firefox thankfully allows me to override that b.s now), and they serve "Install our App!" overlays.
Doordash I found is like this - some stores use them for white-labelled Delivery and SMS/Email you a link to the tracking page for your order.
I click the link on my desktop, I get a standard page, it shows a tracking map.
I click the link on my phone, I get a mobile version of the page which does have a tracking map, but the entire screen is covered with an overlay that says "Install our App!" with no dismiss option and you have to try to make out the driver's location through the 80% opaque overlay.
This had a new tidbit in the final section, though: They are working on a new XR browser [0] and history is repeating itself.
Only tangentially related, but when I checked the mobile browser stats for Germany, I found out about Instabridge which seems to be some ad-tech wifi password sharing app and seems close (7.75 % - 10.58 % to overtaking Samsung Internet as 3rd biggest browser. It appears as if almost all their users came from Safari.
[0]: https://wolvic.com/
[1]: https://gs.statcounter.com/browser-market-share/mobile/germa...
https://conferences.sigcomm.org/imc/2017/papers/imc17-final2...
There was a crazy "android anomaly of 2015" that nobody else seems to have noticed.
The Microsoft XML file with domain-UA pairs is among the most insane ideas I have ever seen.
Both are described in this paper.
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.
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.
Sometimes just the keyword "Safari" will get you the mobile site (looking at you arista.com).
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.
Such as?
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.
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.
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.
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.
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.
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.
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.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...
How important is that nowadays? Aren't we talking about just executable code? Just how large is your binary?
Universal binaries are very convenient.
So the usual solution is feature detection, where the javascript and/or CSS learns the true capabilities of the browser, and switches features on and off accordingly. Of course, if you depend on generating a lot of capability specific content on the server side, this may be an issue - but in that _extremely_ rare case that's easily worked around by asking the js to redirect to a URL with specific capabilities baked in (or loading a specific javascript file)
Yeah, I got bitten by that one too. Pretty darn annoying especially because Safari doesn't tell you what is wrong.
once we could at least use the availability of touch features to guide between the cases, but now that one started lying as well.
we parse user agent not because we like to but because the absolute shitshow that's the metrics system on browsers.
Complete side note, I'm shocked at how terribly Linux is still doing at the whole hi-dpi vs lo-dpi vs everything in between.
But yes, generally speaking the gold standard is CSS rems - it presumes that a user has somewhat configured their machine comfortably, mind. But if you use that text size as a relative measure for all the text on their screens, you can scale your interface elements knowing that if 1rem is a good readable size for a letter, all headings etc should be bigger, no interactive element should ever be smaller than 1rem (and should probably be a fair bit bigger on mobile devices), you can define margins around this measure too.
It isn't perfect, but it'll beat UA most of the time. You'll stop worrying about the definition of high res and low res, and instead focus on the comfort of the individual - which might be a bespectacled octogenarian or an impoverished student on the same system.
I wish. Once in a while I come up to sites that present content based on UA (e.g switching UAs produces a different layout). In all cases things work, but the UA pile of lies can make it a subpar experience on this or that device with this or that browser.
The only other exception I've seen recently is because of genuinely lacking features e.g. WebMidi, or where a really small outfit just doesn't have the time to ensure 100% compatibility with every browser yet, so puts it out there with heavy warnings.
But IME, it is vanishingly rare to find a website that says "Nope, can't do this with firefox" and flat-out refuse to serve you without a very good reason, and when they do, they're idiots if they use the highly-spoofable UA to do that check.
(But I would love to see counter-examples - as I say, I'm sure they exist, but outside the corporate world, I haven't seen it in a while)
It does not need to be in headers, anyone wanting that could take the latency hit of a pre-detection js page. My 2cts.
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.
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.
I encourage anyone who's using Firefox to turn the `privacy.Resistfingerprinting` setting to `true`. It gives you a generic Windows 10 useragent with an old version of Firefox. The Tor Browser Bundle does this so you can blend in with the same UA.
Does it have any negative side-effects?
It doesn't just spoof the UA, it does some other things too. Not sure what they are. It's part of the Tor Uplift[0] initiative.
I could even imagine an "assigned capability strings" database and x- prefixes and all, but it's probably an old fool's dream in these fast-m— thing-breaking times.
At this point I think UA spoofing is effectively a compact capabilty declaration, where you say “I can do everything X does + Y and Z specifically”
Most of the problem here is failure to adhere to standards.
If you're worried about spaces in user-agents wasting bandwidth, there are a awful lot of windmills you'd have to bark at every day, I do not envy you.
Basically you obviously want to remove the UA string as it's just wasting bandwidth.
Instead you felt compelled to instead reply to tell everyone you know that UA is the Ukrainian ISO code.
Did you really find the comments "confusing", or is that artistic license?
It comes across like, "I couldn't just read the headline and immediately post my reaction to it". You're not the first to have this reaction to HN articles, and you won't be the last, but it's very dismissive of the eclectic nature of HN articles to charge into the comments to discuss something else entirely.
Edit: by the way, if you want don't want to be dismissive of whatever good there is in HN's community, you'd do well not to presume that others are dishonest ("artisticly licensed"). I spent the morning reading about what's actually happening in Ukraine and saw a post on UA's history (this post) and came in expecting to read more about Ukraine. I experienced amusing confusion and shared that.
https://news.ycombinator.com/newsguidelines.html
Here are a few relevant excerpts:
- Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community
- Assume good faith.
- Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
I would rather discuss the article than carry on this meta-discussion any further.
Also, if someone takes a conversation in a direction in a forum that you don't want to follow then best response is usually 'don't follow'.
For example: "Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0"
You can even see it will stick around in the plans [2] they have to reduce the information contained in Chrome's UA
[1] https://en.wikipedia.org/wiki/Google_Chrome_version_history (scroll down to v27.0.1453 on 2013-05-21)