WhatsApp Blocking Encrypted Calls to All Saudi Numbers

> but refusing to do so would be reason to have them dismissed from their jobs.

I've quit jobs on principle before. The key is to have a nest egg.

> Many employees are expats; leaving their jobs would mean a loss of their residence and thus deportation.

Could they find another job?

Erm, well...I suppose this could be done if you're fond of the "navigating through the digestive terminus to arrive at the synovial hinge" method[1]. There are several much easier and much less lossy ways of blocking voice transmissions streams that doesn't involve continuous and arduous logging of IP addresses or even blocks of IP addresses.

---

[1] also known as "going through your ass to get to your elbow"

I beg to differ. ZRTP is currently the best choice for voice when the caller and callee share no key material to begin with. In the context of Signal-the-app, the caller and callee often do share key material, but the protocol (to the best of my knowledge) doesn't bother to use that key material to authenticate the voice channel. This means that two users with the ability to securely text-message each other can still have their voice calls tapped if they fail to validate the short code each time.

The same omission also means that you cannot confirm that you have real end-to-end encryption by making a voice call and comparing the short authentication string on the screen.

I don't know whether Signal-the-protocol in WhatsApp is better designed, but calling ZRTP a good choice is ignoring the fact that current uses are not well thought out.

Good luck convincing them that the location is not being logged permanently by WhatsApp servers -- or even sent to them in the first place.

Your argument is essentially "engineers at steel plants make steel, which can be used to make guns, which can be used to kill."

At some point, the chain of causality is so remote that assigning unequivocal judgments of evil becomes logically absurd. Are port scanners evil now too?

As a quick example, one strategy (although personally I've always questioned it's viability, but it's just one of many examples) is a network admin may install a filter that deep searches packets for common SQL injection or XSS strings. This is done as a secondary measure to possibly prevent malicious requests.

Other examples are if you want to force employees to not be able to send certain documents or information outside of the company for compliance reasons, you can scrub traffic for that information. Obviously more complex.

The general concept is that it's useful for when you know you do not want specific traffic crossing your network. Ironically, it's the same use case scenario with draconian governments preventing encryption, but in the production or corporate scenario the use case is not ethically unsound.

This is much different than (my own wording): "anyone working in DPI for a company they know is selling their products to a police state".

It is absurd to blame open-source developers, researchers, or even employees at company's whose software has a legitimate purpose but is illegally exported and misused. They're just doing their job, since the technology has legitimate uses, as you've acknowledged. Blame the governments, not the programmers.