3 ms·

There is a service which gives you unlimited disposable credit card numbers, just ask your bank for it. You can't stop abuse against a time-based trial, so why

by Aldo_MX 12y ago

There is a service which gives you unlimited disposable credit card numbers, just ask your bank for it. You can't stop abuse against a time-based trial, so why use a time-based trial? I don't know your business, but you should consider designing an unlimited trial instead, if your service is good most people will eventually pay for it, or even better, someone else will pay on behalf of them. A prime example is Dropbox, when you purchase specific phone models you get extra storage, the user didn't pay for that storage, but someone else did (most likely the company who is selling the phone).

oneeyedpigeon 12y ago
Totally depends on your service. Some services easily lend themselves to some sort of 'unlimited free/paid improved' model - e.g. GitHub's number of repos. Others, however, are really difficult to shoehorn into that model, and a time-based trial is the best option - a 'content centric' service, for example.
nirvdrum 12y ago
I can assure you, abuse all but stopped when putting the credit card gate up. We tried all sorts of things with the trial over our 5 year tenure. Way too much time went into dealing with abuse. In our case, it was a visual web testing service. When someone is abusing the service, another person can't use those browsers. Adding more machines might be scalable if you've raised money, but if you're bootstrapping (as we were) there's a very real ceiling to what you can afford. We were running well above the capacity needed for legitimate usage, at our expense, and still had problems stemming from Mailinator traffic. Maybe other companies have a different experience and Mailinator users turn into loyal, paying customers. In our case, they did nothing but waste resources (both computing and human). And in 5 years, not a single one turned into a paying customer, yet many were happy to leech over extended periods of time (we could see the sites being tested, so tracking it was fairly straightforward). I admit, it was weird being able to classify one whole source of traffic as simply negative, but we had the data to back it up. And just to clarify, abuse is being used in two contexts here: 1) people trying to use the service indefinitely without paying for it; and 2) people trying to actually DoS other sites, screw up our browser cluster by firing up pop-ups and print dialogs, and other general scumbaggery.
Aldo_MX 12y ago
@nirvdrum: I can't reply to you directly, probably because of the downvotes, but anyway... My point is that when you design a trial, you should look for constraints that are more difficult to abuse, and also more valuable for a user, and definitely "1 month of service" is neither difficult to abuse, nor valuable for a user. If you found a solution in requiring CC details on signup, it's OK, but that was just a temporary cure to your illness of having a time-limited trial. It's not the fault of mailinator, nor the fault of banks, is the fault of wanting to have one (trial) account per person. South Korea even takes the extreme approach of requiring social security numbers to guarantee that every account reflects one (korean) person, yet it is trivially easy to find stolen databases of schools and companies, and many forums, especially gaming forums even recommend you to commit identity theft to play an online korean game. Not even companies like Amazon, Google, Microsoft, etc. can save themselves from complex abuse techniques like stolen CC's, generated and valid CC's, disposable CC's, etc. You can pretty easily find news about massive DDoS attacks generated from their clouds using these techniques. Regardless of how much effort you have spent dealing with abuse, if you are only playing wack-a-mole, you are just wasting your time. I know it is easier said than done, but probably adding a proxy to do throttling, enforce global limits to free users (ex. domain + ip per hour/day), and stopping/reporting DoS attempts would had been a better investment than trying to prevent users from using Mailinator.
- nirvdrum 12y ago
  We're going in circles, so this will be my last comment on the matter. In our experience, over an extended period of time, there was virtually no legitimate use originating from Mailinator users. Maybe it's a fantastic service for others. For us, it was hands down the biggest source of abuse. It would be extremely difficult for anyone to convince me of its legitimacy in the face of the data we saw over a prolonged period. And it's not even that Mailinator users would sign up, try it for 30 minutes, and then just move on. In that case, I'd just say they weren't qualified, didn't like the service, didn't find the value prop, whatever. But that's not what happened. I don't really think the "you're going to get screwed, so just learn how to get screwed" attitude is really appropriate. There have been a few armchair theories on how we should have dealt with the issue. Suffice to say, 10 paragraphs of text here aren't going to enumerate everything we tried. And it's not as if we made no product improvements in that period either. Simply put: if you don't want to use the service, great. If you don't find it valuable, that's fine too. But no one's taking the high road trying to perennially use a service without paying for it, meanwhile calling it a quality issue. And none of this is abstract. We tried all sorts of technical solutions. People just found another way to abuse. We slapped the credit card gate up and had not a single Mailinator signup for the 2 years after that. It simply solved the problem. Maybe someone will up the ante with fake credit cards . . . for us, we found thousands of Mailinator users weren't willing to take that step.

