I can't find a link, but this problem was foreseen and solved by Robert Morris Jr. He wrote a paper on how users could register their location with a 3rd party using a hash of their IP address. When someone wanted to call them, they would contact that 3rd party for the location then route to the cell. The cell knew someone was there, it just didn't know who. And each 3rd party only had info on a few users, and no choice over which ones it had, if I recall correctly.

Looks like there is info here:

https://en.wikipedia.org/wiki/Robert_Tappan_Morris#Later_lif...

This is the way we should have designed these networks from the beginning. It was inevitable that the stuff in TFA would happen, given the interests of the companies involved and no regulation to prevent it. Same with FaceBook and Cambridge Analytica.

Couldn't you build a lookup table that reverses hashes back into their IP addresses? It might not be worth it for IPv6, but it would probably work for IPv4.

Calls could be done over IP, and as long as you could anonymously authenticate to the tower then you could be granted a new IP address at each tower via something like DHCP. I imagine roaming and handovers would have to be done on the end-device though; the end-device would need to proactively associate to new towers and both ends of the voice call would need to agree to switch to the new IP address.

But if the tower operators collude then they can still track you across towers by localizing the physical source of the end-device's signal.

If you really wanted to do this, a more secure approach is onion routing. It's essentially the same problem -- attempting to preserve anonymity in the face of adversarial network hardware, while being limited by a requirement to enter / exit through certain nodes.

So you'd want a mesh network, formed adhoc out of currently in range cellular device neighbors, with packets re-encapsulated and encrypted at each hop, eventually hitting the tower from a random device.

Authorization would be impossible (the intent of the scheme) without a side channel (as you can't simultaneously have individual authorization and individual anonymization). Which makes it a non-starter for commercial use.

Oh yeah, that's an interesting solution.

I'm not sure simultaneous authorization and anonymization is impossible. Couldn't you use something like Chaum's e-cash to obtain tokens that guarantee the holder the right to use the network for some amount of data, but these tokens are tradeable and therefore the spender doesn't have to be the same as the buyer. Then you could spend this token in the network to get access and the network could authenticate the token without identifying the spender. I'm guessing something like zcash could be used as well...

That's what I meant by side channel. So yes, you can split authorization responsibilities into a different entity, but then that entity is going to be able to deanonymize you.

And it wouldn't play well with billing accounts being deactivated / reactivated.

And... now that I think about it, given the tower:location mapping, you'd also have to include bouncing traffic back out to a non-tower-sharing peer and then back into their tower w/ randomized timing, else outer layers of encapsulation would still identify tower association.

Which means latency would be utter crap.

Anonymous attestation protocols is a thing

"without a side channel"

Do you have any links where this is done without a third party?

Blockchain? No, seriously, just a block-oriented write-ahead-log replicated to the towers, allowing them to cheaply-ish verify a proof-of-traffic quota.

Proving to the tower that you are a paying user should be easy, but routing the data securely will not be as easy. You'd probably need some kind of onion routing or similar on the back haul, unless you want to forego incoming calls. I would not like to have to forego those. Also, why even bother with DHCP, just say that the tower assigns you an IP, without knowing your MAC, right after you were able to prove that you are a paying customer. Handling data quota is going to be non-trivial there, as you'd either need to route everything to the provider anyway, or have a DoS-proof way of decreasing your remaining quota, e.g. by signing a new value with some key of yours, ensuring that the tower can't use that as your ID (maybe don't tell him or so), and then have to prove to the tower that your quota really got diminished, preferably without revealing how much is remaining, and just telling the tower that you still got something to spare. The main issue seems to be that you'd have to hold a session with each tower where you got quote allocated, as you can't re-run that quote proof for each packet. The finest granularity that seems remotely reasonable would be like 16kiB of traffic, which you would deduct form your account, let it get claimed by the tower, and then be required to repeat for each successive block (obviously you could assign larger blocks, but a block, once assigned, can't be put back without serious unnecessary cryptographic hurdles.

I am not well-versed enough in these cryptographic details to tell you how one could do this exactly, but I doubt it's impossible/infeasible to create a cellular protocol technically as powerful as LTE, but without tracking ability by the tower or the provider (byzantine fault tolerance, stochastic).

Off the top of my head, you could have this system: you use a new id that authenticates you with the carrier every n packets, and you do the routing from the source to your id on a server that you control yourself.

Spoiler. The utility of the live call is overstated. Most of the people I interact via a phone vastly prefer async SMS over sync voice calls. We can do SMS via polling, the network doesn't need to push anything to us.

People text so much because there is an expectation the other person is going to respond pretty quickly. There is definitely value derived from having people accessible all the time, and I doubt a service would sell if people weren't.

Poll every X seconds if the last message was is no older than Y minutes. Poll every Z minutes otherwise.