12 ms·

Rust at Scale: An Added Layer of Security for WhatsApp

266 points by ubj 8mo ago

kpcyrd 8mo ago
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.
nevi-me 8mo ago
> 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 8mo ago
  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)
  - deleted 8mo ago
    [deleted]
  - pjmlp 8mo ago
    Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.
    - g947o 8mo ago
      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.)
      - pjmlp 8mo ago
        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 8mo ago
        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 8mo ago
        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 8mo ago
        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.
        usrusr 8mo ago
        Cardio units have neither a "weight bar" nor a repetition counter, but they have a whole universe of possible features in the realm of scripted sequences, reactions to HRM signals and even just "making time pass" features. With unbounded gimmickyness, the sky is the limit. 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.
  - charcircuit 8mo ago
    >deployed more than WhatsApp If you count old Android versions before Rust was added.
  - fabrice_d 8mo ago
    WhatsApp was using libsignal (the C version) when I worked on the KaiOS integration in 2017/2018.
- pjmlp 8mo ago
  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 https://www.youtube.com/watch?v=1VgptLwP588
storystarling 8mo ago
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 8mo ago
  It sounds like it's a design goal of this "wamedia" to _not_ maintain bug compatibility with media players.
  - storystarling 8mo ago
    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.
- rubymamis 8mo ago
  AI reply?
  - storystarling 8mo ago
    Not AI. Anyway, the real issue is permissiveness vs strict parsing—real-world files are messy.
aero-glide2 8mo ago
Quite impressive, I did not know so many bugs were due to memory access.
- IshKebab 8mo ago
  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.
  - tialaramex 8mo ago
    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.
palata 8mo ago
> 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?
- menaerus 8mo ago
  The whole article a bit watery which is why I read it as a PR rather than technical presentation
- pornel 8mo ago
  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 8mo ago
    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.
    - galangalalgol 8mo ago
      Can it do lto on stdlib even without the nightly build-std flag?
    - galangalalgol 8mo ago
      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.
wrtc_dev 8mo ago
[flagged]
- wongarsu 8mo ago
  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
  - m00dy 8mo ago
    I like your AI slop detector, is it part of your consciousness ?
  - candiddevmike 8mo ago
    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).
    - braiamp 8mo ago
      Which many people use. Heck, go to Stack Overflow about 10 years back. You will see people using it. It's a style.
    - seritools 8mo ago
      TIL I'm an AI
    - jdxcode 8mo ago
      I think it's a giveaway that it's human! A hyphen is incorrect punctuation.
      - wongarsu 8mo ago
        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
mentalgear 8mo ago
Cool - now we only need to get selling-you-out-for-profit-Zuckerberg out of WhatsApp to make it really trustworthy.
blub 8mo ago
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.
- surajrmal 8mo ago
  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.
  - blub 8mo ago
    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.
    - surajrmal 8mo ago
      PR makes it sound like it only benefits the company. It benefits the broader rust community as well. Where was it established that the article must provide you some technical knowledge to learn? I sure didn't go into reading it with the expectation it would.
- antonvs 8mo ago
  > 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 progressed far enough that they can help you in that learning process, though.
cong-or 8mo ago
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 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.
- galangalalgol 8mo ago
  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?
  - surajrmal 8mo ago
    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.
    - galangalalgol 8mo ago
      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.
      - metaltyphoon 8mo ago
        I assume OP is taking about using -Zbuild-std on nightly. This will drop it much more.
happyweasel 8mo ago
Let's see how this unwrap()s in production scnr
- galangalalgol 8mo ago
  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.
I_am_tiberius 8mo ago
> "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?
- 4gotunameagain 8mo ago
  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 ?
  - Fripplebubby 8mo ago
    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.
    - monocasa 8mo ago
      To be fair zoom did claim E2EE, with one of the ends being their servers.
      - morpheuskafka 8mo ago
        Speaking of Zoom and encryption, its crazy that they bought Keybase (I think they basically said it was largely an acquihire) years ago, and have neither shut it down as everyone thought, nor materially changed it in any way. Unless they changed something it even gives 200GB cloud storage (KBFS) iirc.
    - antonvs 8mo ago
      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.
