Hacker News Reader

Comment by londons_explore | Hacker News Reader

The fact the IMEI is generally not editable seems like a massive privacy hole.

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.

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_.

They are primarily used for configuring your visual voicemail lol. Stop the hyperbolic statements.

Can they be disabled/blocked on the device, when not needed because the user has disabled "visual voicemail" with their carrier?

https://www.heise.de/news/Zoll-BKA-und-Verfassungsschutz-ver...

Not sure where you get your information, but these are routinely used by police to covertly track targets.

Just because they are routinely used for such does not mean it is their primary purpose.

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!

You’re kind of splitting hairs there, aren’t ya?

No. The Internet is routinely used for porn but it is not its primary purpose.

There’s even a song about how the internet is for porn

Could you elaborate on this? What is a 'visual voicemail'? What would a 'silent SMS' have to do with that?

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).

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 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):

    pw_len=4-9
    vs_len=10
    u=<IMAP username>
    pw=IMAP password>
    rc=0
    st=R
    ipt=148
    srv=e7.vvm.mstore.msg.t-mobile.com
    lang=1|2|3|4
    g_len=180

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:

    curl -v imaps://<USERNAME>:<PASSWORD>@e7.vvm.mstore.msg.t-mobile.com/

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.

In case anyone is interested, the vvmd wiki (visual voicemail implementation for Linux phones) has information on how several carriers implement VVM: https://gitlab.com/kop316/vvmplayer/-/wikis/Visual-Voicemail.... AT&T's is especially nasty.

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.

My old Nokia C2-01 allows sending them from the menu ;-)

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.

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.

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.

Maybe once upon a time, but I'm pretty sure stolen devices can be blacklisted from networks these days.

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?

Not sure, I think that there are international lists of stolen IMEIs. Maybe it's just in Europe, though.

~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 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.

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.

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.

Made phone theft drop to pretty much zero.

> Made phone theft drop to pretty much zero

Use a nuke to kill a fly?

It was the only way to be certain.

The ends always justify the means.

i imagine that phone theft is more common in poorer regions

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.

i guess you haven't been living in a crowded place in eastern europe then

In Australia, you can report your phone as stolen and it becomes IMEI blocked, not able to be used on Australian phone networks.

https://amta.org.au/lost-and-stolen-mobiles/

https://amta.org.au/check-the-status-of-your-handset/

sounds like a dos vector. is there a lot of abuse of this?

sounds like considering linking to a social security number would be a good idea.. any reasons this ain't commonplace?

The article literally talks about blacklisting and has a photo of what a blacklisted phone shows when this happens.

And what time frame did I apply for when I exited mobile?

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.

This is not a fact anymore.

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'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?

Kinda like this? https://en.m.wikipedia.org/wiki/Apple_SIM

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.

rand()?

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

> 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?!

> which tower(s) do you forward the call setup data

Whichever one has most recently communicated with the user in question (based on the credentials or certificate provided, in the original example)

Assuming something like VoIP is in use, you reach other devices with their IP addresses, not MAC addresses.

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.

Yes - the whole MAC/ARP/IP parts of the typical IP stack are a legacy mess and should be sorted out.

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.

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...)

> 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.

> 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.

CB radio has you covered

You can, but it is not that easy and you also need to change your IMSI.

https://invisv.com/pgpp/ for IMSI (not available worldwide)

https://github.com/srlabs/blue-merle for IMEI, a nice guide written by them explaining how it works https://raw.githubusercontent.com/srlabs/blue-merle/main/Doc...

You can follow this thread for more info https://discuss.privacyguides.net/t/cell-towers-tracking-net...

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]

[1] https://www.legislation.gov.uk/ukpga/2002/31/section/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.

IIRC when you put a SIM into a new device for the first time, part of the tower auth includes the IMEI of the previous device you used it with also.

"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.

Invisv is a great suggestion.

This is 100% a privacy concern if you're dealing with state level actors.

They can track you with or without the IMEI. Next identifier is the IMSI read from your SIM card and I guess you're not replacing it every day...

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.

It isn't usually the goal of SIGINT to only collect data about a target's location nor are targets always that easy to follow.

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...

Mobile phones are a massive privacy hole. Almost by definition.

And smartphones 10 times more (or more, depends on how many apps you installed, almost all of them include some sort of trackers).

IMEI is (almost) the last of my privacy problems.

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).

Only if you also change your SIM every day.

As a man who currently has 13 esims in his phone...

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.

they WANT you to be stuck with it because then they can track you no matter what

Reply on news.ycombinator.com