Hacker News

Top stories

Live mirror
30 storiesupdated just nowView source snapshot
  1. Human brain is two separate organs, Stanford Medicine-led research finds(stanford.edu ↗)
    57comments
  2. If math is more than proof, we need to better celebrate the rest of it(terrytao.wordpress.com ↗)
    31comments
  3. GPT-6 Astra Solves a WWI German Radio Cipher(prinzai.com ↗)
    41comments
  4. San Francisco Onion Futures Company(onionfutures.com ↗)
    62comments
  5. Android 17 is the first since 3.x to add new APIs without releasing to the AOSP(grapheneos.social ↗)
    397comments
  6. Typesafe-computer-use drives a Mac toward a goal for 1/50th of a cent per step(github.com/awlevin ↗)
    39comments
  7. Science Is Open Software(jepedersen.dk ↗)
    34comments
  8. SDCC – Small Device C Compiler(sourceforge.net ↗)
    16comments
  9. Cloudflare Quick Tunnels(cloudflare.com ↗)
    277comments
  10. You can run Git on object storage if you re-make packfiles(tigrisdata.com ↗)
    10comments
  11. Apple M6 Pro Achieves the Highest Single-Core CPU Score in Geekbench 7(geekbench.com ↗)
    8comments
  12. Saving another 100TB of RAM(cloudflare.com ↗)
    69comments
  13. How to Write with an LLM(sockpuppet.org ↗)
    322comments
  14. Why building a Rust LSP is hard(rust-glancer.github.io ↗)
    30comments
  15. NASA-IBM Lunar Foundation open-Source Geospatial AI Model(usra.edu ↗)
    2comments
  16. How OpenAI Used Its Own LLMs to Design Its Jalapeño Chip(ieee.org ↗)
    83comments
  17. Ctenophores: Wonders of Biology(quantamagazine.org ↗)
    5comments
  18. The first new cat species discovered in 100 years(nationalgeographic.com ↗)
    103comments
  19. Goroutine Leak Profiles(go.dev ↗)
    2comments
  20. OpenJev(openjev.com ↗)
    260comments
  21. Show HN: Cactus Needle 3: 8-29MB automation models can match DeepSeek V4 Flash(cactuscompute.com ↗)
    88comments
  22. Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug(ledger.com ↗)
    67comments
  23. Veronese's Dogs(publicdomainreview.org ↗)
    discuss
  24. Suppress vulnerabilities applying Kubernetes context to scans(github.com/alegrey91 ↗)
    1comments
  25. Cache-to-Cache: Direct Semantic Communication Between LLMs (2025)(arxiv.org ↗)
    12comments
  26. Minimal Phone 2(minimalcompany.com ↗)
    220comments
  27. Warez: The Infrastructure and Aesthetics of Piracy (2021)(archive.org ↗)
    57comments
  28. Stepfun Step 5 Preview (LLM): On AA Pareto frontier(artificialanalysis.ai ↗)
    2comments
  29. Cyclomatic Complexity in C#(ndepend.com ↗)
    19comments
  30. Inside ZCode: Silently uploading your Git history to the cloud(ferstar.org ↗)
    97comments

Google blocks Android hack that let Pixel users enable VoLTE anywhere

215 pointsby 11mo agoandroidauthority.com
103 comments
11mo agoHN ↗

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.

11mo agoHN ↗

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?

11mo agoHN ↗

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

11mo agoHN ↗

VoLTE was an afterthought and carriers don't trust untested vanilla implementations. So they only allow known-good phones.

11mo agoHN ↗

That still uses their infrastructure at some point, as you are still using your carrier's phone number when you make a VoWiFi call.

11mo agoHN ↗

Yeah, but what’s the problem they’re trying to avoid? Bad SIP implementation not working with their servers?

Just text the user: “Hey, you’re using an unsupported VoWiFi stack, if it breaks – that’s on you.”

11mo agoHN ↗

"That's on you" is not something that works at cellular scale. You're going to end up fighting some mafia scheme microcosm forming around that little thing.

11mo agoHN ↗

I don't know, and I haven't seen any explanation either, malicious or otherwise.

11mo agoHN ↗

