Comment by chii
1 year ago
user-agent had and will never be useful for the client, and therefore, cannot ever be useful for the server in trying to identify someone.
If it is advantagious to lie about the client, the client will lie, and the server will know this and not trust the client's headers.
Blocking or restricting based on other metrics should be the way to go - for example, shape traffic based on the speed and frequency, such that bots gets shaped but users' dont (because they're slower etc). It aligns properly with the desire to stop bots.
> user-agent had and will never be useful for the client
In the past it was definitely useful for some things. To use as an example something I was involved with, many years ago: if you were deploying software via ClickOnce and needed a particular version of .NET installed, that information was exposed in the user-agent string, so you could tell the user “you need to go install this other thing first”, rather than saying “try this, and if it doesn’t work in one of these ways, check if you’ve installed this”.
These days, it’s not often useful, and feature detection is highly preferable where possible, but platform detection (whether via user-agent string or properties like navigator.platform) is still definitely useful, for things that should be tied to what the platform actually is. For example, on a download page you want to know what the OS and architecture are in order to recommend the appropriate file to download for that machine. Or, when implementing keyboard shortcuts, Apple platforms use metaKey (⌘) instead of ctrlKey (⌃), and visually present the shortcuts differently too, such as ⌘⌥⇧⌫ or Command-Option-Shift-Delete, compared with Ctrl+Alt+Shift+Backspace for everyone else.