back
103 comments
I do not see a rational reason why a mobile carrier should have any say in which connectivity technology is enabled for use with its mobile network on a particular phone model.

It should work based on standards, mobile carrier's capabilities and phone's capabilities. If a phone supports capability X, such as VoLTE, then it should just work with all mobile carriers that support that capability. No conditions.

As an imperfect analogy, consider a road, representing a mobile network. This road has some capabilities, such as speed limit. There are cars driving on this road, representing mobile phones. And then consider that a road management company, representing the carrier, would impose different speed limits on different cars, depending on whether they are affiliated with the road management company or not.

Would that be acceptable in a physical world?

If not, we should not accept anything similar in a digital world either.

The official reasoning is that the spec documents and certification testing aren't good enough, and each cellular cores has each its own quirks, interpretations, parameters, and they don't know if the phone is compatible with each networks unless Carrier Acceptance/Inter-Operability Test is done at carrier certified tests.

So why not actually perfect the spec and cut those uncertainties and costs...? idk.

It's not even the mobile carrier that has a say, it's just Google. If Google doesn't sell the phone in a country, they just disallow the feature for everyone, instead of just allowing it as long as the carrier supports it. The carrier doesn't mind (if they did, they'd block by IMEI and the workaround wouldn't have worked)
It had been a thing since mobile phones existed.

Pre-paid cards that required paying for unlocking the phone firmware, eventually forbidden on EU countries.

Vodafone famously had their own firmware on Nokia N95 in Germany that disabled tethering,....

It starts by regular people being trained to accept that lack of quality and restrictions are normal in digital world.

I think it depends; speculating but probably volte is a very complicated spec with many optional enhancements ( think ssl with cipher types )

So carrier can choose to whitelist/blacklist phones depending on extensions available

> As an imperfect analogy, consider a road, representing a mobile network. This road has some capabilities, such as speed limit. There are cars driving on this road, representing mobile phones. And then consider that a road management company, representing the carrier, would impose different speed limits on different cars, depending on whether they are affiliated with the road management company or not. > Would that be acceptable in a physical world?

A number of cars on the road today can be remotely disabled by a device built-in to the car.

While personally I think this is risky, in the U.S., we also have police, sheriffs, highway patrol, M.P.s and others that have authority to tell other cars to stop or to physically stop them, which is just another way of doing the same thing. They also enforce speed limits.

So, no I don’t think that the ability to drive a vehicle as fast as one would like is a global right, per current laws.

> would impose different speed limits on different cars, depending on whether they are affiliated with the road management company or not.

With the state as road management company and public transit as state affiliated then the answer is this exists already.

Your core premise is that if someone can do something for you then they should, but you get to capture all the value from that.

It should work based on standards, mobile carrier's capabilities and phone's capabilities.

That's how it was with GSM.

> that let Pixel users enable VoLTE anywhere

It did a great deal more than that. It also allowed the toggling of VoNR, which apparently affected the fallback behavior of some people's services. (Ie. It would fall back to LTE and not roam back to 5G data unless nudged manually)

However for me, it would enable backup calls over a secondary sim card's data, which would allow text and calls overseas without the usual extortionate charges. Oddly enough, I believe that toggle is enabled for my carrier... but only on iOS.

> that toggle is enabled for my carrier... but only on iOS

WiFi calling with SIM1 number via SIM2 data has always worked on iOS, so I was surprised when it didn't work on Pixel.

> VoNR

off topic but who the hell names these, a pre-schooler?

"New radio", from the makers of "New folder (1)"

I'm sure they had to do this based on carrier pressure, but it would be great if Google would just put more resources into getting carrier support/certification so their flagship devices will work more places.
And... Sell in more countries as well.
How on earth is this a "vulnerability"? It needed adb shell access.
The same way being allowed to install programs on your own computer is called "jailbreaking".
It allowed anyone with knowledge to use the cell network in ways the operator of the cell network didn't like. This is generally considered a major issue and can attract serious legal repercussions for a radio device maker that doesn't take care to enforce only the allowed uses.
People were exploiting the poor mobile carriers.
An interesting note from the Github conversation on it:

"Google's implementation of the security patch is strange, clearly targeting the Pixel IMS rather than fixing the shell's ability to modify carrier configurations. I'm actually worried that the ongoing backlash will ultimately lead Google to remove the MODIFY_PHONE_STATE permission from the shell to properly fix this issue"

