> We first show how travel eSIMs often route user data through third-party networks [---] Second, we analyze the implications of opaque provisioning workflows, documenting how resellers can access sensitive user data [---]. Third, we validate operational risks such as deletion failures and profile lock-in using a private LTE testbed.

So not about eSIM the technology, but the business landscape inviting opportunistic business people when the bar of entry is lowered. Table 1 is worth a read. The outrage bait about traffic being routed through China shouldn't matter too much to the common person, since we're mostly using TLS. If you're on DoH (DNS over HTTPS), you're even using it for host lookups.

> The outrage bait about traffic being routed through China shouldn't matter too much to the common person, since we're mostly using TLS.

That should matter a lot to the common person, TLS or not doesn't matter, what matters is who talks to who, and who talks when. That information alone can give you many useful insights.

It might not matter hugely to most people, that's true, but as someone who's used eSIMs while abroad in both Australia and Canada earlier this year (from Airalo and Nomad - they seemed at the time to be fairly well regarded), I was surprised to see my traffic routed through Hong Kong in both cases.

Google and Duck Duck Go both on the phone assumed I was in Hong Kong when searching, even though I was in Sydney and Vancouver respectively, which did make searching for local places a tiny bit more frustrating.

What matters very much in practice is the latency. It's fine if you just need a little bit of connectivity to occasionally send a message or be able to find something on Google Maps, but just browsing the web can be painfully slow with some of the providers.

1/ ISP or the website Youre accessing can see the DNS queries and block traffic. My eSIM routes through Hong Kong, which means no ChatGPT.

2/ iPhones don't get you set the DNS provider / DoH for cellular

3/ DoH breaks wifi redirect walls, making it tedious to enable/disable. Like you cant just enable DoH for certain apps or disable it for others.

What if TLS won't be relevant in a few years to a decade? Bad actors can hoard encrypted traffic and have the data decrypted when the time comes?

TLS exposes hostnames in plaintext via SNI. If using TLS version below 1.3 hostnames contained in the server certificate are in plaintext, too. ECH still "experimental", not in widespread use, no delivery deadline.

In theory encryption is something that protects the "common person", but SillyCon Valley's version of encryption, "TLS", is, unfortunately, mostly used for data exfiltration by third party intermediaries, so-called "tech" companies, i.e., opportunistic "business people".

Rather than protecting the "common person", the _primary_ use of "TLS" is to faciltate violation of the "common person's" privacy for profit, and to protect the third party intermediary's privacy intrusions from detection by the "common person", by making it difficult for the "common person" to monitor the outgoing traffic from their computers.

The privacy risk created by this third-party controlled encryption ("TLS") is why corporations must perform "TLS inspection". They have to decrypt TLS connections and then re-encrypt them in order to monitor the outgoing traffic from their networks. But the opportunistic "business people" in SillyCon Valley know the "common person" will not do TLS inspection.

But that's not all. Further third parties, more opportunistic "business people" called "certificate authorities" play a disproportionate role in brokering TLS connections, deciding on behalf of the "common person" who is trustworthy and who is not. This largely relies on "ICANN DNS", another laughable SillyCon Valley implementation, and is thus severely flawed, but that is another topic.

SillyCon Valley's so-called "tech" companies utilise this third party "CA system" to make it difficult for the "common person" to exercise control over deciding who they want to trust or distrust, e.g., by frustrating the use of so-called "self-signed certificates" by the "common person". Meanshile, the SillyCon Valley companies ensure that _by default_ the SillyCon Valley companies' certificates are trusted. In some cases, the certificates (or their digital fingerprints) are hardcoded into software used by the "common person".

Despite what the average "tech" worker would like the "common person" to believe, "TLS" is not synonymous with "encryption". Nor is criticism of TLS necessarily criticism of encryption. TLS is only a lame, user-hostile implementation of encryption that the "common person" must suffer while so-called "tech" companies use it to protect their surreptitious data collection from the "common person".