For some reason, I always enjoy reading about UA history. There’s rarely anything new (for me, partially because I lived through some of those earlier changes), but I’m still entertained.
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.
Hah, the android anomaly was fun, despite probably being benign :D The Microsoft UA thing wasn’t actually news to me, they’ve always had crazy hacks like that.
Hm, I thought this was going to be about Ukraine (UA is its ISO code), not a browser's User-Agent string. I started by reading the comments and found them pretty confusing.
Upon opening the article the first line would have informed you otherwise.
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.
I did find it confusing and I often read the comments first, because I usually find them more interesting. The first line of the article did inform me otherwise: your insight is accurate. I didn't mean to degrade your forum experience.
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.
Honestly, there's no point interacting with these people. Your comment was a perfectly fine chatty observation about the name of the article. 99.9% of people here aren't robots annoyed at any hint of spontaneity - most of us appreciate the odd unexpected turn that injects something different into the discussion. The ways we miss our lives are life :)
- 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."
HN should have descriptive subtitles though, the title of this piece only makes sense once you know the context, and if browser UA isn't of interest then that's wasting clicks. "An analysis and history of web browser UA strings" seems like a good subtitle to me.
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'.
Is there something like a "capabilities declaration" in the works to actually solve the problem? You know, something like a "X-I-Support: images, frames, ecma6, vr, xss" header?
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.
IMHO capability strings is also a bad idea. At best (and I'm still not a fan) they could spec HTTP 2.0 or HTTP 4.0. If there are odd features they're not compliant with then either get with the program and fix their browser, or don't claim that level of support.
Most of the problem here is failure to adhere to standards.
I think it's interesting to note that the majority of web developers for at least the last 10 years have realised that the User Agent is a very flaky way to determine capability. It is almost universally ignored now (with a few enterprise-level exceptions)
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)
Sadly there are situations where "feature detection" is not really an option e.g. when safari does something really weird and you need a special codepath for it server-side (like the video player not working if the server doesn't support content-range, so you have to not send a video to safari in that case).
if browsers would stop lying about dpi, we wouldn't need to guess trough UA wheter something is a low res desktop, a high resolution small monitor or something in between (and let's not start talking about browser windows that aren't fullscreen).
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.
Yeah. To some extent, that's outside the browser's hands - if the system doesn't know what the "real world pixel size" is (insert obligatory "of course I know pixels don't exist" disclaimer here) then there's no way to pass that information on to the browser.
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.
Oh, it definitely happens. Especially when you have certain multinational corporations with their own browser and far too much market share who claim their online office suite couldn't possibly work perfectly on <insert competitor>'s browser because it isn't as shiny as their 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)
[U]SA, specifically relating to encryption back when the US considered encryption munitions, and hence there were separate US and international ("I") releases supporting different crypto suites of browsers developed by US-based companies.
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.
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'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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
UA reduction has officially started with Chrome 101: The UA string is not sending the minor version anymore, only 0.0.0.
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.
About time. Statistics are mostly dead in favor of privacy anyway. At least this should help stop Google's blatantly anti-competitive practice of neutering search results if you're not using Chrome.
You think Google is reducing info Chrome sends in its user agent string in order to limit the ability of Google to favor Chrome?
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...
The one important use of the UA string is being able to tell whether it's a computer or a mobile device, to use different templates to render your pages. The new "client hints" botched that because while yes, there is "CH-UA-Mobile" that gives you a straight yes/no answer with no guesswork involved, you have to ask for it first — you can't get it on the first request, which very much defeats its purpose.
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.
> 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.
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.
The problem is that you can't really use the same markup for both touchscreens and mice. Touchscreens call for oversized everything so it's easy to hit things with your finger. Mice are much more precise, enabling you to pack everything more tightly, and capable of hovering, enabling you to add new interactions like revealing things on hover. Moreover, phones are mostly vertical and computer screens are mostly horizontal. While you can no problem add a fixed header on mobile, it will be an annoyance on desktop because it eats into the scarcer vertical area. But you can replace the fixed header with a sidebar because there's often more horizontal space than you know what to do with. And so on, and so forth. There's much difference between the two interaction paradigms if you want to provide a fitting UX for both. Most people these days, however, don't.
> Touchscreens call for oversized everything so it's easy to hit things with your finger. Mice are much more precise, enabling you to pack everything more tightly, and capable of hovering, enabling you to add new interactions like revealing things on hover.
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 */
}
Not only will that work for the same markup, it’ll also improve support for other devices like tablets and laptops with touch screens.
> 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.
I would much rather they served the same content with 'responsive' designs, than do browser-sniffing and serve me a mobile page.
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.
Well, you'd have to separate the different values in the User-Agent somehow, what character would you suggest? They all take the same amount of space (no pun intended).
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.
From this list of Chrome versions [1], it looks like WebKit 537.36 was the last version used before Google forked it to Blink, so I imagine they keep that around in the UA for backwards compatibility with sites that were looking for it.
You can even see it will stick around in the plans [2] they have to reduce the information contained in Chrome's UA
> Of course, a side effect of all of this is that ultimately all of those simple variants in the UA and work that goes into those giant databases mean that we could know an awful lot about you, by default. So that's not great.
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.
Since the generic fingerprint is associated with Tor, you get a lot more captchas. And JS that shows event times based on your clock (say a schedule) will think your time zone is UTC.
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.
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.
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.
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
92 comments
[ 4.1 ms ] story [ 178 ms ] threadThis 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.
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'.
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.
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)
For example: "Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0"
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.
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.
https://www.chromium.org/updates/ua-reduction/
https://wicg.github.io/ua-client-hints/
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:
Not only will that work for the same markup, it’ll also improve support for other devices like tablets and laptops with touch screens.> 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.
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.
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)
[2] https://www.chromium.org/updates/ua-reduction/
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.
[0] https://wiki.mozilla.org/Security/Tor_Uplift
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.
[0]: https://www.amiunique.org/
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.