Rust at Scale: An Added Layer of Security for WhatsApp

storystarling 4 hours ago | parent | next [-]

The hardest part of a rewrite like this is usually maintaining bug-for-bug compatibility with the legacy parser rather than the actual Rust implementation. Most real-world media files are malformed in some way that the C++ code implicitly handled, so if you write a strict parser you end up breaking valid user data. Differential fuzzing seems like the only practical way to map that behavior without manually reviewing millions of edge cases.

▲

dwattttt 3 hours ago | parent [-]

It sounds like it's a design goal of this "wamedia" to _not_ maintain bug compatibility with media players.

	▲	storystarling 2 hours ago \| parent [-]
		I suspect it is actually about maintaining permissiveness for malformed inputs rather than keeping security bugs. I ran into this building ingestion for a print-on-demand service where users upload technically broken PDFs that legacy viewers handle fine. If the new parser is stricter than the old one you end up rejecting files that used to work, which is a non-starter for the product.

▲

wrtc_dev 2 hours ago | parent | prev | next [-]

The focus on media parsing is smart - it's one of the most attack-prone surfaces in any messaging app. Media files are essentially untrusted input from the network that need complex processing.

What's interesting is the broader trend: Signal's libsignal is Rust, Matrix's vodozemac (Olm/Megolm implementation) is Rust, and now WhatsApp is moving this direction. The industry seems to be converging on Rust for the security-critical paths while keeping the UI layer in whatever makes sense for the platform.

The differential fuzzing approach they mention is key - you can't just rewrite and hope for the best. Real-world media is full of edge cases and malformed files that users expect to "just work." Having both implementations running in parallel during the transition gives you a safety net.

▲

wongarsu an hour ago | parent | next [-]

I agree with everything you say. But wow, does that comment sound like AI. Probably Grok?

Not saying you are AI, you might just be a heavy user who picked up the same patterns

▲

jsheard 28 minutes ago | parent | next [-]

If it were an old account I might have given them the benefit of the doubt, but they literally just joined to make this comment. There's so many green accounts popping up which reek of AI now, like I've seen some where all of their comments are almost exactly the same length.

▲

m00dy an hour ago | parent | prev | next [-]

I like your AI slop detector, is it part of your consciousness ?

▲

candiddevmike an hour ago | parent | prev [-]

The "is key - ", is a key giveaway.

▲

braiamp 37 minutes ago | parent | next [-]

Which many people use. Heck, go to Stack Overflow about 10 years back. You will see people using it. It's a style.

▲

jdxcode 22 minutes ago | parent | prev | next [-]

I think it's a giveaway that it's human! A hyphen is incorrect punctuation.

	▲	wongarsu 14 minutes ago \| parent [-]
		According to British style guides an en-dash would be correct in that usage, and the difference between an en-dash (–) and a hyphen (-) is pretty small. Seems perfectly defensible to me unless you are publishing a book or academic journal

▲

seritools 26 minutes ago | parent | prev [-]

TIL I'm an AI

▲

randomint64 18 minutes ago | parent | prev [-]

That's right, Signal (https://kerkour.com/signal-app-rust), Proton (https://kerkour.com/proton-apps-rust), Matrix, Wire and many more are using a share, cross-platform Rust core and a platform-dependent UI layer.

But it's not only the security-critical paths, but also most of the business logic (see the 2 posts above).

▲

nevi-me 5 hours ago | parent | prev | next [-]

> We believe that this is the largest rollout globally of any library written in Rust.

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?

▲

marisen 4 hours ago | parent | next [-]

WhatsApp doesn't use libsignal, and Android is already pretty Rusty and deployed more than WhatsApp around the world (not just smartphone. Tons of "embedded" use cases also run on custom Android)

▲

pjmlp 4 hours ago | parent [-]

Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.

▲

g947o 3 hours ago | parent [-]

It doesn't make sense for that device alone, but the vendor probably supplies all the different equipment in the gym. Using a tablet simplifies their supply chain, deployment, debugging/repair, app update process and simply supports more features. There are probably some connectivity features on the device, for example. When you look at all of that together, it's hard to argue it's wasting money.

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.)

▲

rswail an hour ago | parent | next [-]

Once you price in the cost of integration, plastics, ROHS, CE and other regulatory/certifications, the extra cost of an Android tablet which already has a lot of that starts to make sense.

If you also add in the extra ease of things like device management across fleets etc, it becomes a no-brainer for the manufacturer.

▲

pjmlp 2 hours ago | parent | prev [-]

Well, doesn't look like to me, and a plain ESP32 with a touch screen would do the job for displaying a weight bar with plus, minus and reset count buttons.

▲

usrusr 2 hours ago | parent [-]

And then you get to a cardio unit where you want a completely different set of features and have to start over. Going lean on hardware only makes sense when you push out a very high number of units, when you have to deal with battery constraints or when you just have a lot of intertia, the combination of existing codebase and developer filter skillset.

▲

pjmlp 2 hours ago | parent [-]

Except all the machines have the same feature set I mentioned.

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.

	▲	rswail an hour ago \| parent [-]
		That's not a problem of the platform, but is a problem of the developers. 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.

▲

pjmlp 4 hours ago | parent | prev [-]

If you watch "Microsoft is Getting Rusty: A Review of Successes and Challenges" it appears the whole effort is more on the Azure side, and besides some timid adoption like GDI regions, there is a lukewarm adoption of Rust on Windows side, still pretty much a C and C++ feud.

https://www.youtube.com/watch?v=1VgptLwP588

▲

palata 2 hours ago | parent | prev | next [-]

> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...].

They don't say what they did about it, do they? Did they just accept it?

▲

sluongng 2 hours ago | parent | next [-]

I suspect they just use no_std whenever its applicable

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

▲

pornel 2 hours ago | parent | prev | next [-]

Probably yes. It's ~300KB per binary, and it's a one-time cost.

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.

	▲	surajrmal 3 minutes ago \| parent [-]
		The size is not fixed. It changes based on how much of the standard library you use. Dynamically linking the standard library is also a valid option in many cases.

▲

jsheard 2 hours ago | parent | prev | next [-]

Who knows what they did, but there are things which can be done: https://github.com/johnthagen/min-sized-rust

▲

menaerus 2 hours ago | parent | prev [-]

The whole article a bit watery which is why I read it as a PR rather than technical presentation

▲

blub 16 minutes ago | parent | prev | next [-]

Just like Google’s Rust-in-Android blogs this reads like a PR piece (and in the case of facebook also recruitment piece) with some technical words sprinkled in for effect. The overall communication quality is that of a random startup’s “look what we did” posts.

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.

▲

kpcyrd 5 hours ago | parent | prev | next [-]

Very cool! I'm wondering if Signal is doing something similar? libsignal is implemented in Rust, but I don't know about the other parts.

▲

aero-glide2 2 hours ago | parent | prev | next [-]

Quite impressive, I did not know so many bugs were due to memory access.

	▲	IshKebab 33 minutes ago \| parent [-]
		To be fair the increased reliability of Rust code over C++ isn't just because of memory errors (out-of-bounds accesses, use-after-free, type confusion, etc). You also get: * 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.

▲

mentalgear 2 hours ago | parent | prev [-]

Cool - now we only need to get selling-you-out-for-profit-Zuckerberg out of WhatsApp to make it really trustworthy.