SMS specifications include "Type 0" messages, also known as Silent SMS. These messages don't trigger any even on the phone when received, but they do send back an ACK that includes IMSI metadata. Silent SM, are literally defined in the RFC and primarily used to covertly track user locations without judicial oversight.
GSM, SS7, etc. are massive privacy holes _by design_.
Silent SMS is an incredibly convoluted and impractical way of trying to figure out someones location.
The whole purpose of mobile networks is to track a devices location (so you can route data to/from it!). Of course its easy to do it if your the operator or someone who has compromised it.
I remember using one of those dongles with a SIM card that you could talk to with an API and use that to send flash SMS. Full screen warnings to friends. Only option was 'OK' and the text was gone afterwards.
when we know that govts want this capability, when we know that govt regulators are in the same room with telcos when plans are being drawn up, when we know govt uses these capabilities routinely, why would you doubt it was there for that purpose? isn't this a good time to round up the usual suspects? If the govt intervenes to get this capability and also declares that this should not be the primary purpose, I guess that would make it a secondary purpose? OK, I feel better now, phew!
Visual voicemail is when the dialer app on your phone can show the list of voicemails similar to how you would see your email inbox. You can directly play the voicemail messages and depending on the device/carrier, there might also be a text transcription of the audio.
Many carriers implement this via "silent SMS" + IMAP (the same IMAP as for emails). The device will send an activation or status message to the carrier's visual voicemail number and the carrier will respond with an SMS containing the IMAP credentials.
The version of this I'm familiar with is T-Mobile's old CVVM protocol. During initial setup, the device will send a text message containing "Activate:dt=6" to the number 122 and T-Mobile will reply with (in decoded form):
If visual voicemail is already enabled, then sending the "Status:dt=6" SMS to 122 will also result in the same reply. Putting the credentials in an IMAP client will work and it doesn't have to go over the phone's cellular connection. You can even use curl:
T-Mobile has deprecated this protocol though. New activation messages will fail with a blocked status:
rc=0
st=B
srv=vvm.mstore.msg.t-mobile.com
T-Mobile replaced this CVVM protocol with two HTTP based protocols: "mstore" (used by OEMs like in the dialer app on Google Pixels and OnePlus devices) and "cpaas" (used by T-Mobile's first party visual voicemail app). I've been working on an open source client for mstore for use with open source Android OS's, like GrapheneOS.
I'm not sure if Visual Voicemail really uses silent SMS, but even older phones had a series of indicators such as "voicemail waiting", "message waiting" etc. which the network could control via binary SMS payloads.
By sending one that clears all of them in a network that doesn't use them (or sending one equivalent to the current state for one that does), you can achieve the outcome of initiating SMS-MT (mobile-terminated) delivery to a given ME (phone) without any user notification.
SMS delivery by necessity involves paging the device, revealing its location at a finer level (base station instead of paging area).
So I wouldn't say silent SMS were designed as a spying tool, but they're one out of several ways to silently "ping" a phone and force it to communicate with the network without having to wait for it to cross location area boundaries, get or make a call etc.
Visual voicemail is where an app on your phone can show you a list of voicemails and you can click a button to play them, as opposed to you having to dial a number to access voicemail (the old "press 2 to hear the next message" stuff).
They're not privacy holes by design, but they're not privacy friendly by design either.
When these things were designed, privacy wasn't really a concern and wasn't really thought about in the way it is now. The assumptions were very different, it was assumed that only large and trusted companies could get on SS7 and those would play by the rules, or else face the wrath of the government. Now, a small carrier in a third-world country that routinely violates human rights can get that access.
I think I’m more concerned with the fact that the carriers know the IMEI of phones and claim that they can do nothing about stolen phones. That was the beginning of the end of my infatuation with the mobile space.
I should have been well positioned for early retirement during the early smart phone gold rush but was just so put off by the Ma Bell feeling of the mobile industry that I had exited before most people had even entered.
In Kazakhstan, when a phone is used on a mobile network for the first time, the IMEI of the phone gets locked to that mobile network and that sim card. When you buy the sim card, they photocopy your passport/ID card.
No other sim will work in it until you take that photo ID/passport to the mobile companies office to have it unlocked. The photo id (even if expired) becomes the unlock code for the phone.
Stupid assumption. Phone theft including being robbed for your phone, was more common in London, Sydney, Melbourne than in any place in Eastern Europe I lived in.
Carriers have been blacklisting IMEIs for at least 10+ years. Since phones tended to be carrier-locked back then you couldn't go to a new carrier without being in good standing to get your device's unlock code from the old carrier. Now that devices are available unlocked by default, it is probably harder since it would require carriers to communicate IMEIs?
I looked it up. US Carriers were forced by the US government to start blacklisting them in the final months of 2012. They didn't do it voluntarily.
Australia had been doing it since 2003. IMEIs have been around for 30 years? Everyone having a cellphone is still a relatively recent phenomenon, but according to Pew 80% of American adults had cellphones for several years already before carriers were forced to deal with stolen ones.
~15 years ago the blacklists were certainly shared within Europe, but there was an intercontinental trade of blacklisted phones from Europe to Africa (and, if memory serves, Asia).
I believe the point is that they could've been blacklisted from the start and instead carriers would just put up their hands say "there's nothing we can do" despite there being something they can do.
It's like when your apple laptop gets stolen and then starts using your applecare support and apple won't help you get it back.
Of course, if you decided not to pay your phone bill I'm sure that device would get blackslisted real fast.
Your entire comment makes it sound like your gripes are current issues, not those that you experienced decades ago in a completely different mobile landscape.
You continually use the present tense when the argument... just doesn't apply anymore.
> I think I’m more concerned with the fact that the carriers know the IMEI of phones and claim that they can do nothing about stolen phones.
I really want mobile networks to accept their role as dumb data pipes. I should be able to just provide a password or certificate and connect. No IEMI, no SIM.
And while we are at it stop tunneling my data back "home" when I travel. I don't want increased latency.
> And while we are at it stop tunneling my data back "home" when I travel. I don't want increased latency.
You might not, but a whole lot of customers who aren't as technically sophisticated did. When T-Mobile first started doing included international data roaming, they didn't tunnel back. That caused a lot of confusion from customers who didn't realize why stuff they expected to work, like checking their bank balance, didn't. (It also made throttling speeds a lot more difficult.)
So to fix that, T-Mobile tunnels you back to a few endpoints in the States. Banking apps are generally happy, as are Netflix and Spotify. Most customers are happy because their phone "just works" the same as it "always has".
For those of us who want to avoid the latency, we get a local SIM for data (if possible).
This is interesting. I use Verizon Wireless from the US, and when traveling abroad on their travel pass (roaming), some large multilingual websites serve me the local language instead of English, on sites that serve me English when I'm at home. My browser (Accept-Language header) is configured for only English. I always decline location API browser popups.
The only thing I can think of, assuming they tunnel as you describe, is maybe I first loaded the site from local WiFi instead of mobile data, at which point I was redirected (to a localized subdomain that doesn't redirect back) or got a cookie or something, which lingered as I continued without WiFi.
> And while we are at it stop tunneling my data back "home" when I travel.
Oddly enough, I found this to be a plus when I traveled to China for work. My data was unmolested by the Great Firewall of China. I was able to get on websites with my mobile data that I couldn't when using wifi in the hotels.
How would a networking stack with no hardware addresses even work? The next hop needs a way to reach back to you, before you can negotiate anything fancy like passwords or certificates. Even IPv6 SLAAC starts with a hardware address.
The use of IPv6 in cellular devices is specified by RFC 7066. When a device first registers for a data connection, the network provides an interface identifier to use for the lifetime of the registration, which is guaranteed not to conflict with the one used by the router. The network also allocates a /64 prefix exclusively for use by the device. These two things allows the device to perform SLAAC for link-local and routable addresses without needing to do duplicate address detection.
It’s also worth mentioning SLAAC does not strictly require a hardware address to function. For example, Apple devices implement newer standards from IETF to generate random but stable addresses that don’t reveal information about the hardware addresses (https://support.apple.com/guide/security/ipv6-security-seccb...)
A MAC address is 48 bits and an IMEI is about the same entropy-wise. That's not nearly enough room to avoid duplicates (even SLAAC requires duplicate address detection, and IPv6 has a lot more bits to work with). You'd need a whole new layer 2 protocol, though to be fair you might be able to strip it down to just doing collision detection/avoidance and leave addressing up to layer 3 with IPv6, but that's not going to be any kind of backwards compatible or interoperable.
> Surely the uniqueness is only required at the bottom end of the stack before the first 'router' ie the cell tower
Not if you need to send a message to $thatUniquePhone.
Over simplifying considerably, but if a land line places a call to a mobile, the "220-1234 calling for 220-7890" message enters the network. The `220-7890` phone number needs to map to the unique modem address so you can look up which tower the call setup data should be sent to. If - by sheer coincidence - I also have your MAC address and am attached to a tower 3 states away... which tower(s) do you forward the call setup data to?!
As far as I know MAC addresses are never used to route a message to a particular recipient. They're used so that devices that overhear the message, but aren't the intended recipient, can ignore that message on the honor system.
If you have a wired connection, this makes the MAC completely superfluous. The concept is sort of still valid for wireless connections (or of course for "wired" connections where you have multiple devices physically connected by the same wire, a bus, where the concept originated). It should be rethought.
A typical Ethernet switch operates only at layer 2 and so does indeed route frames by MAC. You need a more expensive, typically managed, switch in order for it to use layer 3 addresses instead and, even then, the initial setup usually relies on layer 2 routing to get an IP address before layer 3 routing can take over. As a sibling comment points out, the whole stack would/does need a rethink to work differently than this. IPv6 SLAAC as mentioned before can potentially eliminate the need for layer 2 addresses but a lot of networks are still IPv4-only, dual-stack, or even layer 3-agnostic.
Note that this is only about last-mile/first-hop. Once you scale past a single LAN segment, routing is mostly layer 3 until you get to core Internet infrastructure which uses ASNs and BGP. At the very least, it is probably sufficient to say that routing across a WAN is all about IP, but if you zoom in on parts of that network of networks, the underlying technologies often use other routing mechanisms internally that don't get exposed to the other parts of the WAN.
Yes, but you could have hundreds of thousands of devices connected to that tower in a dense metro area. Even a single hardware address collision would result in both devices being unable to reliably reach emergency services.
It seems a number of devices are now randomizing their MACs when connected to wifi. I'm not sure how they handle address collisions, if they do at all. Most wifi APs serve a lot fewer devices than a cell tower, but it's possible that the issue isn't as significant as I thought.
And while we're at it, how come if I have a phone without a sim I can't at least navigate to a carrier webpage to buy an esim?
The phone could pop up a menu saying "Here are the available networks", and you pick one, connect and it says "Welcome to AT&T, enter credit card number here", and you type a number and hit OK and you're connected.
Oh wait - just like Wifi!! Why are mobile networks so far behind?
There is no privacy concern, really, as this is unique to the device, not subscriber, and only shared with the network operator, who obviously already "tracks" the subscriber through the SIM
, which contains the subscriber identifier (IMSI).
On the other hand, the IMEI in principle makes tracking and disabling of stolen devices easy.
By the way, in the UK it is actually an offence to change the IMEI [1]
The IMEI also allows a network operator to track a device across multiple sims. And I think it's also shared with roaming operators if roaming happens.
Disclaimer: used to work in SIGINT, so please treat anything I say about this with appropriate skepticism.
There are people that for various reasons do cycle out their SIM card frequently as a means to avoid tracking. This is ineffective. Changing the IMEI/discarding devices entirely is more effective.
But if you change IMEI and use the same SIM card, you're still trackable as if nothing changed, right? The IMSI would be the same. I guess you need to change both at the same time...
Dudes have been driving around with fake base stations, rare, but has happened. Only sent spam sms messages with links but could be expanded with buying data from data brokers. A really serious crime though
I would think state level actors have enough tools to deal with this issue. If nothing else they could go the old fashioned way and just, you know, follow you.
"There is no privacy concern, really..."
Except for the network operator, who needs to track a SIM card not a phone, but who can track you across networks and SIM cards if he has the IMEI. There is no reason the IMEI needs to be stable.
The network operator does NOT need to know who you are, even if you live in a repressive country that mandates tying ID to mobile phone lines. Get a SIM card in person and top up in cash, or use a virtual credit card, or pay in cryptocurrency for an eSIM, or get a subscription in a less oppressive country and roam.
Any immutable id is inherently a privacy concern. Network operators are ISP's, and ISP's have been known to do things like hijack unresolvable DNS entries to a search page with ads. The network operator knows who you are and what imei was associated with your account.
I wouldn't be surprised if there were some 'ghost'/virtual profiles associated to an imei similar to how Facebook would do with the like button
Well, there's your phone number. Networks and law enforcement only need that.
Existing privacy level is adequate for members of the public. Anyone who actually, really requires more either has state agencies resources available or is being wanted by state agencies...
Definitely don't let people edit it. iOS and Android don't allow picking your own MAC address for good reasons – people would inevitably pick 12:34:56, 00:00:00 etc. and cause problems for themselves and others.
To increase privacy, either randomize it (but make it much longer at the same time to avoid collisions) and/or remove it from as many signalling contexts as possible and keep it as a device-local identifier only (which then probably also doesn't have to be unique across manufacturers).
There were a lot of chinese made keiser phones that allows you to edit all the phone/sim related identifiers. Sadly they were discovered and rooted out of the amazon marketplace.
Just let people edit it. Then I can be someone new every day and nobody can track me.
Mac address randomization does that for wifi. Now do the same for mobile networks.