Ask HN: How does my ISP know I am making a WhatsApp call?
8 comments
They do it via operator specific IP pools https://www.whatsapp.com/cidr.txt
https://en.wikipedia.org/wiki/Zero-rating
https://onlinelibrary.wiley.com/doi/10.1155/2020/7285786
(you identify the traffic, and then you deny or degrade the connection based on heuristics)
https://onlinelibrary.wiley.com/doi/10.1155/2020/7285786
(you identify the traffic, and then you deny or degrade the connection based on heuristics)
They're just monitoring the types of traffic you send to through them as your ISP, and where it's headed to. If you're sending packets of voice data, encrypted or not, and connecting to Whatsapp's known public servers that handle voice data, then they can block that data.
There are various ways to identify the type of connection that is being made. The most straightforward way for the service provider to block some traffic is to put in place a firewall rule that blocks specific protocol/port number combinations. This won't work if WhatsApp were to use HTTPS on port 443 because then the call would look identical to regular web traffic.
Another possibility is related to the fact Meta is likely cooperating in the data bundle scheme. So it might be that WhatsApp is intentionally sending a specific signal of some kind that Econet can use to determine what each connection is for. There is a good overview of some of the possible methods on Wikipedia, for example: https://en.wikipedia.org/wiki/Deep_content_inspection
Another possibility is related to the fact Meta is likely cooperating in the data bundle scheme. So it might be that WhatsApp is intentionally sending a specific signal of some kind that Econet can use to determine what each connection is for. There is a good overview of some of the possible methods on Wikipedia, for example: https://en.wikipedia.org/wiki/Deep_content_inspection
In the before times, I ran the engineering side of WhatsApp's special pricing / zero rating program. Things may have changed a bit since then, and there's some stuff I heard about but never got the details on. A couple notes:
a) Several carriers offered programs without connecting up with us. AFAIK, that's the case for the airline free messaging programs. I've never been sufficiently motivated to do packet traces while in an airplane, but it could be interesting to try to figure out what they're doing.
b) there is (or was) support from WA for carriers to do special pricing for messaging (including multimedia) separate from real time (voice/video calls). When I was doing this, this was primarily done by having different address pools for messaging and voip relay servers. p2p voip makes it harder to special price and I don't know how that's handled (but in this case --- the carrier seems to be only allowing traffic for messaging, so p2p voip doesn't need to be specifically matched)
c) it's not that hard to look at a packet trace and see what's what anyway. chat isn't TLS, multimedia is, calling is different too. Even if everything looked like TLS, packet spacing and sizes will make the usage clear. Chat is going to be a lot fewer packets, many of them small, and irregularly spaced. Multimedia is going to be an initial clump of packets and then ack clocked; mostly full sized packets. You can't really change the nature of calling packets to look like one of the others without compromising quality of the call.
d) I personally really enjoyed seeing advertisements for WhatsApp Twitter Facebook plans, but corporate wasn't as happy about carriers advertising WTF plans ;)
a) Several carriers offered programs without connecting up with us. AFAIK, that's the case for the airline free messaging programs. I've never been sufficiently motivated to do packet traces while in an airplane, but it could be interesting to try to figure out what they're doing.
b) there is (or was) support from WA for carriers to do special pricing for messaging (including multimedia) separate from real time (voice/video calls). When I was doing this, this was primarily done by having different address pools for messaging and voip relay servers. p2p voip makes it harder to special price and I don't know how that's handled (but in this case --- the carrier seems to be only allowing traffic for messaging, so p2p voip doesn't need to be specifically matched)
c) it's not that hard to look at a packet trace and see what's what anyway. chat isn't TLS, multimedia is, calling is different too. Even if everything looked like TLS, packet spacing and sizes will make the usage clear. Chat is going to be a lot fewer packets, many of them small, and irregularly spaced. Multimedia is going to be an initial clump of packets and then ack clocked; mostly full sized packets. You can't really change the nature of calling packets to look like one of the others without compromising quality of the call.
d) I personally really enjoyed seeing advertisements for WhatsApp Twitter Facebook plans, but corporate wasn't as happy about carriers advertising WTF plans ;)
Thanks for clarifying these details! Obviously much better than my pure speculation, though I'm not sure why I got downvoted for it.
Id imagine they're blocking access to the IP, or the endpoints used for certain functionality, like WhatsApp calls
this is hilarious, what a bunch of grifting cunts.
If you initiate a call, the call goes through, it will ring for the other person but as soon as they answer, your WhatsApp will be stuck on the "connecting" screen. The same is true for the reverse i.e. if someone else calls you, you get stuck with a "connecting" screen as soon as you answer.
Aside from it being very annoying that my "240MB" of data is apparently unable to make a call on WhatsApp, I am generally curious how they might be doing this, the simplest explanation I have is they limit the bandwidth so much that a call cannot go through.
Whatever method they are using to do it, I imagine it can also be used to "fingerprint" someone. It's not a lot of information, but it can be a useful/helpful data point if coupled with other data.