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.
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.
> 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?
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!
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.
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.
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.
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.
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
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?
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):
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.
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...
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...
22 comments
[ 5.2 ms ] story [ 37.1 ms ] threadDoes 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?
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.
What do people want - a company to openly violate known local laws?
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?
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!
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.
* 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.
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.
See also chromium and MV3
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?
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
https://grapheneos.org/releases#2025100300
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...