Re:It is not possible to detect and block Chrome headless
by exikyut on Friday January 19, 2018 @07:52AM
(#16185827)
> Google's latest captcha specification (and similarly sophisticated systems) must be completed in a small window of time, change rapidly, have a varying number of "rounds", and are extremely antagonistic to being reloaded in e.g. a frame.
Hmmm.
I've observed the timing thing myself - I'll sometimes hit the captcha first while I fill the rest of a form out, then it'll expire, and I'll need to do it again.
What do you mean by "change rapidly" and "varying number of "rounds""?
Regarding avoiding loading the content in a frame - what about making the initial iframe load happen on the machine of the person filling the captcha? Why can't this work?
--
> Practically speaking, you can't consistently outsource that to a third party API that uses humans to click and verify the images.
I'm both very curious and somewhat surprised this is the case.
--
>> It sounds plausible that one could simply sign up for the captcha-filling service multiple times, and submit captchas to defeat in parallel. Could this work?
> Sure, but what are you gaining? ... you'll be paying the same as just sending multiple requests to the API, and the concurrent requests are routed via the API's backend to different human operators for a solution.
This is what I'd strongly expect, but I very much wonder if captcha-filling services ratelimit the number of filled captchas per account.
In theory (now I think about it) ratelimiting would hurt the service provider so this might be unlikely, but where I want to play with massive parallelism I do wonder if sharding hundreds of requests across multiple accounts would be useful or not. Sharding across multiple providers would probably increase parallel throughput by a small amount though.
Hmmm.
I've observed the timing thing myself - I'll sometimes hit the captcha first while I fill the rest of a form out, then it'll expire, and I'll need to do it again.
What do you mean by "change rapidly" and "varying number of "rounds""?
Regarding avoiding loading the content in a frame - what about making the initial iframe load happen on the machine of the person filling the captcha? Why can't this work?
--
> Practically speaking, you can't consistently outsource that to a third party API that uses humans to click and verify the images.
I'm both very curious and somewhat surprised this is the case.
--
>> It sounds plausible that one could simply sign up for the captcha-filling service multiple times, and submit captchas to defeat in parallel. Could this work?
> Sure, but what are you gaining? ... you'll be paying the same as just sending multiple requests to the API, and the concurrent requests are routed via the API's backend to different human operators for a solution.
This is what I'd strongly expect, but I very much wonder if captcha-filling services ratelimit the number of filled captchas per account.
In theory (now I think about it) ratelimiting would hurt the service provider so this might be unlikely, but where I want to play with massive parallelism I do wonder if sharding hundreds of requests across multiple accounts would be useful or not. Sharding across multiple providers would probably increase parallel throughput by a small amount though.
Thanks for the feedback!