Physically acquiring the SIMs is only one part of the process as they're pretty worthless without going through the activation process.

Prior to this year in Mexico (which introduced ID-based regulations around SIM purchase/activation), you could buy a SIM at a remote gas station, a data package in cash, and activate it without giving your name/email/etc. Now, in 2026, you have to show an ID/passport to do that.

The U.S. doesn't have a federal regulation (as far as I know) for this. That level of network protection is usually at the provider level. However, activating the SIM almost always requires an email or existing phone number and not just purchase/possession of the SIM+top-up card. Purchasing the top-up card sometimes can be done in cash, other times requires a pre-paid debit which has its own limitations/regulations due to a mix of KYC/AML. But applying said top-up card usually still requires at least some form of identity verification. For some of the top national providers, and I'm not sure what model they use to gauge risk to make this decision, they even require an SSN (for prepaid!) and run some form of a check on you (I'm not entirely sure if it's a soft credit check or what).

A SIM in the U.S. is significantly more difficult to acquire than a SIM in Mexico/many other countries.

E.g.

- Limit on # of SIMs purchased at retailers, low ability to use cash to purchase them, generally always on camera

- SIMs locked up behind the counter at lots of major retailers in the U.S.

- Activation requirements on U.S. networks for prepaid SIMs

Granted, if you're a company you can certainly acquire a lot of SIMs. A lot of questionable activity uses straw purchases, very similar to folks using smurfs to acquire pseudoephedrine in the 2000s.

That paper is about PKI-based session setup for End-End which is the ancestor of SSL/TLS. It even mentions a CAE which is effectively a CA and it does a synchronous handshake to establish a symmetric key. It's very clearly about transport layer security from end to end.

It's not about User-User E2EE (akin to Signal) and shares very little other than that data is encrypted from point A to point B.

RFC 4949 (Internet Security Glossary, Version 2) from 2007: https://datatracker.ietf.org/doc/html/rfc4949

     $ end-to-end encryption
      (I) Continuous protection of data that flows between two points in
      a network, effected by encrypting data when it leaves its source,
      keeping it encrypted while it passes through any intermediate
      computers (such as routers), and decrypting it only when it
      arrives at the intended final destination. (See: wiretapping.
      Compare: link encryption.)

      Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS,
      SILS, SSH, SSL, TLS.

      Tutorial: When two points are separated by multiple communication
      links that are connected by one or more intermediate relays, end-
      to-end encryption enables the source and destination systems to
      protect their communications without depending on the intermediate
      systems to provide the protection.

You quoted the MITRE paper (or the older paper it references) defining end-to-end encryption as:

> "data being enciphered at the source and remaining unintelligible until it deciphered at its final destination."

This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination". The application processing the data lived on the server. Therefore, by the definition you just quoted, SSL/TLS from Client to Server was "End-to-End Encryption" because the network (routers/ISPs) could not decipher it.

The "modern" definition (post-Signal/WhatsApp) effectively redefined "final destination" to mean "another human user," relegating the Service Provider to a mere hop in the middle. That is a massive semantic shift.

re Saltzer's "End-to-End Arguments": The paper argues that functions (like reliability or encryption) should be moved from the lower network layers (links) to the "ends" (hosts/applications). SSL/TLS is the literal implementation of this argument: moving encryption out of the network links (Link Encryption) and into the application endpoints (Host-to-Host).

The term "End-to-End" in networking *has* historically meant Host-to-Host (Transport Layer), whereas the modern messaging usage means User-to-User. That is why a lot of folks from that era (and the RFCs) called SSL "End-to-End encryption" because relative to the network, it is.

---

RFC 4949 from 2007 (Internet Security Glossary) is quite explicit on this: https://datatracker.ietf.org/doc/html/rfc4949

> $ end-to-end encryption

> (I) Continuous protection of data that flows between two points in

> a network, effected by encrypting data when it leaves its source,

> keeping it encrypted while it passes through any intermediate

> computers (such as routers), and decrypting it only when it

> arrives at the intended final destination. (See: wiretapping. Compare: link encryption.)

>

> Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS, SSH, *SSL, TLS*.

>

> Tutorial: When two points are separated by multiple communication

> links that are connected by one or more intermediate relays, end-

> to-end encryption enables the source and destination systems to

> protect their communications without depending on the intermediate

> systems to provide the protection.

---

RFC 1455 from 1993 (32 years ago) also uses the term in the IP/Host context: https://pike.lysator.liu.se/docs/ietf/rfc/14/rfc1455.xml

> At this time all Internet Protocol (IP) packets must have most of their header information, including the "from" and "to" addresses, in the clear. This is required for routers to properly handle the traffic even if a higher level protocol fully encrypts all bytes in the packet after the IP header. This renders even *end-to-end encrypted* IP packets subject to traffic analysis if the data stream can be observed.

---

Regarding your claim that "no one really used the E2EE term before it got the current meaning," the IETF standards for the internet (albeit an informational RFC and not a standards RFC) explicitly list SSL and TLS as examples of End-to-End encryption. The definition of "End" has simply shifted from the Machine to the User.

> no one really used the E2EE term before it got the current meaning

