I'd be interested in hearing WhatsApp's response to this.
Or moxie's, for that matter. He's been contacted by the Saudi government before and publicly turned down their offers to be complicit in their human rights violations. (He also wrote the encryption that WhatsApp uses.)
I have no special insight, but it's a fact that SA drops VoIP traffic. The UX for that is pretty bad, calls fail to connect by timing out after 5min or whatever, and people are left trying over and over again or waiting around hoping the call will connect. I think it could make sense to short circuit that process and display an immediate error to the caller that lets them know this call just isn't going to work.
The author's suggestion that it's impossible for SA to block VoIP without blocking messaging is incorrect.
They're simply providing a better user experience. The Saudis blocked encrypted calls, and users would have wait staring at frustrating repeated timeouts and long 'connecting' hangs.
Therefore Whatsapp simply said OK, let's just improve the users experience by giving them an immediate error informing them.
The gist explicitly claims that's not possible. Specifically, it claims that there's no way for the Saudi teleco to distinguish encrypted phone calls from encrypted messages, and since you can send encrypted messages to Saudi users, there's no technical reason why you can't also call them. The implication is that if WhatsApp did allow the calls, the Saudi telecos might block both calls and messages (since they can't distinguish them), and so WhatsApp disallows calls to avoid provoking them. And the OP's point is that WhatsApp should detect whether the user is actually in-country and allow the calls if they're in another country (since the Saudi telecos won't matter there).
Bandwidth won't be apparent during the handshake. And voice data isn't really that large anyway, though it would be plausible to detect that some kind of stream is going on as opposed to discrete messages. Still, that would have to come mid-call rather than when the call is attempted.
Sure, in this case it's based on what port they are using. But, it's not a winnable problem due to bandwidth and the option to simply block everything. Limit encrypted streams to 3kbps and you can do eCommerce or slowly send a selfie not real time audio.
WhatsApp calls are made to a different port; I worked at a teleco in Oman and that's how they blocked the calling feature while keeping messaging alive.
To localize this behavior to the US as an example, Verizon wireless is known to block SIP traffic coming and going out of port 5060; it's entirely possible the Saudis are engaging this very similarly and have effectively blocked traffic, encrypted or not coming and going to a specific protocol port.
So I don't think saying "there's no way to tell" is entirely accurate
Seems like WhatsApp could easily choose to use a different port if they wanted to, but I guess this comes back to not wanting to have their encrypted messages get blocked.
VoIP traffic is UDP, and will always be very easy to identify. We barely have functional circumvention strategies for higher-latency traffic types, so building a circumvention strategy for traffic like realtime voice with ultra low-latency requirements is a tall order. Honestly getting VoIP to work well in the best possible network scenarios is enough of a challenge.
I assume that higher latency communication like WhatsApp's push-to-talk "voice notes" works just fine in SA though.
The telco doesn't have much of a choice, as the rules are administered by the TRA (telecommunications regulatory authority), and by proxy, state security.
No one that worked there wanted to do it, but refusing to do so would be reason to have them dismissed from their jobs.
Many employees are expats; leaving their jobs would mean a loss of their residence and thus deportation.
> I correct myself, then: Your police state sucks.
Police states are very shitty indeed.
> I've quit jobs on principle before. The key is to have a nest egg.
A lot of the expats come from Lebanon, Syria, Pakistan, India, and occasionally Eastern Europe. Almost all of them that I know have families they need to support (immediate and sending remittances), and the money is a lifeline. Being deported back and/or being blacklisted from the GCC is a life-ruining scenario. Getting visas to the west is not always an option.
>Could they find another job?
It's possible, but all countries in the GCC operate under a Kafala (sponsorship) system. Having it revoked in one GCC member state raises complications in others.
For those wondering, GCC = Gulf Cooperation Council, not the compiler.
You can definitely distinguish with near 100% reliability if someone is messaging or calling, even if there is encryption involved.
All you need to do is profile for relatively constant data transfer rates over the course of many minutes that exceed a very low minimum.
If Whatsapp uses a media proxy for calls then you could just trigger on connections made to these servers where these data transfers in question occur.
But even if they don't use a media proxy they'll the clients will connect to specific IP's for call signalling and that's when you'll also know that a call was attempted.
I'm neither defending Saudi Arabia nor Whatsapp, just wanted to let you know that there are very simple ways to detect calls. I'm sure that there are even better, much more advanced techniques that are currently in use by both oppressive (and likely our) governments.
Detecting calls like that would be for detecting calls in-progress, not for shutting them down during the initial handshake, which is what the gist claims is WhatsApp's explanation.
My point was that this is one way to detect the IP where the client connects to for calls as call signalling, call media transfer and chat messaging all connect to different IP's.
Once you have that you can block media transfer, or if the clients use peer to peer media transfer at least block the call signalling.
After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used.
Bandwidth usage pops up in your logs that somehow resembles the profile of a call - investigate by doing a simple test and then block the IP.
After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used.
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 wrote myself that there are surely more advanced ways to do that but I'm not a professional in this particular area as I'm not in the business of censoring people or blocking communication.
Still my point remains valid I believe: The OP claimed with certainty that no one could know if a call is being made which is wrong.
But you can outline your ideas on how to detect a call attempt without "going through your ass to get to your elbow" as you put it.
I still feel that blocking IP's or ports is an easy solution for governments that feel the need to censor.
There are plenty of DPI/TM solutions that identify and classify the protocol very quickly and efficiently, every ISP today does it.
It's highly unlikely that a Saudi or any modern telco would would not be able to analyse the traffic and extrapolate the exact protocol and application from it as well as other information such as if it's an encrypted stream or not (heck testing if data is encrypted or not is as simple as running compression on random samples and checking the compression ratio, you'll have to classify if the data is compressed to begin with but if it's not compressed data and it's not compressible it's quite likely to encrypted).
This would work for a call in-progress. The gist explicitly claims the calls are blocked during the handshake, which would be before there's enough data to analyze. It appears from other comments that what's really going on is calls simply use a different port and that port is blocked.
The root comment on this thread resolves that distinction: it might make sense from a UX perspective to block calls that are known in advance not to be workable. WhatsApp can sensibly be reacting to something that occurs once a session is in steady state.
Sure, though I think there's still merit in the OP's request for WhatsApp to detect when a customer with a Saudi number is actually in another country and allow the call to go through (though I don't know how easy it is to detect that).
Assuming WhatsApp uses ZRTP, it's possible to detect and block encrypted calls no matter what port is used because the ZRTP advertisement can be seen in the RTP packet.
In order to know when ZRTP will fail WhatsApp would need to maintain lists of address space where ISPs drop such packets. It would have to be done on the client side, but then clients can't easily discover their public address because NAT. The signaling server that sets up the call could check easily, but if the server decided when not to use encryption that would be a backdoor.
It's easier to just do it by country code, despite the drawbacks.
ZRTP is a key agreement protocol. It sets the key for SRTP, which is ultimately responsible for securing the RTP payload. SRTP keys can also be set by the signaling server, but then the encryption is not end to end. There's another protocol called SDP to handle this
Signal does use ZRTP. It just doesn't use SIP. ZRTP is currently the best choice for voice.
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.
Actually, ZRTP supports SAS signing. This allows applications that use Axolotl to provide additional signatures to ZRTP, enabling sessions to be confirmed without human intervention. See section 7.2 of RFC 6189 for details. Support for Axolotl integration was added to the very popular ZRTPCPP library on August 1, 2015.
I think it's still a good idea for clients to display the SAS even when signed with another key. Especially when that session was established with a protocol which uses the TOFU model.
The author is incorrect. While Signal Protocol is used to communicate an SRTP master secret and a session id, the clients still need to do an ICE handshake in order to establish communication with each other before the responder can even ring. It is very straightforward for SA to block that traffic, and it is established fact that they do.
It seems as if WhatsApp is short circuiting this frustrating series of timeouts to improve a flaky seeming UX. That strategy does negatively effect people on the internet who register for WhatsApp with Saudi VoIP numbers when they're in France, but it is a much clearer UX for almost everyone who is actually a Saudi WhatsApp user or calling actual Saudi users. What the author is demanding is a worse UX for the same outcome.
It sounds like there might be room for improvement, but I have a feeling that if WhatsApp were recording their users' locations in order to provide a more advanced location-aware version of the same strategy, people would not be very happy about that.
Seems like a lot of effort for an edge case. Now you've added a dependency on some network service you need to access (and from WhatsApp's POV: maintain) before placing outgoing calls. If you use GPS instead, you're dependent on having the location permission (which is not needed to run WhatsApp in general), and you're draining everyone's battery and adding latency to get a sufficiently accurate location lock. Doesn't seem like it would be worth the trouble to me.
There would also be a number of people complaining loudly, demanding to know "why does WhatsApp look up my exact location [using the GPS] at the precise time I make a call!?".
Good luck convincing them that the location is not being logged permanently by WhatsApp servers -- or even sent to them in the first place.
I've never been to Saudi Arabia, but in the UAE and Oman if you were to receive a WhatsApp call using a foreign number from a free country, lets say France, the handshake for the call would still be dropped with the attempted call failing.
On iOS, you would get an error saying "Call couldn't connect. X's mobile carrier or WiFi doesn't support WhatsApp calls".
I feel like I'm missing something; in what case does any data being communicated to a Saudi Arabian number, whose user is not in Saudi Arabia, pass over any Saudi Arabian territory?
You're probably missing the "That strategy does negatively effect people on the internet who register for WhatsApp with Saudi VoIP numbers when they're in France" bit. It's a reasonable trade-off in light of the complexities the alternatives carry with them, IMO.
> I have a feeling that if WhatsApp were recording their users' locations in order to provide a more advanced location-aware version of the same strategy, people would not be very happy about that.
They don't need to record your location. WhatsApp client can just query your IP address and silence the call-prohibiting UX if it finds out you're outside Saudi address space. This is an exceedingly obvious solution with no effect on user privacy.
Whilst it may be a better user experience for those with Saudi numbers in Saudi Arabia (calls would be blocked anyway) it is a much worse user experience for those with Saudi numbers not in Saudi Arabia (calls would work fine, but are blocked by WhatsaApp).
Maybe it's just a use case they missed - but quite a significant one!
Couldn't someone with WhatsApp/Facebook's resources find a way around the blockage?
Write a bunch of different protocols and switch randomly - or use steganography - use machine learning to evade the block - buy a bunch of existing apps and hide the data in their protocols - put up a fake weak encryption, detect "dissident" talk, and in that case generate a long nonsense recording for the censors from the voices of the speakers, hiding the true message steganographically :-) - or basically anything they can come up with.
Or - Saudi Arabia is not such a big market - make a complete theatric fuss about it and complain about human rights and so on, close all FB and WhatsApp connections and burn all bridges, and milk it for publicity.
(Only being half serious here :-) but I would be really tempted to do something mischievous in their case rather than comply.)
Governments and companies are very much on the same team these days (think of it as a one party state with occasional internal disagreements and manouverings) - so there won't be anything 'mischievous' going on from those quarters
WhatApp does the same for UAE numbers. If I initiate a call to my sister who lives in UAE I get an error saying that "Whatsapp calling is unavailable in the UAE" or something along those lines.
We worked around it by installing Signal, but she needs a VPN to be able to access it since it's completely blocked in the UAE (as well as Oman).
We get around this by texting each other before hand on whatsapp with the keyword "vpn" and then talk to each other over Signal. Quite the hassle.
Same is true of Egypt as well, but I presumed that WhatsApp checks and knows when telcos were just blocking degrading their service in generally, not specifically for encryption.
Quite ironically, I wonder if the Saudis remember Moxie at all ...
I think it should be clear that the Saudi government are the ones who are blocking this type of encrypted communication. WhatsApp is just taking the handling of this blockage and integrating it into the app UX so that its users understand what the problem is.
Thank you, WhatsApp! Oppressive governments, especially ones that have lots of resources to torment their citizens, should not get to play with our toys.
Saudi Arabia is one of the main US allies in the region. Millions of tax dollars go towards securing the Saudi regime every year through American military bases in the country.
Maybe they know it's going to be blocked anyway, and they are avoiding getting into the cat and mouse game of trying constantly new ways to get around it and are just telling the user they're not even going to try. It's not ratting anybody out, it's not being complicit with anybody, it's simply saying it's not even going to try to encrypt. It sucks, but you know who to blame? The Saudi government.
"However the only true solution that respects the human rights of Saudi users is to give them encrypted calls no matter the consequences, instead of downgrading them to using regular Saudi phone lines, which are tapped by a religious dictatorship."
The British-found US-supported Saudi state and its regime
is not a religious dictatorship. Geoff Simons described
it best, IMHO, when he came up with title "Saudi Arabia: The Shape of a Client Feudalism" for his book.
On an even fussier note, some people in the Arabian peninsula don't recognize the legitimacy of the state/regime. And they really hate it when they are referred to as Saudis. It's like calling Widerstand Germans Hitlerians.
This case is a brilliant reminder to anyone working in deep packet inspection/blocking/filtering tech that your work negatively affects the safety of millions of people in such countries at once.
This case is a brilliant reminder to anyone working in fiber optics that your work negatively affects the safety of millions of people in such countries at once.
But seriously, deep packet inspection is evil now? It's an extremely useful security tool.
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?
Do you possibly just have no idea that deep packet inspection has many legitimate uses, and is critical to security in many networks? Or are you simply ignoring that fact for the sake of your argument?
It's mostly useful for production and other corporate networks. It's basically a more powerful firewall, where you can enforce contracts on your network concerning what traffic is allowed to go in or out.
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.
I am not ignoring the legitimate use cases - and I never said that there weren't any. I simply pointed out that if you work in DPI/filter/blocking and your company sells to those regimes, that you support the oppression of the affected users.
I can help with some real world examples. One is Blue Coat.
That's not actually what you said. You said: "anyone working in deep packet inspection/blocking/filtering".
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.
At some point Whatsapp will be banned completely. Otherwise what would prevent conversations using push to talk. I use it when my connection or the other's end one is unreliable. What's the difference?
Tying an online messaging app to a phone number is fundamentally silly (attn Signal developers). Having phone numbers as one search item among many makes a lot of sense, but mandating a 1:1 relationship between phone numbers and app identities is like mandating a 1:1 relationship between horse stalls and automobiles.
It makes a lot of sense for mobile messaging apps, though, and that's what both Signal and WhatsApp are. Phone number == username is an implementation detail of Signal (the app) and WhatsApp and not something the protocol dictates. Other implementations could easily handle things differently.
> It makes a lot of sense for mobile messaging apps, though, and that's what both Signal and WhatsApp are. Phone number == username is an implementation detail of Signal (the app) and WhatsApp and not something the protocol dictates. Other implementations could easily handle things differently.
An extensible solution would be to use URNs as usernames, with tel: (https://tools.ietf.org/html/rfc3966) — or maybe sms: (https://tools.ietf.org/html/rfc5724) — URNs, e.g. tel:+1-201-555-0123 or sms:+12015550123. Then anyone who wanted to could also register a client using mailto:jsmith@example.invalid.
Even better would be to use opaque user identifiers (maybe using their own URI scheme …), with all the above used to search for other users.
Combine that with a server-mediated privacy-preserving contact list search scheme, and you'd have a huge end-user benefit: persistent identities across multiple devices, freed of the tiedown to telephones. Heck, it might even form the nucleus of a smart PKI based on SPKI/SDSI, better than either the PGP Web of Trust or XPKI's lunatic trust-all-of-the-CAs-in-the-world-to-certify-everything-in-the-world model …
85 comments
[ 2.8 ms ] story [ 141 ms ] threadOr moxie's, for that matter. He's been contacted by the Saudi government before and publicly turned down their offers to be complicit in their human rights violations. (He also wrote the encryption that WhatsApp uses.)
https://moxie.org/blog/saudi-surveillance/
More importantly, can anyone independently verify this? :)
The author's suggestion that it's impossible for SA to block VoIP without blocking messaging is incorrect.
Therefore Whatsapp simply said OK, let's just improve the users experience by giving them an immediate error informing them.
I live in the UAE and it's exactly the same over here.
So I don't think saying "there's no way to tell" is entirely accurate
I assume that higher latency communication like WhatsApp's push-to-talk "voice notes" works just fine in SA though.
No one that worked there wanted to do it, but refusing to do so would be reason to have them dismissed from their jobs.
Many employees are expats; leaving their jobs would mean a loss of their residence and thus deportation.
Such is life in a police state.
> 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?
Police states are very shitty indeed.
> I've quit jobs on principle before. The key is to have a nest egg.
A lot of the expats come from Lebanon, Syria, Pakistan, India, and occasionally Eastern Europe. Almost all of them that I know have families they need to support (immediate and sending remittances), and the money is a lifeline. Being deported back and/or being blacklisted from the GCC is a life-ruining scenario. Getting visas to the west is not always an option.
>Could they find another job?
It's possible, but all countries in the GCC operate under a Kafala (sponsorship) system. Having it revoked in one GCC member state raises complications in others.
For those wondering, GCC = Gulf Cooperation Council, not the compiler.
(edit for clarity)
All you need to do is profile for relatively constant data transfer rates over the course of many minutes that exceed a very low minimum.
If Whatsapp uses a media proxy for calls then you could just trigger on connections made to these servers where these data transfers in question occur.
But even if they don't use a media proxy they'll the clients will connect to specific IP's for call signalling and that's when you'll also know that a call was attempted.
I'm neither defending Saudi Arabia nor Whatsapp, just wanted to let you know that there are very simple ways to detect calls. I'm sure that there are even better, much more advanced techniques that are currently in use by both oppressive (and likely our) governments.
Once you have that you can block media transfer, or if the clients use peer to peer media transfer at least block the call signalling.
After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used.
Bandwidth usage pops up in your logs that somehow resembles the profile of a call - investigate by doing a simple test and then block the IP.
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"
Still my point remains valid I believe: The OP claimed with certainty that no one could know if a call is being made which is wrong.
But you can outline your ideas on how to detect a call attempt without "going through your ass to get to your elbow" as you put it.
I still feel that blocking IP's or ports is an easy solution for governments that feel the need to censor.
In order to know when ZRTP will fail WhatsApp would need to maintain lists of address space where ISPs drop such packets. It would have to be done on the client side, but then clients can't easily discover their public address because NAT. The signaling server that sets up the call could check easily, but if the server decided when not to use encryption that would be a backdoor.
It's easier to just do it by country code, despite the drawbacks.
Signal does use ZRTP. It just doesn't use SIP. ZRTP is currently the best choice for voice.
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.
I think it's still a good idea for clients to display the SAS even when signed with another key. Especially when that session was established with a protocol which uses the TOFU model.
It seems as if WhatsApp is short circuiting this frustrating series of timeouts to improve a flaky seeming UX. That strategy does negatively effect people on the internet who register for WhatsApp with Saudi VoIP numbers when they're in France, but it is a much clearer UX for almost everyone who is actually a Saudi WhatsApp user or calling actual Saudi users. What the author is demanding is a worse UX for the same outcome.
It sounds like there might be room for improvement, but I have a feeling that if WhatsApp were recording their users' locations in order to provide a more advanced location-aware version of the same strategy, people would not be very happy about that.
Good luck convincing them that the location is not being logged permanently by WhatsApp servers -- or even sent to them in the first place.
On iOS, you would get an error saying "Call couldn't connect. X's mobile carrier or WiFi doesn't support WhatsApp calls".
They don't need to record your location. WhatsApp client can just query your IP address and silence the call-prohibiting UX if it finds out you're outside Saudi address space. This is an exceedingly obvious solution with no effect on user privacy.
Maybe it's just a use case they missed - but quite a significant one!
Write a bunch of different protocols and switch randomly - or use steganography - use machine learning to evade the block - buy a bunch of existing apps and hide the data in their protocols - put up a fake weak encryption, detect "dissident" talk, and in that case generate a long nonsense recording for the censors from the voices of the speakers, hiding the true message steganographically :-) - or basically anything they can come up with.
Or - Saudi Arabia is not such a big market - make a complete theatric fuss about it and complain about human rights and so on, close all FB and WhatsApp connections and burn all bridges, and milk it for publicity.
(Only being half serious here :-) but I would be really tempted to do something mischievous in their case rather than comply.)
We worked around it by installing Signal, but she needs a VPN to be able to access it since it's completely blocked in the UAE (as well as Oman).
We get around this by texting each other before hand on whatsapp with the keyword "vpn" and then talk to each other over Signal. Quite the hassle.
[0]: http://i.imgur.com/rQu9Ocf.jpg
Quite ironically, I wonder if the Saudis remember Moxie at all ...
In the PRC, censorship is an inextricable part of the deal.
Ironic that Saudi is chairing there world's human rights office and denying an essential human right - right to private communication
The British-found US-supported Saudi state and its regime is not a religious dictatorship. Geoff Simons described it best, IMHO, when he came up with title "Saudi Arabia: The Shape of a Client Feudalism" for his book.
On an even fussier note, some people in the Arabian peninsula don't recognize the legitimacy of the state/regime. And they really hate it when they are referred to as Saudis. It's like calling Widerstand Germans Hitlerians.
But seriously, deep packet inspection is evil now? It's an extremely useful security tool.
Yes, it might be useful for some folks - it's really bad for others. People have died because of oppressive regimes targeting dissidents that way.
The idea that anyone working on technology that could be used for surveillance is morally culpable is flat wrong.
People have died because of fertilizer and particle physics. It does not make chemical engineers or physicists evil.
Yea I know, morale is a difficult topic these days.
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.
I can help with some real world examples. One is Blue Coat.
https://en.wikipedia.org/wiki/Blue_Coat_Systems#Controversy
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.
An extensible solution would be to use URNs as usernames, with tel: (https://tools.ietf.org/html/rfc3966) — or maybe sms: (https://tools.ietf.org/html/rfc5724) — URNs, e.g. tel:+1-201-555-0123 or sms:+12015550123. Then anyone who wanted to could also register a client using mailto:jsmith@example.invalid.
Even better would be to use opaque user identifiers (maybe using their own URI scheme …), with all the above used to search for other users.
Combine that with a server-mediated privacy-preserving contact list search scheme, and you'd have a huge end-user benefit: persistent identities across multiple devices, freed of the tiedown to telephones. Heck, it might even form the nucleus of a smart PKI based on SPKI/SDSI, better than either the PGP Web of Trust or XPKI's lunatic trust-all-of-the-CAs-in-the-world-to-certify-everything-in-the-world model …