by Aldo_MX 12y ago

oneeyedpigeon 12y ago

Totally depends on your service. Some services easily lend themselves to some sort of 'unlimited free/paid improved' model - e.g. GitHub's number of repos. Others, however, are really difficult to shoehorn into that model, and a time-based trial is the best option - a 'content centric' service, for example.

nirvdrum 12y ago

I can assure you, abuse all but stopped when putting the credit card gate up. We tried all sorts of things with the trial over our 5 year tenure. Way too much time went into dealing with abuse. In our case, it was a visual web testing service. When someone is abusing the service, another person can't use those browsers. Adding more machines might be scalable if you've raised money, but if you're bootstrapping (as we were) there's a very real ceiling to what you can afford. We were running well above the capacity needed for legitimate usage, at our expense, and still had problems stemming from Mailinator traffic. Maybe other companies have a different experience and Mailinator users turn into loyal, paying customers. In our case, they did nothing but waste resources (both computing and human). And in 5 years, not a single one turned into a paying customer, yet many were happy to leech over extended periods of time (we could see the sites being tested, so tracking it was fairly straightforward). I admit, it was weird being able to classify one whole source of traffic as simply negative, but we had the data to back it up. And just to clarify, abuse is being used in two contexts here: 1) people trying to use the service indefinitely without paying for it; and 2) people trying to actually DoS other sites, screw up our browser cluster by firing up pop-ups and print dialogs, and other general scumbaggery.

Aldo_MX 12y ago

@nirvdrum: I can't reply to you directly, probably because of the downvotes, but anyway... My point is that when you design a trial, you should look for constraints that are more difficult to abuse, and also more valuable for a user, and definitely "1 month of service" is neither difficult to abuse, nor valuable for a user. If you found a solution in requiring CC details on signup, it's OK, but that was just a temporary cure to your illness of having a time-limited trial. It's not the fault of mailinator, nor the fault of banks, is the fault of wanting to have one (trial) account per person. South Korea even takes the extreme approach of requiring social security numbers to guarantee that every account reflects one (korean) person, yet it is trivially easy to find stolen databases of schools and companies, and many forums, especially gaming forums even recommend you to commit identity theft to play an online korean game. Not even companies like Amazon, Google, Microsoft, etc. can save themselves from complex abuse techniques like stolen CC's, generated and valid CC's, disposable CC's, etc. You can pretty easily find news about massive DDoS attacks generated from their clouds using these techniques. Regardless of how much effort you have spent dealing with abuse, if you are only playing wack-a-mole, you are just wasting your time. I know it is easier said than done, but probably adding a proxy to do throttling, enforce global limits to free users (ex. domain + ip per hour/day), and stopping/reporting DoS attempts would had been a better investment than trying to prevent users from using Mailinator.

nirvdrum 12y ago
We're going in circles, so this will be my last comment on the matter. In our experience, over an extended period of time, there was virtually no legitimate use originating from Mailinator users. Maybe it's a fantastic service for others. For us, it was hands down the biggest source of abuse. It would be extremely difficult for anyone to convince me of its legitimacy in the face of the data we saw over a prolonged period. And it's not even that Mailinator users would sign up, try it for 30 minutes, and then just move on. In that case, I'd just say they weren't qualified, didn't like the service, didn't find the value prop, whatever. But that's not what happened. I don't really think the "you're going to get screwed, so just learn how to get screwed" attitude is really appropriate. There have been a few armchair theories on how we should have dealt with the issue. Suffice to say, 10 paragraphs of text here aren't going to enumerate everything we tried. And it's not as if we made no product improvements in that period either. Simply put: if you don't want to use the service, great. If you don't find it valuable, that's fine too. But no one's taking the high road trying to perennially use a service without paying for it, meanwhile calling it a quality issue. And none of this is abstract. We tried all sorts of technical solutions. People just found another way to abuse. We slapped the credit card gate up and had not a single Mailinator signup for the 2 years after that. It simply solved the problem. Maybe someone will up the ante with fake credit cards . . . for us, we found thousands of Mailinator users weren't willing to take that step.