https://github.com/kyujin-cho/pixel-volte-patch/issues/384

From the article:

>To gain these elevated privileges, Pixel IMS uses Shizuku, an open source Android app that lets other apps run processes as the shell user.

It's possible for an app to use wireless debugging to debug the phone it's running on to get shell permissions.

> While not documented in the official changelog, Google appears to have quietly patched this particular exploit.

So Google and phone carriers conspired to secretly sabotage user devices. Isn't that patch the actual "hack", given that it is undisclosed and against the device owner's wishes? Why are we going along with this deranged pretense that even if you buy something, it still belongs to the manufacturer?

Phones, just like cars, are only allowed to be manufactured and sold to the extent that the manufacturer takes reasonable efforts to prevent end-user misuse of the devices they are selling. This is because phones, just like cars, use and can greatly affect shared public infrastructure - the radio spectrum for phones, public roads for cars. As such, it is natural that there are manufacturer enforced restrictions on end user's use of these devices. Whether this particular case is an overreach of this, or whether there is a real risk to the network from allowing this, I'm not sure.
In Australia, tons of phones were rendered useless during the "3G switchoff". What was not mentioned about this switchoff is that lots of 4G devices were affected - specifically those that supported VoLTE but were not endorsed by the carriers.

I got one of my old phones IMEI's blacklisted just by using the Pixel IMS app. It worked for about 24 hours before the phone got blocked.

From what I remember the issue was that many models of phone would use 4g/5g for everything but emergency calls, which was done over 3G. So the government made the choice to block those phones from the network entirely rather than leave them seemingly working but unable to make emergency calls.
The days of GSM/3G were great. All you needed was a quad-band phone, of which plenty were available from numerous far-East companies but many based on the same or similar chipsets, and you'd have connectivity in the whole world.

The situation with LTE is far worse, with several dozen different bands and many opportunities to whitelist and effectively do user-agent discrimination. Even if you bought an unlocked device, if it doesn't have the bands in the area you want to use it and those your provider has cells for, you won't get any service.

a high-severity privilege escalation vulnerability

This is an extremely clear signal of how they think of the user --- as sheep to be corralled and controlled, not as individuals who have control over the devices they bought. The "security" propaganda they continue to spew has been going on for a while, long enough that increasingly more users are now aware of the truth.

To paraphrase the famous words of Linus: Google, fuck you!

Why is having so many bands a bad thing? Demand for data is so much higher now you need (ideally) hundreds of MHz of spectrum in dense areas. You need some way to partition that up as you can't just have one huge static block of spectrum per auction.

The issue with LTE isn't bands, it's the crappy way they have done VoLTE and also seemingly learnt nothing for VoNR.

They should have done something like GET volte.reserved/.well-known/volte-config (each carrier sets up their DNS to resolve volte.reserved to their ims server which provides config data to the phone). It would have given pretty much plug and play compatibility for all devices.

Instead the way it works is every phone has a (usually) hopelessly outdated lookup table of carriers and config files. Sort of works for Apple because they can push updates from one central place, but for Android it's a total mess.

> LTE is far worse, with several dozen different bands

The national radio regulators are mostly to blame for that part, as far as I understand. So ultimately the national militaries, who hogged most of the relevant spectrum for radar(?) at a time when you couldn’t viably communicate over it, and will now never let go of it, at least not in a coordinated fashion (see: 5G rollout).

E.g. 2.4 GHz WiFi avoided the same problem by using a mostly-unregulated band, which as far as I can tell (but can’t reliably confirm) seems to have been essentially allocated for microwave ovens (a rotational absorption band of water molecules, which is why it’s difficult to heat up frozen things in a microwave).

> This is an extremely clear signal of how they think of the user --- as sheep to be corralled and controlled, not as individuals who have control over the devices they bought. The "security" propaganda they continue to spew has been going on for a while, long enough that increasingly more users are now aware of the truth.

While labeling this a security vulnerability is a little weird, it is nevertheless a serious problem for Google, and potentially for the carriers which would allow Google phones. In general, carrier settings have to be enforced by phone manufacturers without relying on the good behavior of phone users, as otherwise the whole cell network can be affected. Now, in this particular case, the impact seems pretty small - though even here this is not 100% clear. For example, if enabling these settings could allow a phone to appear to work for normal use, while actually having major missing functionality such as not being able to receive national alerts or not being able to issue emergency calls, then this is a real risk to the consumer, and shouldn't be allowed.

