I think it's pretty hard to read this as anything other than a maintainer trying to stop malicious actors from abusing their project. You might not agree with h

I think it's pretty hard to read this as anything other than a maintainer trying to stop malicious actors from abusing their project. You might not agree with how they're doing it, but calling this enshittification and kafkaesque feels pretty hyperbolic. Posting the comment here just in case folks don't click through: Hey everyone, It saddens me to be forced to add yet another annoying thing to the public localtunnel server but... As of 2 minutes ago, all tunnels now require a real user to enter the endpoint IP address (which acts like your tunnel link's password) on the consent page. Showing and having the users click a continue button in order to access the tunnel content didn't really do too much to fight of people hosting phishing portals via localtunnel. I've also been getting an enormous amount of phishing/abuse notices from various organizations worldwide, forwarded notices from my hosting provider, and even have been put on notice that I will be responsible for costs related to removing IPs from various IP blacklists... I'm currently building an abuse reporting tool for these orgs to use that'll automate banning users hosting phishing portals but until that's built & tested this new password-protection way of abuse fighting will have to do. Sorry for any inconvenience... PS. If localtunnel doesn't work for your use case for whatever reason, feel free to checkout other alternatives like https://ngrok.io If anyone has any other suggestions on easy ways to fight phishing/malware portals from using this service, i'm all ears!