This works in theory, and shows you've made good research on the topic. I operate an IP anonymizer detection service and these are the gotchas I think you'd find in real life though:

- some browsers / extensions disable webRTC by default, and certain privacy configs use a proxy to reach out to STUN. These are not "weird" browsers: Safari, Firefox, Brave, Opera do it by default or through configs.

- naive RTT calculations will cause you lots of false positives. Just as an example, some devices on low battery do slow down their network stack, randomly causing bigger RTT on some network packets and triggering your TLS > RTT*3. We discovered it the hard way, and there are many more other corner cases.

- as an independent site operator, I'd find this harder to deploy than i.e. deploying a reverse proxy or using 3rd party service. Also you'd need to always show an interstitial screen where the webRTC checks happen, instead of running your detections on the fly as each request comes in.

If you're interested on the topic, let's chat by email and/or take a look at our demos:

- https://demo.truesign.ai/protected-form

- https://demo.truesign.ai/protected-content

Truesign doesn't use PoW. The bot detection works by collecting network and browser signals.

The PoW solutions I've seen out there just add 1-2 seconds of delay before granting access to the whole site. It could work against random unsophisticaed crawlers but I don't see how that can stop determined bots.

it analyzes the network packets in real time, they contain many data points if you know where to look.

Residential and mobile proxies are also detected.

It would be dangerous if this tool fell into the wrong hands.

Where's the wait list?

Personally I found that rejecting disposable/temporary emails and flagging requests behind VPNs filtered out 99% of abuse on my sites.

No need to ask for a phone or card -- or worse, biometric data! -- which also removes friction.