> Servers: $2.9 million dollars per year.
> Registration Fees: $6 million dollars per year.
> Total Bandwidth: $2.8 million dollars per year.
> Additional Services: $700,000 dollars per year.
Signal pays more for delivering verification SMS during sign-up, than for all other infrastructure (except traffic) combined. Wow, that sounds excessive.
https://www.cnn.com/2023/02/18/business/twitter-blue-two-fac...
My wild guess is that either the stack is not really optimal (last I heard it was java) or they do other costly things at scale (sgx?)
Bonus: Session does not demand users' phone number. Also no bundled cryptocurrency.[1]
My mom was able to get our entire extended family on Signal without my involvement, which is a testament to how easy that is.
Not whether that's a good idea is more debatable; you're not wrong about discoverability.
They are near-ubiquitous on a per-user level, but hard to accumulate without significant cost. (Unlike email addresses.)
But the down side is that phone verification tends to be on a per-service level. So, for instance, Signal incurs these costs when they verify their users, and every other service incurs these same costs when they verify _their_ users.
There are a number of businesses out there that are trying to act as clearinghouses, where they verify the users once, then allow the users' verified profiles to be confirmed by multiple services.
I wonder if any of those could be used to reduce these "registration" costs.
Moving off cloud services to lower-cost provider like Hetzner, Vultr and DigitalOcean might provide a lot of cost savings.
I also imagine they're using managed SMS services from one of these clouds, and moving off them to a combination of local SMS gateways in each country can also further reduce costs (and in one case I've personally observed, by upto two orders of magnitude). This obviously pushes a lot of complexity on Signal's side, but is usually worth it.
It seems like Session relies on Oxen's network, so while there is no inherent coin it is blockchain backed.
> Session’s onion routing system, known as onion requests, uses Oxen‘s network of Oxen Service Nodes, which also power the $OXEN cryptocurrency. Check out Oxen.io to find more information on the tech behind Session’s onion routing.
That'd be all well and good... the technology would die naturally, but all my American relatives continue to stubbornly use iMessage.
For P2P communication. SMS is alive and well for B2C messaging, most importantly for 2FA OTP delivery, but also as a first line of defense against spam/bot account creation.
It's not a good solution to either problem, but it's slightly better than nothing (which apparently makes it good enough for many), so I suspect we're stuck with it for now.
> That'd be all well and good... the technology would die naturally, but all my American relatives continue to stubbornly use iMessage.
iMessage is not SMS, though. It just uses phone numbers as identifiers, but so do many other popular over-the-top messengers, including the most popular one globally.
Every actual Java project: “oh, did you want that memory and those cycles for something else? Yeah, sorry, I need them all. Why no, I’m not actually doing anything right now, why do you ask?”
Edit: I meant moving off cloud to Hetzner, Vultr, DigitalOcean.
I know this will invite comments about usernames. I would like usernames a lot too.
They stopped doing that (and I uninstalled Signal as a result), so they can also stop with the phone number thing, in fact, it would make more sense than with the current situation where Signal needs a phone number but doesn't use it (except for registration). I could even reinstall Signal if they do this.
Increasing the Java heap size just makes it so that when garbage collection eventually hits, it causes an even more massive slowdown across the entire application.
I've got an Android phone so all iMessage transmissions come across as SMS (or MMS).
In most countries, you can get an anonymous phone number anyway.
There are opensource self hosted solutions like BlueBubble that allow reasonably secure communication through iMessage to the other chat platforms on desktop/Android etc. I have zero affiliation, but I know others who happily use it. There are also less secure and paid solutions I can't speak to.
Personally, I prefer it over downloading yet another client, dealing with additional credentials, wondering about who can access my messages, and so on and so forth…
And all that just to message the handful of people that I know who use <popular in other country third party app>.
If I want discoverability, let me provide my phone number.
If I want privacy, just assign a random identifier.
The iOS application is called "Messages"; iMessage is the over-the-top Apple-exclusive messaging service.
In the US, that's effectively zero due to the US phone infrastructure largely using a shared-cost model, but in most other countries which use "sender pays", these fees can be significant.
It's also not a great idea to make sign-ups for an instant messaging service contingent on having an account with another, competing service.
> Service A => User: Please Enter Your Phone Number and Email
> Service A => Clearinghouse: Please verify phone number XXX wants to sign up for an account with us
> Clearinghouse => User (SMS): Please respond with the Email you used at signup to confirm you want an account with Service A
Later...
> Service B => User: Please Enter Your phone number and Email
> Service B => Clearinghouse: Please verify phone number XXX wants to sign up for an account with us
> Clearinghouse => User (Email): Please verify you want an account with Service B
Not saying it's great (providing email twice is annoying), but it's something.
But hey, they still want your whole address book, and announce you're on signal to everyone else on signal.
The whole "secure" thing is a joke. Its all linked to your identity via your phone#.
1. https://www.wsj.com/articles/why-apples-imessage-is-winning-...
Previous Twitter employees have said that this is incorrect. Because Twitter began as an SMS-only (and then SMS-first) application (remember 40404?), they very early on established direct-connection infrastructure for sending SMS, meaning that they have a marginal cost of literally $0.00/message in most markets. Twitter still has to maintain that infrastructure, because they didn't get rid of SMS 2FA - they just restricted it to Twitter Blue users, so the overhead is still the same.
Almost nobody else who delivers SMS today has that infrastructure, because it doesn't make sense for most services to build.
The only place where Twitter was paying significant amounts for SMS was due to SMS pump schemes, which is a consequence of Twitter gutting its anti-spam detection, resulting in them paying for SMS pumping which was previously blocked.
Absolutely they are. Most of my friends and family are Pixel users and we all communicate using RCS. If Apple would just support the modern replacement for SMS (which includes end to end encryption), iPhone users would be much safer and would have a better experience.
Bullies will bully. Targeting the articles of bullying versus the source is fruitless; the former is unlimited.
Nobody wants this. Universal access means universal access for spammers. iMessage won over SMS because of cost and spam filtering.
RCS is an open standard that any carrier/OS/messaging app can support, unlike iMessage, which is exclusive to iPhones.
Many startups move up to the jam when there is little else that has optimized performance and efficiency like the jvm for 20-30 years.
Of courses this is a moot conversation if you’ve never used Java at scale. Apple and others are Java houses.
Sending mass email is still difficult. Its probably easier to pay a provider than set up and establish reputation for yourself. But they don't charge near the rates. Last time I compared rates it was something like 10x-100x to send an sms compared to an email, but it has been a while.
The loaded costs should have the numbers run.
It would be a fascination under the covers look with signal.
It apparently just doesn't work with dual-SIM phones, requires a phone number and an active plan with a supported operator (at least iMessage lets me use an email address!), the multi-device story is non-existent, to just name a few.
Telephone numbers are fundamentally incompatible with privacy. Signal's leadership knows this, but they don't appear to care.
Using my phone number as an identifier and authentication factor for so many things these days is bad enough; I really don't want the messaging layer itself to touch my phone provider at all.
$7m Twilio
$4m Microsoft
$3m AWS
$1.3m Google
https://projects.propublica.org/nonprofits/organizations/824...
I am very, very interested to understand how that works, because without more detail or sources I'm calling bullshit. I definitely understand how Twitter could have greatly reduced their per-message fee with telecom providers, but at the end of the day Twitter is not a telecom and is still at the mercy of whoever is that "last mile" for actually delivering the SMS to your phone, so I don't understand how they have no marginal cost here. Happy to be proven wrong.
Not nobody.
> iMessage won over SMS because of cost and spam filtering.
Really? I've never used imessage.
I'm not mad at all if somebody prefers using their phone number and not having a password for a service – just give me the option to use my email address and/or a username.
There are too many "phone number only" services out there these days.
My preference would be that Apple drop SMS support from Messages all-together and market it as an iOS only communication method. People with iPhones would then have to pick some alternative, perhaps they would use Signal or perhaps something else.
I already have to install a handful of applications to talk to all of my friends and co-workers, at least I wouldn't have to continue to use SMS.
RCS is exactly what it says on the box: A modern successor to SMS. That does not make it a good modern instant messenger.
So sending 1 costs the same as sending a 10 million. It isn't that they are free to send, its that they are charged for access to the system, but aren't charged per message.
No one wants to support it. Even telecoms don't want to support it.
(And even Google doesn’t really have any love for RCS, they crawled back to it as a fallback plan with their tail between their legs when their own proprietary lock-in messaging apps didn’t work out. Which makes their attempts to shame Apple into adopting it pretty hilariously disingenuous.)
Within the scope of messaging network effects, nobody.
> Really?
Yes. iMessage spam is rare and stamped out fast. Open protocols tend to have spam problems the moment they begin scaling.
You can push Java very far.
Of course you can also write horribly ugly code in it.
Why is the security a joke? The data is e2e encrypted, and isn't related to a phone number in any way after registration. Do you know of a better way of combining privacy and anti-abuse measures? If you don't offload identity checks to telecom providers during registration some bad actor will immediately create a million accounts and send millions of spam messages and destroy the slim chance of this type of app to exist for free.
Dramatic exaggeration and attribution of evil intent is counterproductive and disingenuous.
I worked on an automated SMS marketing system back in the day so I have seen this in action, at scale. This would be stuff like "text LAKERS to 12345 for Lakers updates"- we didn't handle the Lakers but we did handle many sports teams. Though I wasn't privvy to the financial side, I got the sense that the per-text cost ended up being manageable at scale, but this is because we were one organization who would apply the rules onto our own customers, and if we failed to do so properly we risked losing the interconnects to the various carriers. We typically used a single contracted "aggregator" service which provided a unified API for the carriers. When I left, we were using OpenMarket.
When you have a self-service SaaS offering such as Twilio, the per-text costs are going to go up because the barriers for sending unwanted texts (or fail to follow the rest of the rules mandated by the TCPA) is so much lower, and Twilio has to address that organizationally which adds cost.
Additionally, Twilio does not purchase short codes (ie 12345) which means its harder for the carriers to track bad behavior across their network. There is an initial cost (fairly high) to acquiring a short code, though you can also share short codes across customers in some cases. Acquiring a single short code and sending all messages from that short code would likely reduce costs.
I would love to see more detail from Signal about what sort of SMS interconnection they are using, because directly connecting with an aggregator instead of a SaaS offering (if they haven't already) could save a lot of money, and they are definitely at the scale that would allow for it. And given that they only use it for account verification and are a non-profit, it seems likely they could get a good deal since the risk of TCPA violations is effectively zero.
Some of these will be willing and able to pay $1/month to Twilio for a workaround, but most probably won't.
My carrier charges an arm and a leg for international texting, and if distinguishing between texts and iMessages wasn't as easy as it is, I would probably have to pay hundreds in carrier bills at least once.
I supported a marketing platform for a while, and it was so much easier to send an email than an sms.
... legacy telecom operators have realized that SMS messages are now used primarily for app registration and two-factor authentication in many places, as people switch to calling and texting services that rely on network data. In response to increased verification traffic from apps like Signal, and decreased SMS revenue from their own customers, these service providers have significantly raised their SMS rates in many locations, assuming (correctly) that tech companies will have to pay anyway.
...
These costs vary dramatically from month to month, and the rates that we pay are sometimes inflated due to “toll fraud”—a practice where some network operators split revenue with fraudulent actors to drive increased volumes of SMS and calling traffic on their network. The telephony providers that apps like Signal rely on to send verification codes during the registration process still charge their own customers for this make-believe traffic, which can increase registration costs in ways that are often unpredictable.
This is not how SMS pricing works in many, if not, most countries.
Here is more information about what I meant when I used the term "bundled".
I was on the support side, so I just saw when it went wrong, which was a lot.
Intentionally ignoring the fact that Signal splatters your phone number to everyone else is a humongous problem. And you can even put your phone number block in your address book, and it'll tell you everyone who has Signal. This happens all the time, with Signal servers leaking all of this metadata.
And doing "engagement promotion" is what companies do to sell more shit. So, exactly what are they "selling"?
>Why is the security a joke?
Metadata, pertaining to communication patters and to whom matters just as much as what's being said.
And that metadata, like "your phone number" and "contact's phone number", and "when data is being sent to/from" is that metadata.
> The data is e2e encrypted,
> and isn't related to a phone number in any way after registration.
Bullshit. I see new people hopping on signal fairly regularly. If that was true, it'd be a simple verify-once-and-delete. It aint.
> Do you know of a better way of combining privacy and anti-abuse measures?
I reject your claim of "privacy", with regards to metadata.
Secondly, Tox has an alternate way to handle this, by allowing any number of accounts not tied to anything. Sure, it's a SHA256 id, but who cares. There, its secure AND anonymous.
Basically, I look at Signal as "better than SMS, but not much". It's basically a way to keep the phone company from scanning messages.
Any chance at all it has something to do with the fact that they've acquired an RCS infrastructure provider that they can sell to telcos?
The clearing house verifies you only once, or once a year, instead of every time. If the clearing house were to be a nonprofit, perhaps even set up by Signal themselves to spread costs with similar services, that has to be cheaper.
It also gives users confidence that only a randomized user ID was shared, so it won't be used for cross-service correlation and tracking, if the service didn't actually need your phone number but only some identifier.
For what it's worth, they've worked tirelessly to ensure their failure.
Should we also force luxury brands to offer stipends so that teenagers whose parents can't afford them (or simply don't want to participate in that nonsense) don't feel stigmatized?
It would be a completely different story if Apple were to ban third-party messaging apps on their platform, but as restrictive as they are in other areas, they aren't doing that.
It literally only takes a free app download to get a cross-platform messaging experience at least on par with iMessage (and in my personal view superior in many regards).
I have no experience directly with foreign telecoms, so I was simply explaining how something with no marginal cost could still be a very expensive system.
As I have to explain about open source, 'Free is only free if your time is worth nothing.' (And I use a lot of FOSS, it just not always the solution.)
For something like Twitter where you could post by SMS, the balance of traffic might have been such that giving Twitter free outbound SMS was balanced by the charges incurred by customers sending to Twitter's shortcode. Or it might just be balanced by increased customer happiness when they can use the product more effectively.
If the carrier doesn't run their own messaging infra, they might be paying their IT provider on a per message basis, and might not be able or willing to set the messaging rate to zero.
For a use case where SMS is used to show control of a phone number, getting a zero cost direct route is a harder sell, but it can happen if the routing through aggregators is poor and the carrier is concerned about that, or if there's some other larger agreement in play.
In Brazil, businesses use Whatsapp to communicate with consumers. You order pizza and book doctor appointments over whatsapp
To be fair, that wasn't Google's plan, that was the GSMA's plan. GSMA created the RCS spec, failed to get more than a handful of their members to use it, and kind of abandoned it to the wolves. For reasons I don't quite understand, Google decided it'd be a good idea to take it up, and then push it harder than any of their previous messaging services; but it's not like they came up with it.
Twilio offers short codes, but short codes are country specific, and the costs for sending to the US are low anyway < ~ $0.01/message for most services, lower with volume; IIRC, short code messaging costs were half, but then you've got some overseas destinations where it's $0.10/message and that's real money.
It reminds me of the "Blue eyes/Brown eyes" exercise (https://en.wikipedia.org/wiki/Jane_Elliott) so let's say this was a real psychology experiment. Middle-schoolers and high-schoolers are encouraged to communicate via a chat application with rich multimedia functionality. But any conversation that includes even a single individual who belongs to an arbitrarily-defined "out-group" has its functionality degraded and the application highlights who the out-group member(s) are. After a year you compare the mental, social, physical, and academic well-being of both groups. Would your university's IRB approve such an experiment?
I initially gave Apple the benefit of the doubt that this was simply a technical limitation. And of course kids will always bully each other about something. But at this point it does indeed seem like a billion-dollar company is intentionally amplifying and leveraging this sort of bullying to drive marketshare. If you don't find this immoral then I'm not sure what to say.
Now, even if stars align, your SMS ends up on a route where nobody is mitm-ing or hijacking it, the telco systems work and it gets delivered, it is STILL not a guarantee of identity. It simply verifies that you have somehow got access to a particular phone number.
I do agree about being linked to your phone number - doing it that way means not considering a lot of people's valid threat models. They are working on moving to usernames, though. It's in beta now.
And you'll need to maintain ingress numbers in all the countries you support, and maybe numbers per carrier, depending, and you'll need to tell the user the right number to text to ... it's a lot, and it might not work well or might not save much money.
Google has made some proprietary extensions to RCS to support end to end encryption but this is not the same thing.
RCS is better than SMS no doubt but lets not pretend it is on the same level as iMessage. Lack of end to end encryption alone makes RCS a dated standard
https://www.techradar.com/phones/iphone/breaking-apple-will-...
I ran the engineering side of carrier integrations at WhatsApp. Carriers wanted to sell data plans with special pricing for data with WA and use WA branding in advertising, because it attracted customers that might later convert to a bigger general purpose data plan. As part of that, we would ask for zero rated SMS to their customers for verification. When it was available, it was generally faster and higher success vs sending messages through an aggregator.
We also had some, usually small, carriers approach us asking us to set up direct routes to them for verification, because their customers would not always receive our messages when we sent through an aggregator. Early in my career at WA, we would just send these carriers to our aggregator contacts, and often things would get linked up and then we'd still pay $/message but it would work better. As we got a little bigger and built support for direct routes anyway, it was usually not too hard to set up a direct connection and then there'd be no cost for that carrier. Messing around with IPSEC VPNs and SMPP isn't fun and the GSMA SOAP messaging APIs are way worse, but once you get the first couple implementations done, it becomes cookie cutter (and FB had built way better tools for this, and a 24/7 support team, so I never had to be up, on the phone with telco peeps at 3 am kicking racoon or whatever ipsec daemon we were running until it finally connected)
It still seems like a lot of money to spend on simple, old technology, but from the PoW perspective, making it cheaper would defeat its purpose.
*Which is why many sites reject Google Voice numbers, for example, for SMS verification.
Particularly when the phone requirement is the biggest weakness in Signal.
Getting rid of it will make it substantially cheaper to operate and much more private. Win-win.
I'm not following. Signal gets stung for the registration SMS costs because they send the SMS to the user. They don't pay when one user sends an SMS to another user. If you send an SMS, you're the one who pays.
(I didn't realise they were moving away from phone numbers. Don't they they stay mandatory when PNP comes along?)
There are a couple other options of course, but I am not sure they are better:
* Fully federate this, a la Matrix or XMPP. I really wish this was a practical option, but without legislation I doubt any company wants to go willingly in this direction. Even if they did, it'd be difficult to contain spam at scale. It also creates 'first contact' issues; love it or hate it, the general public seem attached to the idea of phone numbers and it seems to work relatively well and unambiguously. It is also the most technically complicated and most brittle and unpredictable for users.
* Phone / OS maker operates it for their devices. You don't seem to want Google running things, so this seems markedly worse than what they have actually done which is give you options (most people can at least choose a carrier, and carriers can choose implementations). It's unclear how operating costs are recouped here, especially for low-end devices. Does this lead to feature stratification? I hope not, but probably. It's a global single point of failure, both from a technical point of view as well as a policy/jurisdiction one (can $country LE subpoena my records because the company operating the service is ${country}an - or perhaps merely operates in $country, for example?). Also unclear how users are 'found', but maybe it's a bit easier than in a fully federated system.
* Phone / OS maker partners operate the service, giving users a few choices. Not really sure why anyone would go in for this, but it's basically the same as if the phone maker operates it.
None of these are great options, but I think the carrier is probably the least-bad one. You have an agreement with them. You have the legal protections offered in your home jurisdiction, with clear jurisdiction over the whole thing. They already have a ton of data on you and access to your traffic. You have a neck to wring if the service doesn't work properly.
They really should have standardized E2EE though, not including it is ridiculous.
It doesn't say how it works. If Alice's phone can tell whether her contact Bob uses Signal without Alice and Bob doing any sort of a priori cryptographic exchange, why couldn't Signal itself do whatever Alice's phone is doing?
They've given Signal quite the fork.
> If you are drawing as much billable traffic as you are sending
SMS verification traffic is usually unidirectional, so that’s very unlikely to be the case.
In most of the world, SMS is billed per-message, so it's basically no extra effort on the Telecoms side at all. In fact, Telecoms' online charging systems are fast enough to calculate users' data usage by seconds in real time, so they don't even blink at counting SMS.
There's nothing that requires tech companies to use SMS for registration or for 2FA. The normal way to do it is by email, which continues to be free. For Signal, there is no need to do 2FA registration at all.
Signal is ideologically committed to publicizing your phone number, and apparently they'd rather pay $6 million to hold to their commitment than just... not do that.
In general, pricing varies widely by destination (country and sometimes carrier), US and some other places are < $0.01, up to $0.10/message isn't uncommon, and some places are $0.20-$0.30/message. Voice calling was usually mor expensive (Twilio should have a price list somewhere for that too; if you can get 6 or 1 second billing, assume a voice verification call is about 30 seconds, but you might have to pay for a whole minute even if you don't use a whole minute).
Those SMTP -> SMS gateways sometimes work in the US, but they don't work much in other countries, and they're not good enough to rely on if your product requires an SMS during the new user flow. SMS costs are real and it's frustrating, but if it costs too much, you need to use something other than phone numbers for ids; I don't think skirting by with email gateways is going to work. But, if you build dynamic routing, I guess you could try.
Also, you've got the use the right email gateway for the user's carrier, and a carrier lookup is on the order of $0.01, unless you have tons of volume, so for the US, you might as well pay for the SMS.
[1] https://assets.cdn.prod.twilio.com/pricing-csv/SMSPricing.cs...
This is the worst take in technology. The main value of FOSS is freedom, not time or money savings. For many people freedom is more valuable than either.
Also, FOSS and managed aren't mutually exclusive.
Plenty of people are, and for good reasons.
Varies heavily by region. The shop opposite my house has ~50 SIM cards on the shelf, for £0.99/ea.
But the secret of JVM existing as an option is eventually learned by most who scale.
The knowledge of how to do this has forever been lost. Hopefully archaeologists can reconstruct it one day.
IMHO, RCS isn't a solution to anything since it still requires phone carriers to adopt it. A quick check of the internet indicates that many of these phone carriers are actually charging more to send RCS messages than SMS, making it a non-starter all around.
Maybe Google could create an iMessage-like (internet only) alternative for Android... Although it still wouldn't work with the actual Apple iMessage protocol unless Apple adopted it. IMHO they'd have better luck getting companies like Apple to interoperate if it was pre-installed and worked on all Android phones.
And I would argue that the language used implies Google created RCS themselves (it was their idea): "RCS is Google's idea of a solution"
It's the Microsoft 90's playbook https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...