erithax 8mo ago
> We believe that this is the largest rollout globally of any library written in Rust. I think that crown currently goes to https://github.com/googlefonts/fontations 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 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/signalapp/libsignal
- mdriley 8mo ago
  Just a few more Rust libraries we've shipped in Chromium: - https://github.com/image-rs/image-png https://github.com/image-rs/image-png - https://github.com/webmproject/CrabbyAvif https://github.com/webmproject/CrabbyAvif - https://github.com/RCasatta/qr_code https://github.com/RCasatta/qr_code - https://github.com/unicode-org/icu4x https://github.com/unicode-org/icu4x
- dcsommer 8mo ago
  Just for reference, Wamedia ships on the major Meta apps and on iOS, Android, Desktop, and Web platforms.
justinlords 8mo ago
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 builds.
- chinathrow 8mo ago
  We really need an AI filter here on HN.
  - stingraycharles 8mo ago
    A comment like this works as well, let the community do its thing.
    - rvnx 8mo ago
      There are a couple of bots here. Quoting a user: keeping it simple: a flat $15,000 to get you on the front page of Hacker News. [...] contact e-mail below Expensive, but now with LLMs it's super cheap to do. 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
      - stingraycharles 8mo ago
        Do you have any actual evidence that these types of services are being offered for that type of price point, though? 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.
londons_explore 8mo ago
> 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.
- jraph 8mo ago
  What one should do about this? I mean, beside working on lowering that number. (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.
  - embedding-shape 8mo ago
    I guess if you want to lower that number, you'd need to build something better, in some way. Answered as another European who've had Whatsapp forever, as some stubborn people refuse to move away from it, and also bunch of businesses use it.
    - 01HNNWZ0MV43FF 8mo ago
      Network effect is killer. "better" would include having more than 3 billion people already on it. 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.
      - embedding-shape 8mo ago
        > Network effect is killer. "better" would include having more than 3 billion people already on it. 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 :)
aloukissas 8mo ago
I love how Meta will do anything but prevent phishing and prepaid credit card scams in Whatsapp/Messenger
yasmineroy33 8mo ago
[dead]

266 points by ubj 8mo ago

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.

nevi-me 8mo ago

> 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 8mo ago
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)
- deleted 8mo ago
  [deleted]
- pjmlp 8mo ago
  Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.
  - g947o 8mo ago
    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.)
    - pjmlp 8mo ago
      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 8mo ago
        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 8mo ago
        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 8mo ago
        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.
        usrusr 8mo ago
        Cardio units have neither a "weight bar" nor a repetition counter, but they have a whole universe of possible features in the realm of scripted sequences, reactions to HRM signals and even just "making time pass" features. With unbounded gimmickyness, the sky is the limit. 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.
- charcircuit 8mo ago
  >deployed more than WhatsApp If you count old Android versions before Rust was added.
- fabrice_d 8mo ago
  WhatsApp was using libsignal (the C version) when I worked on the KaiOS integration in 2017/2018.
pjmlp 8mo ago
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 https://www.youtube.com/watch?v=1VgptLwP588

storystarling 8mo ago

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 8mo ago
It sounds like it's a design goal of this "wamedia" to _not_ maintain bug compatibility with media players.
- storystarling 8mo ago
  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.
rubymamis 8mo ago
AI reply?
- storystarling 8mo ago
  Not AI. Anyway, the real issue is permissiveness vs strict parsing—real-world files are messy.

aero-glide2 8mo ago

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

IshKebab 8mo ago
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.
- tialaramex 8mo ago
  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.

palata 8mo ago

> 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?

menaerus 8mo ago
The whole article a bit watery which is why I read it as a PR rather than technical presentation
pornel 8mo ago
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 8mo ago
  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.
  - galangalalgol 8mo ago
    Can it do lto on stdlib even without the nightly build-std flag?
  - galangalalgol 8mo ago
    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.

wrtc_dev 8mo ago

[flagged]

wongarsu 8mo ago
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
- m00dy 8mo ago
  I like your AI slop detector, is it part of your consciousness ?
- candiddevmike 8mo ago
  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).
  - braiamp 8mo ago
    Which many people use. Heck, go to Stack Overflow about 10 years back. You will see people using it. It's a style.
  - seritools 8mo ago
    TIL I'm an AI
  - jdxcode 8mo ago
    I think it's a giveaway that it's human! A hyphen is incorrect punctuation.
    - wongarsu 8mo ago
      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

mentalgear 8mo ago

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

blub 8mo ago

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.

surajrmal 8mo ago
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.
- blub 8mo ago
  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.
  - surajrmal 8mo ago
    PR makes it sound like it only benefits the company. It benefits the broader rust community as well. Where was it established that the article must provide you some technical knowledge to learn? I sure didn't go into reading it with the expectation it would.
antonvs 8mo ago
> 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 progressed far enough that they can help you in that learning process, though.

cong-or 8mo ago

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

galangalalgol 8mo ago
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?
- surajrmal 8mo ago
  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.
  - galangalalgol 8mo ago
    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.
    - metaltyphoon 8mo ago
      I assume OP is taking about using -Zbuild-std on nightly. This will drop it much more.

happyweasel 8mo ago

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

galangalalgol 8mo ago
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.

I_am_tiberius 8mo ago

> "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?

4gotunameagain 8mo ago
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 ?
- Fripplebubby 8mo ago
  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.
  - monocasa 8mo ago
    To be fair zoom did claim E2EE, with one of the ends being their servers.
    - morpheuskafka 8mo ago
      Speaking of Zoom and encryption, its crazy that they bought Keybase (I think they basically said it was largely an acquihire) years ago, and have neither shut it down as everyone thought, nor materially changed it in any way. Unless they changed something it even gives 200GB cloud storage (KBFS) iirc.
  - antonvs 8mo ago
    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.

erithax 8mo ago

> We believe that this is the largest rollout globally of any library written in Rust. I think that crown currently goes to https://github.com/googlefonts/fontations 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 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/signalapp/libsignal

mdriley 8mo ago
Just a few more Rust libraries we've shipped in Chromium: - https://github.com/image-rs/image-png https://github.com/image-rs/image-png - https://github.com/webmproject/CrabbyAvif https://github.com/webmproject/CrabbyAvif - https://github.com/RCasatta/qr_code https://github.com/RCasatta/qr_code - https://github.com/unicode-org/icu4x https://github.com/unicode-org/icu4x
dcsommer 8mo ago
Just for reference, Wamedia ships on the major Meta apps and on iOS, Android, Desktop, and Web platforms.

justinlords 8mo ago

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

chinathrow 8mo ago
We really need an AI filter here on HN.
- stingraycharles 8mo ago
  A comment like this works as well, let the community do its thing.
  - rvnx 8mo ago
    There are a couple of bots here. Quoting a user: keeping it simple: a flat $15,000 to get you on the front page of Hacker News. [...] contact e-mail below Expensive, but now with LLMs it's super cheap to do. 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
    - stingraycharles 8mo ago
      Do you have any actual evidence that these types of services are being offered for that type of price point, though? 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.

londons_explore 8mo ago

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

jraph 8mo ago
What one should do about this? I mean, beside working on lowering that number. (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.
- embedding-shape 8mo ago
  I guess if you want to lower that number, you'd need to build something better, in some way. Answered as another European who've had Whatsapp forever, as some stubborn people refuse to move away from it, and also bunch of businesses use it.
  - 01HNNWZ0MV43FF 8mo ago
    Network effect is killer. "better" would include having more than 3 billion people already on it. 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.
    - embedding-shape 8mo ago
      > Network effect is killer. "better" would include having more than 3 billion people already on it. 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 :)

aloukissas 8mo ago

I love how Meta will do anything but prevent phishing and prepaid credit card scams in Whatsapp/Messenger

yasmineroy33 8mo ago

[dead]