libv8-node VS InsideReCaptcha

Cue libv8-node+mini_racer from which PyMiniRacer was born. It is non-trivial but not as hard as one might think.

The most painful part is the libv8 build system and Google tooling, which makes it an absolute PITA for libv8 consumers that are not Chrome.

This is why the libv8 gem was atrocious to keep up to date and to build for several platforms, and why libv8-node was born, because the node build system and source distribution are actually sane.

Disclaimer: worked at Sqreen, now maintainer of libv8-node and collaborator of mini_racer

https://github.com/sqreen/PyMiniRacer

https://github.com/rubyjs/mini_racer

https://github.com/rubyjs/libv8-node

Google: implements an entire obfuscated VM with its own bytecode inside Javascript for their CAPTCHAs so that people cannot cheat it

While they likely wouldn't do a zero-day, their JS files, particularly for automated captchas, do push the boundaries of whatever JS engine they're executed inside. See https://github.com/neuroradiology/InsideReCaptcha#the-analys... and note that this analysis is 8 years old. While there's minimal risk if you're either using a full-fledged modern JS engine or a limited-subset interpreter like the OP, an older or non-optimized spec-compliant JS engine might hit pathological performance cases and result in you DOSing yourself.

So people voting for DCR are not allowed to protect their privacy with VPNs, must reveal their real IP address, and must allow proprietary, obfuscated, sophisticated Google reCAPTCHA to fingerprint the heck out of their devices.