I disagree with respect to a pay gate. A payment gate on ngrok, even something as simple as requiring a credit card number would pose a significant barrier for a large swath of ngrok users. As some motivating evidence I can tell you:
I've had requests to support niche payment systems (whose names I can't even recall) because the country's credit card infrastructure is poor or not commonly used.
I've had a number of people tell me that their credit card wouldn't process because their provider is not supported world-wide.
ngrok is useful to students, some in high-school or even younger who surely don't have easy access to a credit card.
Sure, I could make those people email me with special requests to get around the system, but that greatly degrades the experience and moves initial experience from joy -> frustrating.
There are a number of possible technical solutions I would rather pursue first before greatly damaging first-time user experience and funnel.
If you want to have ngrok as a free public service, then abuse will be hard to get around while keeping it fully featured. However, to preserve the initial user experience you could allow the first 5 IP addresses to access the tunnel of unvalidated accounts. This should let them experience the full benefits themselves and/or with their friends or a few remote services and can keep using it with only those first 5 IP addresses. Afterwards, they can jump through extra hoops to remove restrictions. For example:
* Free plan: keep using it with up to 5 IP addresses. Rate
limited to 512 Kbps total.
* Lite plan: register by having us send you an SMS. Unlocks up
to 10 different subnets (allows the entire /24 or /16 etc.
network block based on whois lookup).
* Home plan: pay us $X and remove all IP restrictions. Up to 5
simultaneous connections at 512 Kbps per connection.
* Professional plan: pay us $Y and remove all IP restrictions.
Up to 15 simultaneous open connections at 1.5 Mbps each.
* Enterprise plan: need something custom? We're happy to put
together a quote.
This limits your exposure to abuse to the first 5 visitors without degrading the experience. Once that threshold is hit, you can response with a "429 Too Many Requests" type of server response, with a link to more info. You could also let users expire IP addresses/subnets, freeing up new connections from new IPs (with appropriate rate limiting). Successive levels of hoops, both free and financial, unlock additional benefits for those who want to pay for them.
Can you run your paying customers on a different system (preferably different host provider) to the free ones to prevent a ban triggered by the free users affecting the paying customers?
I won't disagree that putting a credit card form up is a barrier, principally because constructing barriers is the point of the exercise. Net-net, it strikes me as better to inconvenience a fraction of users predictably with mitigation in place versus inconveniencing all users unpredictably in a difficult-to-recover-from fashion when e.g. your hosting company sends you a termination letter.
By the way, since you mention you haven't worked in hosting before: you should know that you're at risk of getting your account terminated, even if you answer all tickets in a timely fashion. Every ticket opened against you represents multiple fairly highly-paid humans having to interrupt their work days. They accept this as a cost of doing business the first few times. You will eventually be told "You don't pay us nearly enough to generate this volume of tickets. Take your business elsewhere."
Anyhow, your business, ultimately your call. If you're looking to do primarily automated solutions:
1) Risk score customers. You can do this in intelligent, data-driven fashions, but you'll get results quicker by just coding heuristics. Some heuristics which you'll find valuable are "Where is the ngrok client getting called from? Does it come from a number of high-risk countries?" (I know, I know, most people hate the implications here but it is a case of being mugged by reality), "What OS are they using for the client application?", "Has the machine invoking the current ngrok subdomain been banned before?", "Does the subdomain receive traffic from 'far away' from the IP we're sending it to?", "Does the subdomain receive traffic from more than N IPs?", "Is there a large lag between creation of the subdomain and first use?", "Does an IP create multiple subdomains either in parallel or in series?", etc. You can easily make people's access increasingly open as their risk score approaches Presumed Safe and make it more restricted as their risk score approaches Quite Possibly Not Safe. (This is a nice compromise which lets legitimate users without a credit card in without-loss-of-generality China continue to get non-zero value out of ngrok.)
2) You may wish to have your client application fingerprint systems which it is installed on. (There exists substantial literature on this.) Add abusers' fingerprints to a hellban list: their IPs can see their sites, and maybe the first 3 IPs accessing their subdomain see it and get added to a bucket which shares their hellban, but everyone else mysteriously 500s out. This will make it hard for abusers to realize "Doh, I have been found out and need to switch proxies or rooted boxes."
P.S. Customer to vendor here: irrespective of your decision with regards to people who don't pay money for your services, please charge more. It will give you more resources to fix this problem so that you don't get shut down again and ruin my Twilio programming productivity.
I agree with @patio11, this seems like an amazing service that I can't wait to use now that I have discovered it, but similar to those running open proxies on the net and thus creating negative externalities for the rest of the web, you have a certain responsibility to block abuse before it is reported to the hosting provider.
Maybe something like Sift Science could help automatically create these heuristics. You could just modify your script to notify their systems every time abuse is reported, and it could learn the features of potential abusers.
> you should know that you're at risk of getting your account terminated, even if you answer all tickets in a timely fashion. Every ticket opened against you represents multiple fairly highly-paid humans having to interrupt their work days.
The solution is to SWIP the IPs to ngrok.
Then the provider is out of the loop. If it's a decent hoster I hope that's what he reccomends instead of just kicking ngrok.
A payment gate on ngrok would defeat the very essence of what the word "ngrok" came to mean. You Sir, have the greatest respect from me, and would agree that a technical solution is possible and conceivably orders of magnitude easier than the development of ngrok. On my things to do before I depart this world, is to understand how such a marvelous piece of software can be developed.
I've had requests to support niche payment systems (whose names I can't even recall) because the country's credit card infrastructure is poor or not commonly used.
I've had a number of people tell me that their credit card wouldn't process because their provider is not supported world-wide.
ngrok is useful to students, some in high-school or even younger who surely don't have easy access to a credit card.
Sure, I could make those people email me with special requests to get around the system, but that greatly degrades the experience and moves initial experience from joy -> frustrating.
There are a number of possible technical solutions I would rather pursue first before greatly damaging first-time user experience and funnel.