Earlier quoted context omitted.
Why should Twilio do this when nobody else does?
Keeping their traffic clean makes it easier to interconnect, and in an ideal world, they want to interconnect with everyone
Twilio’s toll fraud problem
141–150 of 221 posts
Re: Twilio’s toll fraud problem
#142We've been hit by this at work as well. We had to add CAPTCHA and a several other techniques to defend against this. How it works: 1. Attacker leases 1 or more premium rate numbers in an international country. - Attacker can lease a premium rate number for as little as $10/month - Typically, the attacker gets to keep 70% of the money generated by the premium rate number. 2. Attacker then finds companies with OTP (One…
Some of the criminals behind these attacks will have access to the phone network. They'll pick an expensive route, like a range of phone numbers in Georgia (the country) from the USA, and offer a cheaper route to it. The system will start using their route for those calls. They'll accept all calls to that route, get paid, and never actually connect any calls.
That gives them a range of "normal" phone numbers which helps them avoid throttling on just one number. But they can be just as expensive as premium numbers to call.
At least, this is how it was explained to me as my team fought these attacks a couple years ago. We'd see calls to a large range of a few thousand numbers. Couldn't throttle on a single number.
Re: Twilio’s toll fraud problem
#143Earlier quoted context omitted.
>Your only power to encourage them to fix this is to do the thing they're begging you not to: dispute the charges. I'd check their TOS to see if they offer some kind of arbitration option. As noted in other threads, triggering that process can be a surprisingly effective way to make someone from the company actually engage with the issue. Disputing the charges is always a nuclear option. They may never do business wi…
> Disputing the charges is always a nuclear option. They may never do business with you after that. This is something that I think needs to be regulated. I'm not saying that this should be the case for a company the size of Twilio, but I definitely think that a company the size of Apple/Google/Samsung should not be able to ruin your life because you had temerity to stand up to them and dispute a charge.
Re: Twilio’s toll fraud problem
#144We've been hit by this at work as well. We had to add CAPTCHA and a several other techniques to defend against this. How it works: 1. Attacker leases 1 or more premium rate numbers in an international country. - Attacker can lease a premium rate number for as little as $10/month - Typically, the attacker gets to keep 70% of the money generated by the premium rate number. 2. Attacker then finds companies with OTP (One…
I am curious if the Twilio 'lookup' API call will identify it as such:
/usr/local/bin/curl -s -X GET "https://lookups.twilio.com/v1/PhoneNumbers/$number?Type=carrier&Type=caller-name" -u $accountsid:$authtoken | /usr/local/bin/jq '.'
... which would be a very fast and simple way to validate a number before you (or your process) use it ...Re: Twilio’s toll fraud problem
#145Isn't this something Elon Musk brought up a few weeks ago when Twitter SMS 2FA stopped working in some countries? (India? I think?). On a Twitter spaces he said they were losing millions to SMS fraud for years and found out that some Telecom companies were complicit so they just cut off all SMS traffic to those companies until they re-negotiated terms.
Last time I tried to sign up for Twitter it demanded I verify my account with text messages. Actually, virtually all services do this now when creating an account. The worst (Microsoft for example) let you sign up and use the account for a bit (possibly purchasing some items tied to the account) and then extort the phone number out of you later to maintain access. It is sort of amusing that these companies hitched th…
Re: Twilio’s toll fraud problem
#146My impression at the time was the fraud detection heuristics helped, but the root cause was scammers working with telcos overseas. Many of these companies have extremely high rates in the first place, and turn a blind eye to the practice because it makes them much of their money.
Some VoIP providers like Twilio may be the same. As a middleman / carrier, they will always profit from traffic on their network, even if they disavow it as fraudulent and wag their finger at you about it.
Re: Twilio’s toll fraud problem
#147I loved Twilio many years ago, but they've become the new Google/SendGrid/Shopify/Stripe/Uber/(soon to add CloudFlare). They retain the right to any/all the upside of any risk/scale, and you retain the obligation in any downside. No questions. It's despicable.
I did as well.
In fact, I built my own little personal telco around their services and API.
It is all slowly falling apart, however, as their failure to build out their infrastructure offerings (as opposed to their "customer engagement" offerings) and the regulatory SNAFUs[1][2] that are emerging as a result of their behavior erode all of my use-cases ...
All I wanted was more, and more useful, twiml verbs ... instead I got "customer engagement workflows".
[1] https://twitter.com/rsyncnet/status/1593384850073214976
[2] 10DLC A2P makes personal/hobbyist Twilio usage basically impossible (although mine continue to work ...)
Re: Twilio’s toll fraud problem
#148I find it particularly frustrating that they force you to upgrade to Verify to solve the problem unless you want to build out a lot of your own internal risk detection (which we ended up doing instead) With the rise of AI APIs, I expect we'll see similar attack vectors for apps that integrate APIs from OpenAI or Stability. There won't be a colluding telecomm, but the API output (a completed task) is relatively fungib…
Consider installing a device fingerprinting system -- this has be the single most effective solution we've seen our customers integrate for more sophisticated bot problems: https://stytch.com/docs/fraud#device-fingerprinting. I'd recommend against the off-the-shelf solutions (e.g. open source ones) because many of them are easily reverse engineered, so they work well for low-level threats but not for persistent ones. In addition to our solution, Arkose and Fingerprint Pro are a couple ones I'm aware of
Re: Twilio’s toll fraud problem
#149Earlier quoted context omitted.
Same here! So, i wonder then, who would be a viable alternative to Twilio?
Hey! I'd naturally recommend SignalWire (as one of the founders over there.) We have a full messaging + voice + video APIs, including a Twilio-compatible API just for people who need to switch. We're backed by companies like Deutsche Telekom, T-Mobile, and Samsung so we know how to make telecom infra! https://signalwire.com/products/cloud-messaging We're also the folks behind the open-source FreeSWITCH framework that…
Do you have a god-damned email verb for twiml ?
I mean, seriously. Twilio could allow (verified-ownership emails only) for the simplest possible email integration into twiml for the sole purpose of alerting and paging, etc.
No spam possible since it's only verified account-controlled emails. Basically sending email to yourself from within twiml.
But no. Instead they bought sendgrid and email integration is a complete abomination of a two-company, two platform, two accounts workflow that is fragile and fails all the time.
So ... do you ?
Re: Twilio’s toll fraud problem
#150Earlier quoted context omitted.
I'm surprised/confused: Why is it hard to detect premium rate numbers, or at least set a flag to not allow sending to them? Like, I can't think of a time when twillo should ever be sending to a premium rate number; why is this even possible?
There are 200+ jurisdictions in the phone network and everybody has their own conventions on what a "premium" number is. For comparison, imagine if each domain in the world could set its own rates for much doing a DNS query would cost you, and governments regulated this only by designating a few second level domains as "premium". That's pretty much the scale of the problem. Edit: To be clear, this is a very well know…