Rust at Scale: An Added Layer of Security for WhatsApp
engineering.fb.com
engineering.fb.com
Binary size is a real concern on the client side. On servers the Rust stdlib overhead usually doesn’t matter, but when you’re shipping to billions of mobile devices, every KB counts. Good to see they invested in build tooling instead of just accepting the bloat.
Also note that if you statically link to the rust std library, lto will excise the majority of it anyways, no need to rebuild it.
I think that crown currently goes to https://github.com/googlefonts/fontations which is included in Chromium, not sure if it's on all platforms yet. Moreover, the translative dependencies of Fontations (click through https://crates.io/crates/fontations/0.3.0/dependencies) should have an even (slightly) larger install-base.
EDIT: from the quote you can also gather that they don't use https://github.com/signalapp/libsignal
- https://github.com/image-rs/image-png
- https://github.com/webmproject/CrabbyAvif
Whatsapp is a chat application with 3 billion daily active users.
For those of you in the US (where Whatsapp is seldom used), this is a fact worth remembering.
If you want to build products for the rest of the world, you need to know how those users think and breathe - and for 3 billion of them, Whatsapp is how they talk.
(Asking as a European who quite stubbornly refuses to install it - there are dozens of us. Dozens!)
Edit: please don't participate in making WhatsApp even more inescapable as it is today.
I have been trying to get hold of anyone or anything at Whatsapp. I've spent 6 months trying to navigate the bureaucracy. Facebook support claims they can't touch WhatsApp; WhatsApp support ignores the Facebook side. If you're building on WA, have a backup plan.
If any Whatsapp employee reading this can look into my WBA Account 1117362643780814
I can't do any of the above,
1. Requesting a new test number. Test numbers are placeholder 555 number that works only within WhatsApp test network. Can't get one.
2. Registering a new, real phone number (SIM obtained from a regular tele provider)
3. Disconnecting the WhatsApp product from the Facebook App to reset the integration.
Although the FB app is being used, I don't have any WhatsAppp users (because I have not even made the product), so wiping out any WBA accounts and starting fresh is also okay, if someone can do this.
I'd urge caution before using them as a component of your business, though. Their business strategy is pretty chaotic and has relied heavily on weird cryptocurrency-adjacent plays (e.g. TON / Fragment / gifts). They've made a couple of attempts to introduce business features, but I'm not sure they've had any substantial uptake.
That said, Telegram is likely a lot more open for a business type that is legal but still regulated or illegal in some countries (legalized/unregulated substances, tobacco/e-cigarettes, adult content, etc.), probably less worried of random bans/demonetization.
Despite not being E2EE, Telegram also seems to have higher usage in censored countries (Russia and Iran etc). Once a Russian guy in Korea randomly asked if I had Telegram wanting me to take a picture for him since his phone was dead -- obviously had no idea that sounded like a massive scam flag to most Western users.
Maybe the EU or China will crack down on it. A single company shouldn't decide who gets to talk to half the world. If that company is American they will not tolerate it for long.
Personally DeltaChat is my new favorite Thing but it falls afoul of Zooko's Triangle - A WhatsApp number or POTS number is short because it's centrally controlled and you have to pay for each one. DeltaChat has public keys, so I have 20 of them, and nobody can control who gets one, but they're incredibly long... the QR codes are nightmares.
At one point people moved from something else to Whatsapp, and that happened before Whatsapp had 3 billion people on it. If it's good, early adopters will adopt it and want others to adopt it too, then it snowballs from there.
It has happened before, and as long as new regulation doesn't solidify Whatsapp/FB in their position, it can happen again :)
WhatsApp allowed people to send SMS without paying, or rather, paying just once to buy the app, so it was instantly valuable if you just convinced your spouse or parents or a single friend to install it.
To overcome it now, you need a lot more effort (or rely on enshittification, which I'm sure will happen).
And no one was paying per SMS at the time we were using SMS for communication, almost everyone I know were on monthly plans that gave you N text messages and N minutes of calls for static sum each month.
The first people I saw who started using whatsapp, was people who were communicating across the border, because even if you had a monthly plan, those didn't include international messages. Eventually we all converged on whatsapp because that's what outside family and relatives used anyways.
> paying for “N text messages per month” is precisely what people refer to as paying per message
Maybe I said it wrong, "N text messages per month" for me means "Pay us 10 EUR per month, send up to 5000 messages" for example. Doesn't matter how many you send, you pay the same.
While "pay per message" is "Every text message you send, costs 0.01 EUR". Maybe I'm using the wrong words, but that's how I understand it.
Most of the people who were "texters" (in my circles) were on plans offering the first way of paying, while hardly anyone was doing it the second.
Another important part, was that most telecom's had free SMS and calls if you were with the same company (and still do, AFAIK), so constant bickering about what plan people are on and why they don't change so it's free and yadda yadda.
Many people were already mostly texting for free at this point.
The rates people were paying back then were extortionate - like 60-90% profit margin. When WhatsApp launched, plans were 5-15 euros/month for 100-500 messages with ~0.15 per message for overages. So you might not count the bundle as a per text message, but it really is which you can tell by what happens if you send more than your bundle allowed. Compare that with WhatsApp’s $1/year for unlimited messaging and you start to see the pricing disparity.
Many people were not mostly texting free in 2009. I think you’ve got the timelines mixed up. That started changing towards the mid to late 2010s precisely because of internet-based chat apps on the phone and plummeting data costs making the telco’s SMS pricing plans insane.
The initial claim of "WhatsApp happened at a time when, in Europe, you paid for SMS." maybe was true in parts of Europe, but clearly not everywhere. People were mostly using the Facebook chat (not Facebook Messenger/Chat) already before Whatsapp started being used, although Whatsapp in Sweden still isn't as popular as in other countries. In Spain, everyone uses Whatsapp, in Sweden, seemingly the people I talk to only have Whatsapp to communicate with me and others outside the country.
> Many people were not mostly texting free in 2009
Most people I knew definitively were mostly texting for free even before 2009, again, at least in Sweden.
I grew up in Canada so my knowledge is purely from talking with people in non-Swedish parts of Europe that I met and also reading contemporary articles analyzing the space as well as retrospective analysis of what led to WhatsApp’s popularity and dominance.
Send 2 factor verification pins over whatsapp - it is more reliable than SMS and generally there is a better 1:1 mapping between whatsapp accounts and real humans than phone numbers, so it is a good anti-spam or good way to distribute "first month free" type deals whilst keeping abuse low.
Obviously make sure all URL's have info cards properly rendered in Whatsapp for good share-ability.
https://www.birdy.chat/blog/first-to-interoperate-with-whats...
Every business in Brazil has an whatsapp to talk to their clients. Sometimes this whatsapp goes into the phone or computer of a real human being. Other times, it's manned by a bot (usually a dumb choose-your-own-adventure bot - I don't see business using LLMs for this here)
Indeed I use food delivery apps (ifood here) only to check out the menu of delivery restaurants, then I search for them in Google so I can order directly from them through whatsapp. This won't work for some dark kitchens, but other than that it's pretty reliable and avoid the middleman
Meta is also a despicable company, they don't need my help to succeed.
(edit: and I haven't abandoned the idea to switch back to a Linux mobile OS at some point, and WhatsApp would be a pain)
I help moderate a community of developers and we hit the whatsapp group limit of 1024 members and sometimes have to wait for someone to leave (intentionally or accidentally) before we can add new members. We've tried to move people onto "better" platforms like Discord or Slack but we always end up coming back to WhatsApp which is subsidized via MNOs (mobile network operators) social media data/internet bundles and for the fact that most people are just stuck on whatsapp.
"phone number, public keys, timestamps, and, if set to public, about text and profile picture. From these data points, the researchers were able to extract additional information, which allowed them to infer a user's operating system, account age, as well as the number of linked companion devices."
See: https://www.univie.ac.at/en/news/press-room/press-releases/d...
They have ads and spam already (sorry, no-consent messages from businesses). This isn’t even new. [0]
There’s a clear pattern, say “we’ve rolled out strict policies”[1] and then… nothing changes on the ground, and TechCrunch writes another “they’ve fixed it” article a year later.[2]
Also their Communities feature has pretty crap UX.
Yes WhatsApp’s pervasive. But if pervasive was the end of the story, we’d all be using ICQ and AOL. The last thing any country needs is to hand over more of their lives to Facebook [sic].
[0] https://techcrunch.com/2022/10/10/in-india-businesses-are-in...
[1] https://techcrunch.com/2024/11/20/whatsapp-will-finally-let-...
[2] https://techcrunch.com/2025/10/17/whatsapp-will-curb-the-num...
Nontechnical uncle messaging me on Signal was a great signal that Signal was gaining some social traction.
I suppose this is true because there's more phones using WhatsApp than there are say Windows 11 PCs.
Given that WhatsApp uses libsignal, is it safe to assume that they haven't been using the Rust library directly?
If you count old Android versions before Rust was added.
It's like complaining about Electron apps. For sure I love small native apps like everyone else. But, if Electron enables a company to ship cross-platform apps and iterate faster, who am I to say no?
(I happen to have seen some of those tablets in diagnostic mode and poked around a bit. These things are much more complicated than you think.)
If you also add in the extra ease of things like device management across fleets etc, it becomes a no-brainer for the manufacturer.
Even worse was an article some months back about Android tablets hooked to heating & cooling systems expected to last 20 years. There's no way those things are making it at scale.
"should" or "actually can"? Do you have references to show that's the actual lifespan of the equipment, mechanically?
What actually prompted the engineering-CYA "should" is if the Android tablet is controlling some sort of robotic system for selecting weight sizes, that that system might have an expected life span on par with a tablet, being a physical thing moving around some pins or something in a potentially hostile user environment. That'll break long before anything else would.
I'm just going to ignore this.
Agree that wanting to hire cheap developers is why they did it that way, the current interface is so laggy that I would bet it is Web based, on top of running Android for nothing.
The extra cost of an Android capable tablet (maybe $200 especially wholesale) is a minimal hardware cost considering the overall price of the equipment is in the thousands.
But finding good embedded developers is a very difficult problem to solve, much easier to find Android app developers and then you get the Android eco-system for free like device management, OTA updates etc.
Put all the sensors and controls on a USB bus and you need one or two actual embedded developers to deal with the drivers and the rest of the developers can build the UI that people see.
In the case of a gym, the person buying the equipment is the customer, not you.
They want features that will make you "sticky" to the gym, plus save costs on training you on how to use the equipment.
Personally, I'm a bit of an aficionado of close to the metal sports electronics. When I stare at gym screens I immediately notice updates that are supposed to come in once a second to get randomly delayed by what must be hundreds of millis. But I can totally see why they went that route. It's a market where feature quantity is big as a success metric and using a maintenance-friendly platform is even bigger. Wether Android actually checks that box might be debatable, but a bad embedded implementation could easily be worse, no doubt about that.
In the old days, those screens would have randomly dropped into some Windows desktop failing to operate in some kiosk mode fantasy.
They don't say what they did about it, do they? Did they just accept it?
https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee...
https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba...
Turn out if you have strong control over the compiler and linker instrumentations, there are a lot of ways to optimize binary size
It can be avoided entirely by disabling the standard library, but that's inconvenient, and usually done only when writing for embedded devices.
Usually the problem isn't the size directly, but duplication of Rust dependencies in mixed C++/Rust codebases.
If you end up with a sandwich of build systems (when you have library dependencies like C++ => Rust => C++ => Rust), each Rust/Cargo build bundles its copy of libstd and crates. Then you need to either ensure that the linker can clean that up, or use something like Bazel instead of Cargo to make it see both Rust and C++ deps as part of a single dependency tree.
A println!("hello world") happens to pull in almost all of it (it panics if stdout is closed).
Later code growth is just obviously proportional to what you're doing, and you're not getting a whole new copy of std::fmt every time you call print.
Wasn't there news lately that they can still read your messages somehow?
If you want to assure me your e2e is secure, there must be at least two clients implemented by different people, with at least one of them opensource.
Whatsapp used to have this, but lately they have cracked down on third party clients.
Blame spammers on that. The amount of scammers and spammers on Whatsapp is unreal.
Do you trust facebook (excuse me, meta) to not snoop on your messages, and to not share them with the "intelligence" agencies ?
Neither the OS nor the application would know the contents of your message beyond "it's 500x700 pixels".
Similar things are done for DRM video, and widevine level 1 or 2 haven't seen many breaches despite running on a wide array of hardware open to physical attack.
If you can have an e2e chat between two iphones locked in a big glass box with a sign that says "Anyone who can hack into this conversation gets $100M", that's a really good marketing campaign.
If you can make the app use secure enclaves or whatever to take the ~100k people who write the source code of the libraries, app and OS out of the attack surface, that $100M becomes much safer.
So Google can, if ordered or willing to help, create a new release track (e.g. experimental-do-not-deleted) and add specific e-mails to that track with the "improved" version.
Nobody would be able to see that in real world, and you know what, if WhatsApp themselves are ordered, they can also create their own "test" track, it's just less covert but it would technically be working.
In all cases, Google and Apple have to respect US laws, and the laws of earning money too.
If you do not cooperative with intelligence / police services of your country, only bad things can happen.
A particularly relevant point is when it comes to government interception. E.g. it would be perfectly possible for an messaging app to have a "wiretap mode" that the vendor enables for users that are the subject of a relevant warrant.
Well, that statement can only resolve to true.
These requests of data collection are perfectly legal. FBI DITU gives an order: give me all chats from *@banana.com and they receive banana.com.
From there, two choices from the perspective of a tech provider:
a) You accept. You get paid.
You can always claim you had been coerced / are a victim, and that everything has been done by the law.
You take the risk to lose over 250K per day (!) in fines, some other court scandals that will come to you, some shady private stuff (what if we learn about your secret jacuzzi ?), harassement of the team, be publicly shamed that you supported terrorists who caused actual death of Americans, etc.
In addition, nobody will know that you are the privacy hero and you are not even sure that the data is not exfiltrated another way.
Yes, we looked carefully and decided we won't enjoy losing 100M USD and go to jail.
The trick is that the identifier / wildcard can be very vague and wide. Or there can be multiple of them, each of them are narrow, but put one of top of the other they are super wide.
No, but I trust some nosy German guy at TU Whatever to spend hours poking at the assembly, find that hidden flag and proudly present it at 40C3.
With enough eyeballs, all source is open (and AI will give us far more eyeballs than we have any idea what to do with).
Sure, you can have different builds distributed to different people, but the NSA can also just do that with Signal, Signal being open source makes it that much easier. FDroid mitigates this somewhat, but it's not like the NSA can't get a fake TLS certificate for their domain and MITM your communications.
The interesting aspects, such as how they protect against supply-chain attacks from the dependency-happy rust toolchain or how they integrated the C++ code with the Rust code on so many platforms - a top challenge as they said - remain a mystery.
Would also be interesting to hear how much AI-driven development they used for this project. My hope’s that AI gets really good at Rust so one doesn’t have to directly interact with the unergonomic syntax.
This and the Google blogs offer zero technical insights and I haven’t learned anything from any of them.
There are standard techniques to help manage this that apply across languages, there's no reason to reinvent that wheel.
> My hope’s that AI gets really good at Rust so one doesn’t have to directly interact with the unergonomic syntax.
"Unergonomic syntax" is the battle cry of many people resisting learning a new language. AIs have progressed far enough that they can help you in that learning process, though.
Not only can AIs help, but they can write most if not all the code and spare the human from learning all the intricacies of individual programming languages. Problem is, reports are contradictory on compatibility with Rust. We know they work great with simpler/friendlier languages like Go or Python.
* No undefined behaviour (outside `unsafe`, which is quite easy to avoid). In C++ there are many many sources of UB that aren't really memory errors directly, e.g. signed integer overflow or forgetting to `return` from a function.
* A much stronger type system.
Those two things have a really significant impact on reliability.
On binary size, static linking with LTO should handle most of the bloat without needing custom stdlib builds.
Quoting a user:
keeping it simple: a flat $15,000 to get you on the front page of Hacker News.
[...] contact e-mail below
Spend a week to do a bot, get 10'000 USD of ARR for your B2B tech SaaS, and applause from your investors.
And a week is probably exaggerated, 2 days max
The reason I'm asking is that I actually believe the price point is much lower. It's probably much easier to get on the front page of HN of you time the submission + upvotes well enough.