History of the browser user-agent string (2008) | Hacker News Reader

History of the browser user-agent string (2008)

webaim.org

62 pointstosh23 comments

It is time to get rid of this header. All browsers should stop sending it.

Even more important is to stop leaking your private IPs: https://browserleaks.com/webrtc

Even more important: Stop using http by default when users enter a hostname into their urlbar. https is a joke at the moment. Because when users go to somecoolsite.com they are at first connecting via http. Now a man in the middle could just proxy their connection. No security at all.

HSTS somewhat solves the case after the first connection, but I dream of a world we’re HTTP is disabled for public ip access

HSTS has more downsides then upsides.

First of all its additional complexity that has to be implemented by the website. More work, more things that can go wrong.

Second, it needs to store data on users machine. It is basically a cookie. So users would need to kiss goodbye privacy to "benefit" from it.

Third, it only works if the user has connected to the site on the same browser before. And did not delete the cached HSTS data.

So in sum, it kills privacy, works only sometimes and piles up on the stack. It's a typical bandaid solultion. Instead of fixing the root cause, it makes things worse.

HSTS Preload exists.

HSTS is a server config line, automated vulnerability scanners will pick it us. Sure that’s not optimal, but crypto is hard in general, HSTS is one of the easier to understand concepts. Fix the whole problem not one minor functional issue.

The users machine cannot be part of a legitimate threat model. Either it’s compromised or it’s not. Either it’s FDE’d or it’s not. I wouldn’t even pretend that a HSTS assertion here or there would even make a difference in the shitshow that is browser cache.

I agree it’s a hack, but at this point I pretty much think that about crypto standards, period. Having HSTS is better than not, and we’re a while away from disabling unencrypted comms.

We use user agent histogram as a security litmus test on our payment sites. If we see a spike of a smaller set of user agents without increased traffic (or a longer ‘tail’), we can almost be certain that something shady is going on. Not super useful as in, we can’t just block every legit looking user agent, but it notifies the analytics team that can then dig deeper.

The https issue is already solved by HSTS preload.

As for user agents. Nope. We connect those directly to better user support outcomes, especially for our less technical users. Abandoning that would be a foolish conceit.

One of Mozilla's recommended extensions is Smart HTTPS (which tries connecting to HTTPS, and if it fails reverts to HTTP). But I agree it would be nice for it to be default.

[0] https://addons.mozilla.org/en-US/firefox/addon/smart-https-r...

But that doesn't help with mitm attacks at all. HSTS preloading is crude but probably the most pragmatic working solution.

It helps with passive sniffing. But yeah, if attacker blocks HTTPS, then it's ineffective. I'm not dismissing HSTS, but rather suggesting to use both of these techniques (HSTS as site admin, Smart HTTPS as an user).

It's likely that the Chrome team has plans to eventually assume https by default, given that they've outlined their plans mark http as insecure on connect[0] (rather than on input).

The move would likely have to be coordinated among the browser vendors, but it wouldn't surprise me if Apple decides to lead the charge on this one. All iPhones being https by default would put a massive demand on crappy systems that assume they can mitm users.

0: http://www.chromium.org/Home/chromium-security/marking-http-...

I think it's clear that everyone would like HTTPS-by-default, it's just a question of how to do it in a way that doesn't cause a massively degraded user-experience in the short term and still provides security gains (racing the two gets around the UX problem, but provides no security benefit). We might see something whereby we use HTTPS if the hostname has previously been connected to over HTTPS (even without HSTS).

Now as we have reduced doctype to just HTML, almost everybody is using Chrome (and all the alternative browsers are built on the same engine) and the rest use Firefox (which still renders HTML almost exactly the same), standards are pretty well-established and most of the people are forced to auto-update regularly and have no problems doing so (thanks to the progress in bandwidth availability) it indeed feels reasonable to clean the user-agent up or deprecate it completely.

What would break if at this point Safri and Chrome decided to go back to a basic user agent string and abandon all of the silliness? Do any important sites do sniffing in any important way?

(I know I sniff for iPhone but that’s about it)

Several Google sites use user-agent sniffing.

I've seen comments from Youtube devs that say progressive enhancement is too slow, so they use the useragent to choose what bundle to send.

YouTube could likely use Service Workers in modern browsers to determine what bundle to load. If so then our modern browsers could simply send [browser]/[major version] (eg. Google Chrome/78 or perhaps Blink/78) while old browsers continue to send their legacy mess.

It's worth calling Google out particularly here, because not only do they do useragent sniffing, they also launch new services that use useragent sniffing to block any browsers that aren't on a compatibility whitelist.

I get it, sometimes sniffing is necessary for some things. But it's embarrassing to see a company of Google's size and caliber so reliant on it, and to see their developers so quickly accept that they're just going to abandon what is one of the cornerstones of good web development.

Safari tried to freeze their user agent a while back, but if I remember correctly they backpedalled on their decision almost immediately.

The way I see it the user agent string is just a way of telling bad actors what exploits are going to work on your device -- google chrome gives away your phone's maker and model without a thought.

It never made it to the mobile age.. webdevs started serving iPhone-compatible pages by sniffing "Mobile Safari", so now Chrome on Mobile also says it's "Mobile Safari".

A thread from 2016: https://news.ycombinator.com/item?id=11693455

2013: https://news.ycombinator.com/item?id=6674812

Discussed at the time, though not much: https://news.ycombinator.com/item?id=298844

Prior discussion: https://news.ycombinator.com/item?id=298844

Cute history, though of course Microsoft didn't write Internet Explorer, they bought it. From Spyglass, if I remember correctly?

Reply on news.ycombinator.com