Rust at Scale: An Added Layer of Security for WhatsApp • Hacker News Board

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#61

Post by blub » Wed, Jan 28, 2026, 4:57 PM UTC

antonvs wrote: post #56

blub wrote: post #35

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 wi…

> The interesting aspects, such as how they protect against supply-chain attacks 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 progr…

The dependency management and complexity/poor ergonomics are the two major technical problems with Rust. Normally the first one’s ignored while the second is downplayed, so it would have been interesting to see what (if anything) Facebook have done about them.

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#62

Post by chinathrow » Wed, Jan 28, 2026, 4:58 PM UTC

justinlords wrote: post #58

The differential fuzzing approach is clever — way safer than a big-bang rewrite. Running both versions in parallel to catch edge cases before switching over is how you actually ship rewrites without breaking production. The 160k to 90k LOC drop is impressive, but the real engineering win is the validation strategy. On binary size, static linking with LTO should handle most of the bloat without needing custom stdlib b…

We really need an AI filter here on HN.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#63

Post by blub » Wed, Jan 28, 2026, 4:59 PM UTC

surajrmal wrote: post #39

blub wrote: post #35

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 wi…

The point of articles like this is to help build credibility for rust adoption. Rust is still not very widely adopted industry wide, and a lot of smaller players only use established technologies that bigger firms have shown works well. Rust is not inevitable, and articles like this are necessary for its future industry adoption.

I had already said it’s a PR piece, you’re merely rephrasing that and making it sound like a good thing.

This and the Google blogs offer zero technical insights and I haven’t learned anything from any of them.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#64

Post by rvnx » Wed, Jan 28, 2026, 5:06 PM UTC

antonvs wrote: post #59

Fripplebubby wrote: post #48

Earlier quoted context omitted.

This is not true. The IETF draft is explicit that E2EE means that the message cannot be read by any party other than the sender and the intended receiver. When companies like Meta claim they support E2EE, this is what they claim. There are no tricky semantics or legalese at play here.

It's not entirely accurate to say "any party other than the sender and the intended receiver," since the messaging app running on the user's device can read the messages. Something like "any third party (other than the app vendor)" would be more accurate. Without actually analyze app behavior, it comes down to trusting that the vendor doesn't do anything nefarious.

As far as I remember, Google does the final signing of the APK, which is eventually the signature verified by the OS to verify if an update is valid or not.

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#65

Post by Fripplebubby » Wed, Jan 28, 2026, 5:07 PM UTC

antonvs wrote: post #59

Fripplebubby wrote: post #48

Earlier quoted context omitted.

This is not true. The IETF draft is explicit that E2EE means that the message cannot be read by any party other than the sender and the intended receiver. When companies like Meta claim they support E2EE, this is what they claim. There are no tricky semantics or legalese at play here.

It's not entirely accurate to say "any party other than the sender and the intended receiver," since the messaging app running on the user's device can read the messages. Something like "any third party (other than the app vendor)" would be more accurate. Without actually analyze app behavior, it comes down to trusting that the vendor doesn't do anything nefarious.

I think the draft covers this well: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition...

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#66

Post by londons_explore » Wed, Jan 28, 2026, 5:10 PM UTC

> over 3 billion people to message securely each and every day.

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#67

Post by rubymamis » Wed, Jan 28, 2026, 5:15 PM UTC

storystarling wrote: post #6

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…

AI reply?

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#68

Post by galangalalgol » Wed, Jan 28, 2026, 5:17 PM UTC

surajrmal wrote: post #47

galangalalgol wrote: post #42

Earlier quoted context omitted.

Did they say anywhere what they did? Rebuilding the stdlib as part of your build can shrink it a lot depending on how much of it you use, but that is still nightly only. Maybe they went no_std or created their own?

They didn't but keep in mind that the app is currently 170MiB. The standard library shouldn't have added more than a few hundred kilobytes. They already likely pay similar costs for c++, but it's more worthwhile as they have a lot more c++ code total. 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.

The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#69

Post by londons_explore » Wed, Jan 28, 2026, 5:17 PM UTC

wongarsu wrote: post #51

I_am_tiberius wrote: post #45

> "WhatsApp provides default end-to-end encryption for over 3 billion people". Wasn't there news lately that they can still read your messages somehow?

WhatsApp could exfiltrate messages at the ends. But I assume the trick lies in the word "default". Didn't Skype also default to end-to-end encryption, unless there was a server flag that disabled it for that specific user (I might be fuzzy on the details)

I don't trust un-auditable client applications...

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#70

Post by galangalalgol » Wed, Jan 28, 2026, 5:18 PM UTC

surajrmal wrote: post #37

pornel wrote: post #17

Earlier quoted context omitted.

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 =…

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.

Posted elsewhere but The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.