> I have recently talked with customers and users who have faced servers that refused them access when they connected to sites using curl, but allowed them acce

> I have recently talked with customers and users who have faced servers that refused them access when they connected to sites using curl, but allowed them access to the site when they instead use one of the popular browsers – or if curl was tweaked to look like one of those browsers. It might be a trend in the making. There might be more sites out there now that reject clients that produce the wrong fingerprint then there used to be. As someone working in a bank, yeah we do use this. The draconian application is for our iOS and Android apps - if they don't match Apple's or our fingerprints (respectively, yes you could bake a different cryptographic library in Android) the connection is summarily terminated. For the web app, it is used as a fingerprinting component, but is less draconian in such that it merely checks if the TLS ciphers and the user agent (and some JS magic) is sensible (and the approach is to block known bots outside of robots.txt and the robot-readable login page - to be blunt it includes wget and curl), but I knew that one of our competitors is so much more draconian that it blocks Firefox due to its consistent TLS ciphers (we don't because Firefox is way more accessibility-friendly than Chrome). > Another popular way to work around this kind of blocking is to simply program a browser to do the job. Either a headless browser or with tools like Selenium. Since these methods make the TLS handshake using a browser “engine”, they are unlikely to get blocked by these filters. And yes, we already know about pupeteering (that's why we are now focusing to provide business clients with our own FIDO stick while clients are encourage to activate 2FA, preferably FIDO but at the insistent of the management still includes TOTP and SMS (!) verification).