Build a burner phone with Twilio and Kotlin
twilio.com
twilio.com
Then it's not anonymous, "mostly" or otherwise.
Any entity that is either subject to CALEA, or behaves as if it's subject to CALEA, is not your friend.
Note that Twilio, although not subject to CALEA, still behaves as if it is, bending over backward to honor any and all "lawful requests" for customer information, and requiring PII on account signup: https://www.twilio.com/legal/law-enforcement-guidelines
How utterly unreasonable. Yeah, the man is totally trying to keep you down through Twilio.
If you accept that anonymity isn't a purely true/false proposition, which you are doing by using the word "mostly," having your identity only available to law enforcement after a court order has been issued seems like a textbook instance of "mostly anonymous."
or after a security breach...or after access by a third party without a court order (however unlawful it might be)...
It's still fine to say Twilio is "mostly anonymous," and objecting to that - that Twilio is "mostly anonymous" - on the basis that law enforcement can find out who you are with a court order is very silly. As if a service that requires due process of law to uncover any information about you is morally or practically equivalent to having your name and address in the white pages.
edit: by the way, I never said '"anonymous" simply means it's not listed anywhere'
That being said, burner doesn't mean anonymous. Burner means disposable. Obviously you're not going to dispose of your account, application, and server every time you're done with the number.
It's also not even a phone. I guess its a phone application in the most minimal sense of the word..
But I agree with kchr in principle. "Burner" may not mean anonymous but it's more often than not associated with anonymous and anonymity. It's the go-to perception or association if you will.
So I think kchr and I are saying the same thing: the article is using the burner/anonymity context as a little click-bait IMO and it's not a big deal but it's a valid point.
On the flip side, there are already companies out there specializing in monetizing misdials. They specifically look for phone #s that have been retired recently with a lot of volume and then take those calls and resell as leads for cars, insurance, etc.
Agreed on the challenge of working with a fixed number of phone numbers (and I say this as someone who recently moved to NYC and would love to own a 212 number).
In the industry, phone numbers that have a high-volume of unwanted traffic are called "dirty numbers." Think of a number used by someone who signed up for every sweepstakes they came across for 40 years, or maybe a number that's particularly cute (you probably don't want to have a cellphone tied to XXX-867-5309).
If we sold them, dirty numbers would be worse-than-useless for (almost all) of our customers. So, whenever a phone number is released by a Twilio customer, we reserve it for a minimum of two months before it can be purchased by another account. We also monitor each reserved number until it reaches an acceptably low number of phone calls.
If you do find yourself getting unwanted calls, you can use the <Reject>TwiML verb[^1] to create a blacklist - your account won’t receive or be charged for those calls.
We have a similar challenge in working with the fixed number of IPv4 addresses we're able to get our hands on. We offer our customers dedicated IP addresses for outbound email, but there are sometimes situations where a customer doesn't want to hold onto one forever.
We want to make sure mailbox providers (like Gmail and Hotmail) have time to realize the IP is not in use, rather than mistakenly associating it with the old customer. It makes sense to hold onto it for a while after the customer releases it before allowing another customer to purchase it. We call this the "cooldown period."
Microsoft does use the range of black holes, e.g. Spamhaus, including using their own, so etjossem is right about having to cool down a bad IP before requesting whitelisting. Almost all ESPs and black holes will reject whitelisting requests without a sufficient cool down period anyway.
Gmail is certainly ahead of its time. I haven't tried sending with IPv6 addresses but the Gmail documentation claims it will work.
Could Twilio not arrange for a new "country code" to be assigned, possibly to an industry working group of some kind, and then make the numbers ~64 digits long? Then there should be more than enough to go around and to discard dirty numbers, and the numbers could always be made larger in the future if needed?
https://en.wikipedia.org/wiki/North_American_Numbering_Plan
If you are way, way bigger than Twilio you can create a country code. Country codes exist for special purposes like the Iridium satellite phone network. But you cannot just create a country code for arbitrary purposes and expect it to work with the world's PSTN/SS7 infrastructure, any more than you can choose an arbitrary non-RC1918 /8 of IP space and start using it on the public Internet.
Is there a VoIP trade association they are all members of? If so, the trade association would be big enough to push for a new country code for the special purpose of software-based telephony just like Iridium has one for satellite-based telephony.
If that fails, Iridium is struggling. That hypothetical trade association could acquire the country code from Iridium with special agreements to ensure that Iridium still can lease numbers for no-cost for satellite-phone purposes.
Why not disclose prior call patterns before selling the # rather than putting the burden on developers to flag spam to receive credits?
Saving a couple of cents by getting reimbursed for the call doesn't actually solve the issue when your team is wasting their time picking up the phone only for it to be a misdial or spammer.
The same can't be said for my physical POTS/cellular numbers.
Anecdote of one, and everything, but has anyone actually impactful levels of spam from an insufficiently cooled number that they wouldn't have had from any number in the area code?
Wholeheartedly agree that the burden is ours -- not the developer's -- to make sure a number is clean before you buy it. We monitor inbound activity for two months before making a number available for sale. <Reject> is not for spam that comes with a number when you buy it -- it's for all the stuff that happens after you put that number out in the wild.
More than that though, we can't reveal historical patterns because we'd be violating the privacy of whoever previously owned the number.
Strange - almost every number I put into this UI (friends, family, etc.) comes up with:
"caller_name": {
"caller_name": null,
"caller_type": null,
"error_code": null,
},
Another problem with twilio numbers is that they are not mobile numbers. The reason that is a problem is that two factor authentication and other security measures are very often sent from mobile short codes and not from another actual phone number.
And no twilio number can receive any SMS from a short code. It's not possible, since they are not mobile numbers.
This means that you cannot use a twilio number for google products like gmail or google play store - you can never receive the challenge/auth numbers.
Or, better yet, not bothering to "activate" it, but using it only over Wi-Fi, creating a new Google account, and downloading Talkatone (or the Hangouts Messenger to create a Google Voice account connected to your new account)?
Not a silly question at all. Developers certainly have a propensity to recreate the wheel for the sake of recreating the wheel -- though I think that many of us would agree that the act of creating is itself the advantage.
That said, a few things:
1. Costs less. A Twilio phone number is $1 per month (in the US). A minute of calling costs $0.01.
2. You can get a new number any time you want.
3. You get to write code.
Don't want to speak for Marcos (though he happens to be sitting 10 feet from me at the moment), but my guess is that what excites him most about writing this post isn't that other developers will copy it line for line. It's that they'll use it as a jumping off point -- that it inspires and equips developers to ship their own inventions.
For an example of this, check out the folks at Burner app who used the similar concept (pre-Kotlin) to build an entire business around this idea.
[1]: https://www.twilio.com/blog/2012/08/burner-app-offers-alias-...
This assumes no pooling. With pooling you might need 4 numbers, as the driver could have up to 4 separate passengers they want to contact.
Still looks like a fun project.
I also don't know how this is any different from, say, Google Voice?
Sure, state actors will probably still be able to track you. But the weirdos on Craiglist and the spammers that scrape it won't.
I save numbers for 2nd factor auth, and I seem to get yahoo/msft messages from the same numbers, also github sometimes. Number reuse is definitely a problem. A PKI cert system for numbers/calls would be great to have in this case. I want to know for sure that I'm getting my 2nd factor auth code from msft, regardless of the number they're using.
From other VoIP providers, you can get that pretty easily. I use voip.ms and they charge $4.25/mo for a number and unlimited incoming.
If you only want a number for a month, thats $1.
Leaving $3.25 worth of calls at $0.05 (0.01 incoming, 0.04 back out to your cell) a minute forwarded to a mobile to match. Over an hour of calls, which I wouldn't hit on a gumtree advert.
That $4.25 presumably doesn't include the outbound leg, does it?
Twilio also do SIP registration, so you can route calls to your handset via SIP even more cheaply. (0.004 for outbound, so 0.01 and 0.004, for over 3.5 hours for that $3.25.
There are definitely usage cases for unlimited, but I don't think this is necessarily one of them unless you have a ridiculously high call volume. At that stage, I'd just use the voicemail to email Twimlet and bounce everyone into that.
Twilio - 0.0125 in 0.017 out
voip.ms - 0.09 in 0.005 out
Of course, the unlimited plan is only useful for a select few - if you want to plug it into your PBX and use it as a small support line (could be this case) or if you're making nightly calls for a few hours to relatives or a significant other, it's quite possibly worth it.
Depends what you're going to use it for and if you want that Twilio API really. If you just want a SIP number, it's pretty clear, but if you want all those nice API features and don't need super high volume, Twilio is probably the way to go.
Although there's something to be said for Twilio for straight up SIP too if you've got awkward fucking hardware. The Gigaset N300 is great, but the dialplan options are embarrassingly limited.
Twilio offer their own hosted Node.js (Twilio Functions - BETA) and TwiML Bins (free super-basic TwiML hosting with basic moustache templates for simple variable insertion.)
Pretty sure the whole project in the OP could have been done quicker and easier using Twilio Functions, but I get that it's more of a learning tutorial and example.
I use a combination of TwiML Bins, Functions and Twimlets to quickly chain together powerful functionality. And to work around the N300 dialplan limitations!
Edit: https://support.twilio.com/hc/en-us/articles/230878368-How-t...
https://support.twilio.com/hc/en-us/articles/115007737928-Bu...
Totally understand the concern there, especially since you're already paying for your cellphone.
I did something similar a couple years ago when we were shopping for a car. A lot of car shopping sites are basically lead generators for dealerships and you need to provide a number to get real info. I used a Twilio number forwarded to my cellphone.
The deluge of calls started immediately. After 48 hours, when we had all the information we needed, I released the Twilio number and incurred no further charges.
Total cost was $1 (per month) for the phone number and $0.01 per minute for the inbound calls. Upside was that my phone stopped ringing the moment I was done talking to salesmen.
Or is your comment about sales versus engineers?
If their salespeople know how to fire up a little endpoint in kotlin using their API that's fantastic.
At some point a few years back, my VW dealership sold my phone number to people for vehicle service contracts. Even though I sold that car 4 years ago, I STILL get at least 2-3 calls per week from different companies offering to sell me an extended warranty. How does Twilio mitigate that for us?
(Off topic, but seriously, thanks for Twilio. Ping me if you want to know how we're using it in our new startup [email in profile]. It's pretty rad.)
Just wrote a lengthy reply to this concern up above, but the tl;dr is that we sit on all numbers for at least 2 months and wait until there's an acceptably low amount of inbound traffic before releasing them back into the available number pool.
Would love to hear how you're using us. Will drop you an email. (And thank you!)
This isn't really a burner phone as the Twilio link I clicked asked me for a bunch of personal information first.
Code for 20 extra credits if you check it out: INV-DKCSGJHX
Privacy is incredibly important to us. You can delete the logs of any call or message that you don't want residing on our servers.
https://www.twilio.com/blog/2014/11/introducing-delete-api-n...
Soft-deletes, which the blog indicates that you are doing, is very different from actual deletion.
To make the distinction clear, if a log of a call or message is deleted, can it be given to law enforcement? If so, it's not truly deleted.