Hacker News new | past | comments | ask | show | jobs | submit login

Then I'm not sure I understand you. The proposal is clearly proposing new fields that are less susceptible to abuse (whether intentional or not). Your idea of parsing a "$BROWSER $VERSION $OS" string seems inferior to client hints that use structured headers.

I'm saying we still need a browser version field, in addition to a feature field. Features would do on their own, if they were perfect, but we shouldn't plan on them always being perfect. We have a demonstrated, in-the-field history of browsers claiming to support features when in fact they don't quite support them, and can even have crashing bugs. In the real world, supporting WebVR1.0 is more than just putting "web-vr/1.0.0" in the feature string.

Culturally, you should prefer to use feature detection. Most developers would never need to use anything else. But when Amazon makes its new whizbang WebVR1.0 front-end in 2024, they may need the ability to blacklist a particular browser. Lacking that ability may actually prevent them from being able to ship, if shipping will result in some non-trivial fraction of the browsers claiming "web-vr/1.0.0" will in fact crash, and they have nothing they can do about it.

Besides... they will find a way to blacklist the browser. Honestly "prevent anyone from ever knowing what version of the browser is accessing your site" is not something you can accomplish. If you don't give them some type of user agent in the header, it doesn't mean the Amazon engineers are just going to throw their hands up and fail to ship. They will do something even more inadvisable than user agent sniffing, because you "cleverly" backed them into a corner. If necessary, they will examine the order of headers, details of the TLS negotiation, all sorts of things. See "server fingerprinting" in the security area. You can't really stop it. Might as well just give it to them as a header. But this time, a clean, specified, strict one based on decades of experience, instead of the bashed-together mess that is User-Agent.

Or, to put it really shortly, the fact that a bashed-together User-Agent header has been a disaster is not sufficient proof that the entire idea of sending a User Agent is fundamentally flawed. You can't separate from the current facts whether the problem is that User Agent sniffing is always 100% guarantee totally black&white no shades of grey mega-bad, or if it's the bashed-together nature of the field that is the problem.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact