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

141–150 of 151 posts

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

#141

Post by morpheuskafka »

monocasa wrote: post #53
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.

To be fair zoom did claim E2EE, with one of the ends being their servers.

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.

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

#142

Post by pornel »

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.

I mean you get one upfront cost for things like allocators, common string manipulation and std::fmt, std::{fs, io, path} helper functions, and gathering of pretty backtraces for panics (which is a surprisingly fiddly task, including ELF+DWARF parsers and gzip to decompress the debug info).

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.

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

#143

Post by jerf »

g947o wrote: post #124
jerf wrote: post #117

Earlier quoted context omitted.

Weight training equipment lasts decades all the time. It's just big piles of metal, it's not hard to get right. 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 use…

So you don't have a reference. I'm just going to ignore this.

If you are the sort of person who needs a reference for "weight equipment lasts a long time", feel free. Whatever guilt and shame you think I should be feeling over such a claim, believe me, I don't. I'm more in the "feeling pity for you" department here; I've been around enough to know what kind of person types messages like this.

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

#144

Post by harikb »

morpheuskafka wrote: post #139
harikb wrote: post #80

Earlier quoted context omitted.

As a developer, I tried building an app that needs to use Whatsapp for communication. Unfortunately my phone number got blocked by the second test message. No Spam. Not marketing, just a test message to my own number. Along with it, they blocked my entire business, my LLC, and anything tied to it. I have been trying to get hold of anyone or anything at Whatsapp. I've spent 6 months trying to navigate the bureaucracy.…

The number is only checked at login, and after that you can now create a WebAuthn passkey (iCloud Keychain/Google Passwords synced to your next phone) for future sign-ins so it's actually only needed for first sign up. So just get a prepaid SIM or eSIM and make another account unless your business is so large that tons of people know your number.

Sorry I am confused. I have a "WhatsApp Business Account", tied to an "Business" (verifications all done). What I am talking about is registering a phone number that acts as the "Sender/Responder" of the messages from my customers. I am not trying to use WhatsApp from my phone manually, but have my app communicate with my customers programatically. Hope this is clear.

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.

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

#145

Post by galangalalgol »

surajrmal wrote: post #129
galangalalgol wrote: post #70

Earlier quoted context omitted.

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.

I agree, but if you use more of the std library it will contribute more to the final image. I can write a 100 line rust file that ends up being 1MiB (even after lto) because I maximize as much code from the standard library as possible. This is not a knock on rust, but your statements can be a misleading as well. In practice most folks ignore the majority of the standard library so only a few hundred kib of std libra…

Bit late, but I made a small program that did network and file io as well as using a variety of containers and running system commands. I couldn't get the default release over 650kB. Using a single codegen unit lto strip and panic=abort got that down to 432kB. Using build-std didn't get it any smaller still. When I added optimization for size was the only way I got build-std to shrink things any further than the other options alone, and that only got me 10kB. My conclusion is that build-std is not a substantial contributor. Using std seems to add 300kB-500kB depending on how much you use. That seems like a lot to me because I am old, but elf binaries add several kB of header so maybe I should stop worrying so much.

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

#146

Post by jsgf »

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?

This is built with buck, and core/std are built as a source dependency.

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

#147

Post by surajrmal »

galangalalgol wrote: post #145
surajrmal wrote: post #129

Earlier quoted context omitted.

I agree, but if you use more of the std library it will contribute more to the final image. I can write a 100 line rust file that ends up being 1MiB (even after lto) because I maximize as much code from the standard library as possible. This is not a knock on rust, but your statements can be a misleading as well. In practice most folks ignore the majority of the standard library so only a few hundred kib of std libra…

Bit late, but I made a small program that did network and file io as well as using a variety of containers and running system commands. I couldn't get the default release over 650kB. Using a single codegen unit lto strip and panic=abort got that down to 432kB. Using build-std didn't get it any smaller still. When I added optimization for size was the only way I got build-std to shrink things any further than the othe…

If you build the standard library as a shared library it will be 4+MiB. The portion of that which you end up using is variable but there are ways to accomplish large usage without a great deal if code. I can get a 1.5 MiB binary down to 500KiB by dynamically linking the shared library. It's a net fun because I have many such binaries so it saves size in aggregate. It really does come down to what subset you use though.

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

#148

Post by vlovich123 »

embedding-shape wrote: post #137
vlovich123 wrote: post #135

Earlier quoted context omitted.

Facebook chat preceded Messenger which was a rebranding and separating into a standalone app precisely because WhatsApp ate their lunch so bad. 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…

Let me preface this with that my experience comes from Sweden in the 90s and 00s, and is a correct and truthful lived experience of my life. Seemingly, things were different were you lived, and that's fine, but that's not how it worked all across Europe, so at least we can agree on that :) The initial claim of "WhatsApp happened at a time when, in Europe, you paid for SMS." maybe was true in parts of Europe, but clea…

I think we can agree that Sweden is not a representative sample of what happened in Europe as a way to explain why WhatsApp became dominant for the majority of people in Europe.

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.

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

#149

Post by imtringued »

harikb wrote: post #80
jraph wrote: post #71

Earlier quoted context omitted.

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.

As a developer, I tried building an app that needs to use Whatsapp for communication. Unfortunately my phone number got blocked by the second test message. No Spam. Not marketing, just a test message to my own number. Along with it, they blocked my entire business, my LLC, and anything tied to it. I have been trying to get hold of anyone or anything at Whatsapp. I've spent 6 months trying to navigate the bureaucracy.…

You're supposed to go to a local WhatsApp partner instead of contacting WhatsApp directly if you want to get API access for sending messages.

https://business.facebook.com/messaging/partner-showcase

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

#150

Post by aaravchen »

jraph wrote: post #121
darrenf wrote: post #112

Earlier quoted context omitted.

There is legislation in the EU, and BirdyChat announced compatibility. https://www.birdy.chat/blog/first-to-interoperate-with-whats...

BirdyChat, the existence of which we all first became aware at the same time as that legislation and which nobody can use yet, only join a waitlist... :-)

And apparently requires explicit WhatsApp user opt-in to be available. Meta is of course going to maliciously comply as best they can, so they've made sure interoperability is off by default and requires a specific opt in.
Post reply on HN