Thanks so much for chiming in here. Admittedly, bot detection is really interesting to me as a subject. It's not the kind of thing you can throw infinite ML at

Thanks so much for chiming in here. Admittedly, bot detection is really interesting to me as a subject. It's not the kind of thing you can throw infinite ML at and expect it to break even in terms of scaling; you need careful tuning and optimization baked in from the ground up, which means a fundamentally "manual" approach involving lots of lateral creativity and iteration. That creativity and one-upmanship (along maybe with the gigantic piles of money, because manual ;)) is what makes the field so interesting to me - but alas, I cannot pepper you with questions/topics/discussion/anecdotes/stories for two hours for obvious reasons :) So, instead, a couple of questions, considering datapoints likeliest to benefit others, and perhaps (hopefully) provide some appropriately dissuading signals as well. - How does Botguard detect Chromium running in headless X sessions? By looking at the (surely very wonky) selection of pages visited, or...? (Obviously IP range provenance is a major factor, considering the unusable experience Tor users reportedly have) - Regarding the note about "bending over backwards", while playing with some old VMs very recently I observed with amusement that google.com works in IE 5.5 on Win2K but not IE 6 on Win2K3SP4 (https://imgur.com/a/zg7FoAW https://imgur.com/a/zg7FoAW), entirely possibly due to broken client-side config, I'm not sure. In any case, I've also observed that Gmail's Basic HTML uses very very sparing XHR so as not to stackoverflow JScript, so I know the bending-over-backwards thing has stuck around for a long time. Besides general curiousity and interest in this practice, my question is, I wonder if this'll change going forward? Obviously some large enterprises are still stuck on IE6, which is hopefully only able to reach google.com and nothing else [external] :) - I wonder if a straightforward login API could be released that, after going through some kind of process, releases Google-compatible login cookies. I would not at all be surprised if such ideas have been discussed internally and then jettisoned; what would be most interesting is the ideation behind _why_ such an implementation would be a bad idea. On the surface the check sequence could be designed to be complex enough that Google would always "win" the ensuing "outsmart game", or at least collect sufficient entropy in the process that they could rapidly detect and iterate. My (predictable) guess as to why this wasn't implemented is high probability to incur technical debt, and unfavorable cost-benefit analysis. I ultimately have no problem that JS is necessary now; if anything, it gives me more confidence in my security. Because what other realistic interpretation is there?