It most certainly was a term and no it wasn't simply limited to "some obscure radio protocol".

1994: https://ieeexplore.ieee.org/abstract/document/363791

1984: https://dl.acm.org/doi/pdf/10.1145/357401.357402

1978: https://apps.dtic.mil/sti/tr/pdf/ADA059221.pdf

> Some homemade encryption added on top of TLS is very unlikely to increase the security of the system

"Some homemade encryption" is not what I was suggesting at all. E.g. encrypted-at-the-source (client side) AWS files are still sent over TLS as an encrypted blob within an encrypted blob but remain encrypted past the TLS boundary.

You can easily find these references in the literature, often comparing link encryption with end-to-end encryption. Some of the earliest papers outlining the plans for SSL in the 90s (Analysis of the SSL 3.0 Protocol) are based on this exact foundation from the 80s (End-To-End Arguments in System Design).

Hell, you can even go back to 1978 and see MITRE discussing this exact thing in "Limitations of end-to-end encryption in secure computer networks".

While you are technically correct in a network topology sense (where the "ends" are the TCP connection points), that definition has been obsolete in consumer privacy contexts for a decade now due to "true" E2EE encryption.

If we use your definition, then Gmail, Facebook, and Amazon are all "End-to-End Encrypted" because the traffic is encrypted between my client and their server. But we don't call them E2EE because the service provider holds the keys and can see the data.

In 2025, when a company claims a camera product is "E2EE", a consumer interprets that to mean "Zero Knowledge". I.e. the provider cannot see the video feeds. If Kohler holds the keys to analyze the data, that is Encryption in Transit, not E2EE. Even though in an older sense (which is what my original comment was saying), it was "End to End Encrypted" because the two ends were defined as Client and Server and not Client to Client (e.g. FB Messenger User1 and FB Messenger User2).

Papers in academia and the greater industry[2] also referred to it in this way at the time.

Stack Overflow has plenty of examples of folks calling it "end to end encryption" and you can start to see the time period after the Signal protocol and WhatsApp implemented it that the term started to take on a much wider meaning[4]

This also came up a lot in the context of games that rolled out client side encryption for packets on the way to the server. Folks would run MITM applications on their computer to intercept game packets coming out of the client and back from the server. Clever mechanisms were setup for key management and key exchange[3].

[0] as SSL became more common lots of tooling broke at the network level around packet inspection, routing, caching, etc. As well as engineers "having fun" on Friday nights looking at what folks were looking at.

[1] Stack Overflow's security section has references from that era

[2] "Encrypting the internet" (2010) - https://dl.acm.org/doi/10.1145/1851275.1851200

[3] Habbo Hotel's prime and generator being hidden in one of the dynamic images fetched from the server as well as their DH mechanism comes to mind.

[4] Jabber/XMPP however used E2EE in the more modern sense around that time as they were exploring going beyond TLS and having true E2EE.

I can't blame most people for calling TLS "E2EE", even some folks in industry, but it's not great for a company to advertise that you offer X if the meaning of X has shifted so drastically in the last decade.

E2EE now means something wildly different in the context of messaging applications and the like (since like 2014) so this is more of an outdated way of saying "no one is getting your poop pictures between your toilet and us".

It also feels like it would never make sense for this to be "E2EE encrypted" in the modern sense of the term as the "end user recipient" of the message is the service provider (Kohler) itself. "Encrypted in Transit" and "Encrypted at Rest" is about as good as you're going to get here IMO as the service provider is going to have to have access to the keys, so E2EE in a product like this is kind of impossible if you're not doing the processing on the device.

I wonder if they encrypt it and then send it over TLS or if they're just relying on TLS as the client->server encryption. Restated, I wonder how deep in their stack the encrypted blob goes before it's decrypted.

The intention and cost of something like that is not at all comparable to what is being offered here.

Can you elaborate what you mean by the "Great Flood"? There's certainly evidence for regional megafloods, but I'm not aware of any professional geologic body that recognizes what most people mean when they say "Great Flood", i.e. a single planet-wide flood around that time period.

I've found this a lot in data systems where folks glue stuff together as fast as possible to "ship", while missing the huge glaring issues with the foundation that they've built on top of wet, sliding mud.

In my head, I'm imagining someone early in the morning posting a flyer up on a bulletin board downtown.

Throughout the day many folks walked by and took photos of the flyer with their cell phone.

At the end of the day, the original person came back and removed the flyer.

IMO, at the time that the folks took the photo of the flyer, that flyer was public information. It remains public information even after the flyer is removed[0].

This isn't a great analogy of mine, and has plenty of holes, but was interesting to me after I read your comment. I know it was in the context of doxxing, but I think it's pretty interesting philosophically.

I think something similar applies to photos taken of other people in public spaces. Both the person who took the photo and the subject of the photo are no longer in that physical public space, but the actions took place within that space.

I think something similar applies to digital "public spaces". But what does a public space even mean in the context of walled gardens[1], etc.

[0] you then run into the question of what happens if someone posts non-public information, publicly? [1] are digital walled garden communities that different from physical communities that gate access, whether free or paid. Whether information shared within those contexts are public or private is an interesting thread as well.