WhatsApp is E2EE, but Meta controls both ends. Instead of reading your plaintext on the server, they read it on the client. Not that tricky.
I presume the hardest part would be avoiding detection via decompilation and other reverse engineering techniques. Not familiar with that space (can anyone here shed some light?), but it seems likely that an entity with Meta’s resources would be able to figure that out.
E2EE probably protects well against bulk data collection (traffic analysis would sniff out sending 2x volume of data pretty quickly). But something more subtle and targeted, smuggled out in various fields of various protocols, would be hard to detect.
They only need to get caught doing it once to have a gigantic lawsuit on their hands. They could possibly pull it off very selectively, but doing it in a dragnet fashion seems incredibly risky.
What grounds would the lawsuit be based on? I can’t imagine that slurping any kind of data would be inconsistent with their EULA.
The only risk would be the reputational damage. And as far as their bottom line is concerned, the impact of that would be negligible—how many of WhatsApp’s billion(?) users know that it’s supposed to be E2EE, let alone are under the illusion that Meta doesn’t have access to their data?
Publicly stating to not have access to message contents yet doing otherwise, i.e. outright deception, doesn't seem like something you can EULA your way out of in most jurisdictions.
Beyond that, the GDPR and similar laws also impose limits as to what you can EULA away even without being deceptive about it.
At best, it would come down to the details of what their marketing materials have claimed wrt to keeping contents secret. Do you have anything concrete they've promised? I don't remember anything, but maybe that's just my bad memory.
My suspicion is that things like URL previews, or when the app calls a handler to open a link (YouTube, browser), are still monitored.
So e.g. opening a link to an Amazon product that a friend sent makes you a target for ads in that category.
It's a suspicion, they'd probably argue their EULA allows this. The typical "we have to monitor links for dangerous content" is always the standard bullshit.
This is indeed a common vector of privacy leaks on either the recipient side (to the sender, in this case, if they operate the target of the link for which a preview is being rendered) or to the platform provider (if the preview is rendered server-side). But last time I checked, in WhatsApp, URL previews are rendered exclusively on the sender side and then sent as (E2E encrypted) media to the recipient.
The world is a big place. Of course it happens. But, colloquially speaking, "getting people's attention" suggests that more than a rounding error took heed.
I'm glad your CEO cares. It makes a difference and I hope you feel good about that. And the world would be a better place if more did care. But, to a first approximation, it seems like organizations don't care about data breaches.
I don’t honestly see how that’s necessarily better. Now your ISP can tap your individual household to see what’s being queried. Whereas if you use Do[THU] to connect to some remote recursive resolver it practically functions as a mixer.
That’s why I suggested routing queries through a VPN or Tor if that’s a concern. This bypasses centralized DNS services that may face national blocking orders while retaining privacy.
I don't see how that's an improvement over using a big public resolver. Probably worse privacy (you've basically just swapped your ISP for another virtual ISP), and worse performance (likely longer network paths from your resolver to various authoritative servers, as well as not getting the benefits from the nicely-warmed caches that big public resolvers will have).
A “virtual” ISP may not have my personal details, especially if I am careful about it. I agree that it’s a tradeoff. Some people may live under regimes where big DNS servers are blocked or under legal orders, or they may have concerns about imminent DNS censorship or logging orders.
- Personal details isn't the point (and while a VPN service may have those, a big DNS resolver certainly doesn't)--the point is that correlating DNS traffic with your source/home IP address is likely easier with a big DNS resolver. In any case, I don't see how the VPN approach is superior here.
- People may also live under regimes where VPN providers are blocked. Unless there's some order of magnitude more limitations on DNS resolvers, I don't see how the VPN approach is superior here.
Anonymizing VPNs, especially multi-hop ones, and Tor in particular makes correlation much more difficult. Mullvad paid in crypto or cash is a very good option.
I agree about blocked VPN providers, but in the real world it’s usually possible to get around those blocks, even in places like China where there are sophisticated national firewalls.
These things you suggest incur significant latency. Also, can you simply pipe DNS over Tor? I don't see how, since Tor is TCP-only. I suppose DoT or DoH could potentially work, but not all authoritative servers may support those protocols. The TCP handshake will also add further latency.
Furthermore, even once you layer all that tunneling on top, it's still unclear how doing recursive resolution from your end of the tunnel is better than going through one of the big resolvers. The privacy benefits seem marginal at best. Overall, I don't think you have convinced me in the slightest of your original point that "really anyone who cares about bypassing national blocking orders should run a local caching recursive resolver."
If your centralized DNS server receives a blocking order, what are you doing to do? You’ll have to do something. Give me another alternative then. In the current geopolitical environment, this is not idle speculation, it’s a real threat.
Latency is a tradeoff, I mentioned there are tradeoffs. For an individual or home network, the latency should not be a problem especially with caching.
As for TCP/UDP, current RFCs say that DNS servers must accept TCP, but not all may follow the standard and some misconfigured firewalls may block it. But it doesn’t seem to be an issue when tunneling all traffic over Tor using something like Tails. So I don’t think this is really a problem.
Very much agreed with you that IPv6 is indeed fine. I think it’s even good, even beyond the necessary feature of providing an appropriate number of prefixes.
But I do narrowly agree with GP that CLAT should’ve been a goal from the beginning. Dual stack is such a losing proposition for any org that doesn’t substantially benefit from deploying IPv6. Adding in CLATs with a plan to go 464XLAT from almost day one would have massively changed the calculus.
Dual stack is the problem, we've still got devices which are ipv4 only. I've never seen anything that's ipv6 only.
Even on my standard linux laptop, and corporate windows laptop, with the hack of DNS64, I still have issues with my ipv6 subnet. Yet I have no problem with my ipv4 subnets.
So I don't bother with ipv6 - it's a toy. There is no benefit at all to me, but I can't get rid of IPv4 because some devices won't work with ipv6, and others will work but have bugs.
The ivory towers felt "we know best, everyone will move to us, we don't need backwards compatibility". That arrogance put ipv6 back probably 30 years, maybe more. Building in backward compatibility at the protocol level (so 464 etc) would have removed the need for other hacks (dns64) and allowed a trivial transition.
Yep, agreed on pretty much all counts. The end goal is obviously the same for both dual-stack and translation technologies. But the latter makes things so much lower risk and gives you (the network operator) actual progress and a chance to simplify along the way. Providing IPv4-as-a-service is an actual plausible thing, compared to dual stack's now-draw-the-rest-of-the-owl vision.
Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.
At work I can't see being able to drop ipv4 for at least 20 years due to applications and hardware which still relies on ipv4 (I've got some endpoints which don't even support igmpv2!)
I still haven't had a single failure for someone who can't reach an ipv4 endpoint.
I'm not suggesting dropping v4 connectivity altogether. I'm suggesting migration to a v6-only core by providing IPv4 as a service via 464XLAT, IPv6-Mostly, or only offering IPv4 to select network segments using SIIT-DC-2xlat: https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual...
No. Just no.
If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before. And dual stack is no issue. But as always the ISP does need to not fuck up and you operating system should follow RFCs.
All these transitions methods are far to expensive and an unnecessary overhead.
> If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before.
I think you forgot half a sentence here. What was your point?
> And dual stack is no issue.
How can that possibly be so? Having enough address space to comfortably architect gives you room for far superior topologies, meaning that running dual stack at the bare minimum means that either your IPv6 topology is being compromised to map cleanly to your v4 topology, or that you're running two different topologies altogether. You need two times the sets of firewall rules, two times the number of address configurations...everything in your infra roughly 2x.
> All these transitions methods are far to expensive and an unnecessary overhead.
How so? Running 464XLAT on a device with a proper CLAT has minimal overhead, and the PLAT is no worse than running a NAT for IPv4.
Running nat on ipv4 is no worse than running a stateful firewall on ipv6 only, I don't get the complaints about it. Modern firewalls do far more with deep packet inspection, SSL unwrapping etc. NAT is a hardware function on enterprise access switches let alone firewall layers, any home router would have to do firewalling at their router anyway.
Well performance really isn't something I would point to at all. While I believe it can become problematic with great scale (e.g. those expensive CGNAT boxes), it's more the architectural and connectivity aspects that are problems:
Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.
Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).
I'm not advocating dual stack either. Like I said in my other reply to you, I am suggesting IPv4-as-a-service using standard translation technologies and architectures.
Adding on to what others say about printenv, various diagnostic tools (e.g. crash reporting stuff) will capture the environment. Env vars are just categorically so easy to accidentally leak that it can’t even be classed as an insecurity.
I’ve never even heard of the DHCP option for this. How widely adopted is it? It’s surprising to hear it called “the right way” when it wouldn’t work for a single-stack IPv6 (or IPv6-mostly, probably) network.
reply