From what (little) I understand, VoLTE and VoWiFi are quite similar under the hood—VoLTE is more or less SIP, and VoWiFi is that same SIP over IPsec. You see how this would be an interoperability nightmare (not that I’m excusing the telecom people for getting us into this mess). Furthermore, some carriers get testy about you avoiding roaming charges by using VoWiFi (while others actually encourage it).

11mo agoHN ↗

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.

11mo agoHN ↗

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.

11mo agoHN ↗

This does work on Pixel's, but Google allowed carriers to block it, which at least one major US carrier does.

11mo agoHN ↗

It would be great if google could dick swing on carriers with the same might as Apple

11mo agoHN ↗

This is the “Backup calling” toggle in Pixel IMS, and carriers are fond of blocking that function.

(TIL: Vo“WiFi” over wired Ethernet over USB doesn’t work on AOSP or Pixel and never did, for no apparent reason except noöne caring to make it work.)

11mo agoHN ↗

The part that does not work on iOS is putting SIM2 into airplane mode so that it can do VoWiFi without connecting to the network. That would reduce power consumption and avoid utterly obnoxious behavior on the part of some carriers (cough, Visible).

11mo agoHN ↗

VoNR

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

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

11mo agoHN ↗

Oh what a terrible vulnerability.. good to know it's patched, I feel much more secure now, thanks Google!

11mo agoHN ↗

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?

11mo agoHN ↗

If you did this somewhere it was illegal, wouldn't that be you violating local laws, not Google violating local laws? If it's the former, then Google shouldn't have "fixed" this "vulnerability", because things you own shouldn't enforce laws against you.

11mo agoHN ↗

Yes. The argument will be that because it's expensive to police everyone, lawmakers will simply require anyone selling massmarket goods to do the policing instead.

If you're making a non-compliant device in your garage for you and your friends, the police might come. If you're trying to sell it broadly, the police will come, regardless of the user.

I'm for freedom of choice, but pushing regulations up the manufacturing stack is definitiely more efficient use of my tax money.

11mo agoHN ↗

it would have violated local regulations right?

First, "local" where? I don't know of any laws making VoLTE devices illegal (..unless blessed by a phone carrier?). If you know of any, feel free to list them, but know that Google has blocked it for all users, globally, not just in the localities where VoLTE is somehow illegal.

Second, I don't want Google enforcing the law - contrary to your framing, it would not be Google violating known local laws, but users that illegally (assuming it is illegal anywhere) enabled VoLTE.

Third, it sounds like they're not enforcing the law, but phone carrier bidding. Having private companies backdoor our devices to force the will of other companies on us is way more corporate dystopia than I am comfortable with. If someone steals my bike, I'm not allowed to break into their house to retrieve it. Yet Google can just abuse their backdoor access to my phone and hack me to make some 3rd party corporation happy?

Well, supposing VoLTE is legal in my local area, and my phone carrier allows it on my device, so there is neither legal nor contractual problems, and Google has just sabotaged my phone. Am I allowed to then hack into Google, take their root Android signing key or whatever it is they have to subvert ownership rights, and use it to patch my phone and restore the functionality they broke and that I paid for? No? Well, what if I had sold them the SSD on which those signing keys are stored? Then it's okay, right, that's how it works? If I sell you something it's not actually yours if I had the foresight to include a backdoor in it, and as long as I have the thinnest of pretenses, I can abuse that access against your wishes? Because consumer rights and property rights and personal sovereignty all go up in smoke as soon as something contains a CPU.

11mo agoHN ↗

Your phone has access to the radio spectrum under certain limited conditions, everywhere in the world. People who want to sell devices that can emit in the radio spectrum must make every reasonable effort to not allow the devices they sell to operate outside the conditions. I would bet that carrier contracts and rules around requirements for VoLTE and VoNR are codified in the exact same way. There is no legal right to use any device you like on your carrier's network - most likely, your contract with your carrier instead has an explicit series of devices that you are allowed to use, and this is also backed up by your country's laws by not being allowed to emit in the radio spectrum unless you do it through one of the certified carriers and under their conditions.

So, if Google were aware of a hack that allows users of their devices to circumvent conditions put in place by carriers against misuse of their network, and Google did nothing to patch this, Google could lose their license to produce devices which can access the radio spectrum. You personally could also be hel liable for using these hacks, but Google would definitely be on the hook, and could, in principle, be entirely prevented from manufacturing and selling phones, if this ever escalated enough.

