Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust at Scale: An Added Layer of Security for WhatsApp

engineering.fb.com

Post reply on HN
Print view View original

41–50 of 151 posts

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

#41

Post by dewey »

jdxcode wrote: post #33
candiddevmike wrote: post #27

Earlier quoted context omitted.

The "is key - ", is a key giveaway. EDIT to expand the evidence: It's placing unnecessary emphasis on a one off mention in the article (differential fuzzing) and then writes a bunch of bullshit around what it thinks it means (it's wrong, differential fuzzing isn't running them both in parallel during a transition, it's a testing methodology based on inputs/outputs).

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

AI is trained on human output, so that's not really a good differentiator.

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

#42

Post by galangalalgol »

cong-or wrote: post #38

The 160k → 90k LOC reduction is nice, but the parallel rollout is the more interesting part. Running Rust alongside the C++ version and using differential fuzzing to check equivalence is a lot more realistic than “rewrite and pray.” You get incremental validation with the old system as a fallback. Curious how long they ran both before cutting over. Binary size is a real concern on the client side. On servers the Rust…

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?

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

#43

Post by galangalalgol »

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.

Can it do lto on stdlib even without the nightly build-std flag?

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

#46

Post by 4gotunameagain »

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?

Every encryption is end to end if you're not picky about the ends, or metadata.

Do you trust facebook (excuse me, meta) to not snoop on your messages, and to not share them with the "intelligence" agencies ?

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

#47

Post by surajrmal »

galangalalgol wrote: post #42
cong-or wrote: post #38

The 160k → 90k LOC reduction is nice, but the parallel rollout is the more interesting part. Running Rust alongside the C++ version and using differential fuzzing to check equivalence is a lot more realistic than “rewrite and pray.” You get incremental validation with the old system as a fallback. Curious how long they ran both before cutting over. Binary size is a real concern on the client side. On servers the Rust…

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.

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

#48

Post by Fripplebubby »

4gotunameagain wrote: post #46
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?

Every encryption is end to end if you're not picky about the ends, or metadata. Do you trust facebook (excuse me, meta) to not snoop on your messages, and to not share them with the "intelligence" agencies ?

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.

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

#49

Post by galangalalgol »

happyweasel wrote: post #44

Let's see how this unwrap()s in production scnr

Oh come on, that was funny. It also highlights a problem with the way people write rust. If your app panics it has a bug. People throw panics in cases that can absolutely happen, a file isn't there or fails to parse, some set of inputs is mutually inconsistent these are things for error checking. Even if the correct way to handle an error you detect is to stop the app, do that instead of panicking. Panics are for things that should be impossible. Ideally they even get optimized out.

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

#50

Post by tialaramex »

IshKebab wrote: post #30
aero-glide2 wrote: post #11

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

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…

Rust's "A language empowering everyone..." tagline also helps justify the heavy lifting needed to prevent you shooting yourself in the foot, because we're all able to imagine a hypothetical less experienced programmer who might make a mistake even as we swear that we'd never make it ourselves.
Post reply on HN