And this is why I'm mistrustful of Google's "open source" ventures. It's all very OSS until shit gets real and there is pressure from the supposed sponsor

See also chromium and MV3

This phone/carrier nonsense is just stupid. I had lots of trouble with Wi-Fi calling on Android phones:

* A phone purchased outside US/unlocked but non mainstream (aka not Samsung/Pixel) phone purchased in the US cannot enable Wi-Fi calling despite having hardware & software support for it, as it's not a supported model

* An at&t Samsung phone that is later unlocked cannot enable Wi-Fi calling when using a Visible SIM card. But guess what works? But a Verizon SIM card, insert it without buying/activating a plan, and the phone will ask you whether you want to "switch to" Verizon. After restarting the phone, bloatware from Verizon appears on your phone and suddenly your phone is capable of WiFi calling. (Alternatively, you may be able to connect your phone to a PC and use a tool to fix this.)

Not to mention the voicemail mess. On Android, each carrier provides their own voicemail app that is not integrated with the phone app.

I don't know who to blame, but all of the nonsense makes me question the decision to use an Android phone.

> Not to mention the voicemail mess. On Android, each carrier provides their own voicemail app that is not integrated with the phone app.

This doesn't seem to be the case for T-Mobile US prepaid?

Android is the Windows of the phone world. The whole ecosystem is built around selling hardware at margin and making profits with forced installation of McAfee, Candy Crush etc
> Many carriers only permit VoLTE and VoWiFi on devices they sell or have officially tested.

Does this happen even if you are using a carrier's SIM card; it's just because you didn't buy the hardware from them?

It's not just an IMEI-level block so data still works?

No, this is not really tied to whom you purchased the Pixel from. But it is tied to which carriers would sell you a Pixel at all. Meaning they have some sort of an agreement with Google and Google added configuration files whitelisting these features for the carrier in question.

(At least for many EU based carriers.)

VoLTE was an afterthought and carriers don't trust untested vanilla implementations. So they only allow known-good phones.
This, along with the upcoming requirement for android dev registration, are indicators that the time has never been more ripe for migration to a linux phone.

My current favorite: https://furilabs.com/

Yes, it runs a SoC vendor kernel, but please, don't let the perfect be the enemy of the good.

It also runs android in a container, allowing execution of apps that are only available in android, and the ability to shut down the android VM otherwise.

The HN community is probably one of the most equipped to make this transition, so please seriously consider letting go of goggle...

One workaround is to just do pure VOIP. Then you can get a data only plan. Gotta watch out for 911 access though.

Yeah, what happens when you call 911 in an environment with no 3G/2G and your carrier doesn't like your VoLTE? Is there a public safety issue embedded in all this?

Australia bans phones not capable of 4G 000, except for roaming. Tons of phones support VoLTE, but not emergency VoLTE for some reason.
Not entirely sure, but I heard that the "Pixel 911 bug" (e.g. https://news.ycombinator.com/item?id=37714579) could be related to an IMS bug. Since operators are liable with regards to safety calls, maybe it explains why they would only allow tested devices to use IMS...
I trust this "patch" can be easily reversed in open source versions of Android like Graphene. Just another example of why we need open software on our phones.
Graphene just made VoLTE / NR / VoNR toggle feature built-in to their OS.
Works great on GrapheneOS as of about a week ago.

https://grapheneos.org/releases#2025100300

Another article that also includes an explanation of the current state of the hack (workaround known, patch[1] in development); of GrapheneOS (“security patch” pulled in, but official VoLTE/VoNR/VoWiFi override toggles introduced[2] in device settings as a replacement); and of other phones (coming to all in-support Android phones near you, sometime before December depending on the quality of said support):

https://piunikaweb.com/2025/10/10/october-2025-pixel-update-...

[1]: https://github.com/kyujin-cho/pixel-volte-patch/pull/387

[2] https://github.com/GrapheneOS/os-issue-tracker/issues/956

Does that work for inbound calls, or just for outbound? How does the voice network find you?
Oh what a terrible vulnerability.. good to know it's patched, I feel much more secure now, thanks Google!
Well, I used this so - fuck Google. Android will soon be more locked down than iOS.
weird amount of cope in here
If Google had not patched this, it would have violated local regulations right? In other words, they are trying to be compliant right?

What do people want - a company to openly violate known local laws?