11mo agoHN ↗

VoLTE is on another layer than the one radio spectrum laws apply to. VoLTE is basically SIP with a special handshake that uses the SIM card instead of the usual username/password. It does not affect radio in any way.

11mo agoHN ↗

I am aware, but the cell network itself is considered critical infrastructure as well, and operators are custodians of the radio spectrum. So devices that don't respect operator settings are considered problematic.

Now, do operators abuse this power to enforce commercial interests? Absolutely. This may well be a case of that. But the general principle that devices that operate on the radio spectrum and in cell networks are bound by laws that constrain user's rights, and that manufacturers are responsible for enforcing said constraints in their devices for the good of everyone, is not invalidated by a few greedy policies. Just legislate against the abuses, as the EU for example has often done in this area (leading to free roaming within the EU, legally mandated ability to move to a new network keeping your old number, etc).

11mo agoHN ↗

Just legislate against the abuses

which is never going to happen, because lobbying has overtaken the democratic process, and legislations no longer seem to be about protecting the consumer.

11mo agoHN ↗

Then there's nothing more to discuss and everyone is doomed to obey the robber barons. A country that can't create laws doesn't care about the will of the majority.

There are many countries that can still legislate, and in fact have created many consumer protection laws like the ones I mentioned.

11mo agoHN ↗

How on earth is this a "vulnerability"? It needed adb shell access.

11mo agoHN ↗

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.

11mo agoHN ↗

And it still is, for anything except those carrier overrides.

11mo agoHN ↗

Only if you allow it. This security patch doesn't affect that at all, so why is that relevant?

11mo agoHN ↗

The same way being allowed to install programs on your own computer is called "jailbreaking".

11mo agoHN ↗

"Jail", on the other hand, is a great metaphor for a walled garden.

11mo agoHN ↗

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.

11mo agoHN ↗

Sounds like a vulnerability in their cell network, not in Android.

11mo agoHN ↗

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

11mo agoHN ↗

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?

11mo agoHN ↗

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.

11mo agoHN ↗

I wouldn't mind your servile attitude so much if it wasn't dragging the rest of us down with you. A key part of "may your chains set lightly upon you" was "go home from us".

11mo agoHN ↗

Because the airwaves are a shared service license to the carriers. Like someone posted about Australia, there were laws made that if a phone couldn’t make emergency calls. It can’t be used.

There is no monetary reason for Google to forbid a service that could increase its addressable market

11mo agoHN ↗

Stop pretending Google was legally compelled to do this. So far not a single law against VoLTE has been cited.

11mo agoHN ↗

No one said it was the “law” the carriers have certification requirements

11mo agoHN ↗

I don't follow - you'll have to hold my hand through your argument. You said the airwaves are a "shared service license" to the carriers, and so the carriers "have certification requirements".

If by that you mean the carrier has to be certified by the government for access to the airwaves, then that's just "the law" with extra steps. Nobody has cited a law or regulation that would demand carriers block any device that an end-user can modify to enable VoLTE.

If you mean that the carriers require certain certifications for the devices on their network, and these certifications have no basis in law (i.e. they are permitted to allow VoLTE-capable devices on their network, they just choose not to), then this is just mega-corporations colluding to sabotage consumers.

11mo agoHN ↗

No one is “colluding” certification means that your phone has to support all of the necessary industry standards. The phone manufacturers certify their phones meet those standards. There is nothing to be gained monetarily by keeping phones off their network.

Just like with any device on any network an out of spec device can cause issues.

11mo agoHN ↗

Google did this because otherwise carriers would refuse access to Google Pixel phones entirely on their networks. Carriers are legally allowed to refuse access to devices they deem faulty on their networks.

11mo agoHN ↗

Please avoid this type of maximalist rhetoric. There is clearly a public good to be served by making sure it's not easy to disrupt radio communications, especially by accident. Since any antenna, if not carefully controlled, can cause significant disruption in radio communication around it, it follows that it's a good thing, in principle, that users can't easily misuse their radio emitters to cause disruptions for others. I would say that this is all fairly uncontroversial, outside some extreme libertarian "my property woo!" positions.

Now, while in this particular case, the "vulnerability" that Google patched wasn't affecting the actual radio components, it may have still caused disruptions to the 4G/5G software - it's not very clear to me. It's also very possible that it didn't, and it was just allowing users to circumvent some market segmentation BS that some carrier marketing invented. In that case, I'm all for using our political power to prevent such BS.

But this is still a completely different argument than claiming that you should be allowed to do anything with your phone because you bought it (at least allowed by the design, even if it would be illegal). This is simply not a real right that anyone recognizes, or even desires - again, beyond some extremist libertarians.

11mo agoHN ↗

I am not objecting to it not being allowed to jam radio/disrupt communications. I am objecting to corporations one-sidedly policing us, using said disruption as a mere excuse (or not even an excuse in this case - Google secretly patched this, without disclosing it in the patch notes).

Is it really an "extremist libertarian" position that corporations shouldn't abuse their backdoor access to our devices to enforce their whims? Or even that our property shouldn't enforce laws against us? Like mandating all cars come with a remote shutoff that police can use. It sounds like a totalitarian dystopia to me.

11mo agoHN ↗

The point is that, according to the law a sit stands, a device manufacturer that knowingly ships a device that can be used to accidentally jam communications is breaking the law. Not only is the device manufacturer allowed to modify the device to prevent this, they are compelled by the law to take reasonable steps to do so. Automatic updates are such a reasonable step (and note, you can refuse to install updates on your Android phone - of course, you'll miss out on security updates as well, and may not be able to run certain apps if you're too far out of date). The exact same thing is true of cars.

If a car manufacturer realized that they accidentally left a button in your car that allows you to leak oil, they would have to issue a recall, and any service shop that worked on your car would be obligated to remove said button to make your car work - at the auto maker's expense, of course. The service checkup is the equivalent of the online update on your phone: you're not forced to do it, but many things will stop working if you do, and illegal features will be removed from your car at the checkup.

Of course, I agree that the patch here is not at the same level as an easy way to accidentally jam nearby radios. However, the general legal principle is the same: the argument "Google can't legally modify my property in ways I don't want when I install an update" isn't true, because they can and should have this power in certain cases. That the particular case of enabling VoLTE despite the carrier settings disallowing it doesn't warrant this power simply means that this case should be fought by different arguments, not by a general principle that simply doesn't exist in law.

11mo agoHN ↗

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!

11mo agoHN ↗

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.

11mo agoHN ↗

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.

Because different countries use different sets of bands. That was true for GSM too, but quad band phones were reasonably available. Many phones were at least tri band, so you would at least have half the bands if you imported a 'wrong region' tri-band.

But now, you'll have a real tough time with coverage in the US if you import a EU or JP phone.

11mo agoHN ↗

Plenty of phones support all reasonable bands. The intentional 4G brokenness is much worse.

11mo agoHN ↗

With a "quad band" LTE phone of bands 2, 7, 20 and say 12 you would get pretty much worldwide coverage. It'd just be slower because you can't access other ones. Not sure what the issue is?

11mo agoHN ↗

The issue is the import phones I want to buy don't suppprt those bands. An example phone I might want (Xperia 10 IV) supports 12 bands for LTE, my carrier (US T-Mobile) supports 6, but the intersection is only 2 bands (the old GSM bands) and I know my carrier doesn't always have coverage on those bands. I've got enough dead zones without throwing out 4 bands.

11mo agoHN ↗

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.

11mo agoHN ↗

you're not going to be able to receive National alerts or make emergency calls if your phone can't make calls period...

11mo agoHN ↗

Yes, which you'll be aware of, and likely buy a working phone. If your phone can do everything else, you'll think it's all good until an actual emergency happens.

11mo agoHN ↗

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

11mo agoHN ↗

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.

11mo agoHN ↗

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.

11mo agoHN ↗

Pretty much, but the govt didn't do any blocking directly. They just told the carriers, "Hey, you must not allow people to use devices on your networks that are unable to make emergency calls, or we'll apply serious penalties."

The carriers then responded, "I notice that there is no requirement that we allow any device that can make emergency calls. So we will only allow devices we also sell (and maybe a few other models, if they're popular enough that we can't get away with not allowing them). And if that means more people than necessary will have to buy new phones, we will happily sell them new phones."

11mo agoHN ↗

A phone company cannot test every phone in the world to block or whitelist it.

11mo agoHN ↗

Pretty sure they have more than enough money to do that if it was a requirement.

11mo agoHN ↗

They could have made a fake emergency number and say "dial this number by Day X or we'll blacklist your IMEI". They didn't do that.

11mo agoHN ↗

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.

11mo agoHN ↗

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?

11mo agoHN ↗

I mean, I guess there's an app, but I just use whatever happens in the normal dialer. In app settings, I have the t-mobile app disabled (since apparently I can't remove it), and I don't see anything voicemail related. I do know that google hides some things, but I'm not setup to look beyond the UI.

11mo agoHN ↗

It's the case for Google itself. I use Google voice for voicemail, not my carrier, and it's not possible to get voicemail in the phone app.

11mo agoHN ↗

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

11mo agoHN ↗

Which is exactly how netbooks with OEM specific Linux distributions looked like at their end.

OEMs will always go for what provides their differentiation, selling good hardware alone doesn't cut it on their mindset.

11mo agoHN ↗

This is Pixel phones. Google charge iPhone price for mediocre hardware.

They are expensive now.

11mo agoHN ↗

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.

11mo agoHN ↗

Graphene just made VoLTE / NR / VoNR toggle feature built-in to their OS.

11mo agoHN ↗

Does that work for inbound calls, or just for outbound? How does the voice network find you?

11mo agoHN ↗

VoLTE is normally for both inbound and outbound. It is not 4GLTE base functionality, but is available if the phone supports it on the carrier and the carrier supports the use of it. An alternative is CSFB, which is about switching to 3G/2G (where calls are base functionality) for the duration of the call, but 3G/2G is not available everywhere. VoNR is like VoLTE(the ability to make and receive calls on 4GLTE), but for 5GNR. The carrier's equipment can find the phone for example by the phone sending tracking area updates/location area updates so it "knows" where the phone can be asked to connect so it can receive an inbound call etc.

11mo agoHN ↗

Well, I used this so - fuck Google. Android will soon be more locked down than iOS.

11mo agoHN ↗

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.

11mo agoHN ↗

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.

11mo agoHN ↗

Depends on how the rollout of mobile networking historically went in a particular country. (Mostly, from what I can see, if it was the entrenched landline monopolists from the start or if they had to outcompete a few upstarts first.) In some places (Russia, Ukraine) you have to explain to people what a carrier-locked phone even is, and they get (understandably) appalled at the concept. Others (Turkey) have went as far as to have infra to IMEI-block you after you spend too much time in the country until you pay up.

11mo agoHN ↗

Turkey situation is different. IMEI block is here to collect exorbitant taxes.

This have nothing to do with carriers.

11mo agoHN ↗

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

11mo agoHN ↗

whitelist/blacklist phones depending on extensions available

That would be, I believe, fine. Those are capabilities-based restrictions.

From my point of view, the issue would be if the same phone worked with the same technology over the same mobile network when connected via a carrier A but the same phone on the same network refused to work with the same technology when connected via a carrier B.

11mo agoHN ↗

From my point of view, the issue would be if the same phone worked with the same technology over the same mobile network when connected via a carrier A but the same phone on the same network refused to work with the same technology when connected via a carrier B.

But thats the whole point of carrier profiles ( If I didn't understand wrong. )

Eventually it is the carrier who decides what you can do. ( this can also may be related to deals they made with manufacturers )

I think in this case, it is just missing carrier profile. ( which is like a config file )

11mo agoHN ↗

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)

11mo agoHN ↗

That sounds like a regulation thing, that Google must follow. I doubt Google wants to implement complicated region blocking code.

11mo agoHN ↗

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

That's how it was with GSM.

11mo agoHN ↗

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.

11mo agoHN ↗

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.

11mo agoHN ↗

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.

11mo agoHN ↗

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

11mo agoHN ↗

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?

11mo agoHN ↗

Australia bans phones not capable of 4G 000, except for roaming. Tons of phones support VoLTE, but not emergency VoLTE for some reason.

11mo agoHN ↗

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

11mo agoHN ↗

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