2) chipsets in phones vary by where they are sold.
3) only exynos chipset phones are affected. in some economies. sold by some vendors. Not all models with a given name and code number (pixel 7, samsung 22) will be affected. "it depends"
4) not all manufacturers declare their chipset so
5) it is almost impossible for anyone but the cogniscenti to know if they are exposed to the problem, and a huge amount of FUD is flying around right now about exactly which models, which versions, which economy variants are affected, patched, can be patched, will be patched
6) the "turn off" button has been removed from some phones, presumably at the behest of the carriers to have to gatekeep VoLTE and VoWIFI and decide if they want it on or not, and do not always permit users to decide this for themselves.
It's also not crystal clear which Exynos chipsets are affected. I have a Samsung Galaxy S10e and a Samsung Galaxy S2 which both have Exynos chipsets, but I can't tell if there's simply no mention of these being affected because they're older models, or if it's explicitly only the newer models that are affected.
Fingerprint sensors. I don't miss the times where I had to always enter my passphrase on unlock at all, massive time saver.
Also not being stuck on an ancient version of Android - though I don't know what the custom ROM community for that phone is like, perhaps some soul is still porting newer versions to it.
If I had more time, I would've liked to create my own ROMs for some of my old devices (more specifically, kernels).
If hardware manufacturers published a list of their own patches to the source tree (rather than the typical "single commit/zip file of the entire linux kernel") then it would make community maintenance of old devices much easier.
I keep a few older phones updated for the purposes of travel, backup phones or in case a friend needs a phone temporarily etc.
Some older but popular models still have community maintained ROMs. I try save them from the scrap heap if I can. The main annoyance is battery life and having to keep Micro-USB chargers around.
Those are great things to have, but I'm not entirely sure how they would help at all here. An unlockable bootloader would let you install…what, exactly? The patches for this have not been disclosed. What would your kill switch do? Turn off cellular communication? Good luck being able to use your phone…
Bootloader ROMs let you install open source Android, which typically you can arrange how you see fit. So, either patch the vuln yourself (extreme) or toggle a setting somewhere.
Hardware switch lets you disable wifi completely - I own one phone like this actually, you can flip about 6-8 different seperate switches this way.
Then just wait untill patch becomes available/you have time to configure properly, then this becomes trivially resolved, instead of pulling teeth to get your carrier to push an update, replace your whole phone, etc...
Right but that’s exactly my point: you can’t patch the vulnerability yourself because you don’t know what it is, and the alternative of disabling radios is debilitating and you can do that in software too, since this isn’t a bug in that switch itself.
It doesn't sound reasonable to me to recommend disabling something without providing even minimum information on how someone could exploit it so that I can determine if it's likely to be exploited against me. I could live without VoLTE and Wi-Fi Calling, but some people live in areas with bad cell coverage, or no 2G/3G coverage, so they just can't turn it off.
I believe the VoLTE toggle's presence is controlled by whether there is any fallback from VoLTE. Apparently a substantial number of carriers don't offer anything other than VoLTE at this point. Turning off VoLTE when you are with an affected carrier is equivalent, at that point, to just turning off calls altogether.
I greatly appreciate your nuance to cut through the FUD! I reflexively disabled Wi-Fi Calling on my Google Pixel 7 Pro phone.
A cursory Google search indicates that exynos modems don't support CDMA (apparently it's too expensive to license from Qualcomm) and are largely sold outside the USA.
As a Verizon customer in the US, I believe this means I'm in the clear.
Like another commenter, a side effect of responding to this article was discovering that the March 2023 security patch is available (even though I didn't get a notification about it).
1. I've not seen anyone explain whether this could be exploited by anyone with access to phone lines (i.e. Twilio users) or not and if it would be trivial to try the vuln with every phone number you could find in any DB. If those things are the case, it seems like the chances would be very high that this would be or has already been exploited and affecting every unpatched phone.
2. It seems like Project Zero mistakenly thought that Google devices were already patched when they made their announcement ("affected Pixel devices have received a fix"). Whoops! Thanks for giving attackers a heads up.
3. When contacting Google support (specifically Fi) multiple CS reps told me repeatedly this was all fake news and that Project Zero was unaffiliated with Google. They assured me there was no problem, and if there was a vulnerability, it would be communicated on the Fi website (which has no service status or security pages and has never published any outages or vulnerabilities in the past).
4. The delayed March update for Pixel 6 phones doesn't even show up when you open the software update panel (which shows a checking animation that I assume does nothing). You have to manually check again. Who knows when the folks who are unaware of this vulnerability will actually be prompted to install the patch.
Google have guaranteed at least one person and their family to never purchase another Google product or service.
> When contacting Google support (specifically Fi) multiple CS reps told me repeatedly this was all fake news and that Project Zero was unaffiliated with Google.
I hate CS reps. I used to work as one but I never lied. If I didn’t know something and I couldn’t find it in my knowledge base I contacted the on-site staff to relay the caller’s question/concern.
> It seems like Project Zero mistakenly thought that Google devices were already patched when they made their announcement ("affected Pixel devices have received a fix"). Whoops! Thanks for giving attackers a heads up.
Do you have a source for the fact that Pixel devices don't yet have a fix? The post we're commenting on is actually just blogspam, with its only real source being the initial project zero disclosure [0], which still asserts this to be the case...
The blog post was published on the 16th.[0] Pixel 6 and 6a started the update rollout on the 20th.[1] The March security update was scheduled for earlier but was delayed for 6/a for some reason, and it seems like the Project Zero team didn't check on the actual status of the rollout.
> Tests conducted by Project Zero confirm that those four vulnerabilities allow an attacker to remotely compromise a phone at the baseband level with no user interaction, and require only that the attacker know the victim's phone number.
I read that as well, and either it's unclear or I lack the technical understandings to apply that to my question.
What does "at the baseband level" mean in terms of remote attack vector? Do they need to be physically nearby with an antenna or could they be across the world connecting through VOIP?
And why do they need to know a phone number? If it's that they need a nearby antenna + knowledge of a phone number, it sounds like this vulnerability might not be a big deal, and it would be great if they communicated that clearly. Alternatively, if the vulnerability is accessible from any remote phone connection, knowledge of a phone number wouldn't matter because attackers would spam the attack against millions of numbers.
In effect, it means if they can call you, they can exploit you. The description given was what an attacker needs to hack you in particular, which means they need your phone number to determine which device to target. If they want to spam a million users they could do that too, although these kinds of things are typically not done this way because that is very noisy and reduces the effective life of the vulnerability.
> If they want to spam a million users they could do that too, although these kinds of things are typically not done this way
That seems like a convenient assertion not based on evidence.
Without trying to sound confrontational, it appears as if you are a current employee of Google, which might have colored your comment and should probably have been disclosed.
No offense taken, I’ve seen confrontational and it can be far worse than this ;) I do work for Google; in fact I work on detecting malware for Android. I have no special knowledge of these bugs, in fact I would be surprised if I even have access to them by default. Project Zero typically handles discovery of zero days internally, and this kind of thing requires working with partners and whatnot, so it’s pretty out of the way. What I know for these bugs is summarized by the blog post. If the bug ends up being exploitable from an app, or it’s been a couple months, I might see what is going on with them, but we’re definitely not there right now. And information about specific bugs and how they are being exploited is generally NTK so I wouldn’t talk about that publicly anyways until they are disclosed officially or the patch is public.
With that out of the way, and the obvious “please ask before quoting me in a news article and absolutely do not treat this as any sort of official Google thing”, this bug is quite serious and of the kind you would typically see in a targeted attack. As I mentioned above, you don’t really want to be noisy with how you’re using an exploit because then people will catch on and try to defend against it. Plus, you generally want a specific thing from the person you’re targeting. Hacking into a million phones and getting value out of it is pretty hard. For targeted attacks things like personal information and specific assets are valuable. On a wide scale, what are you going to do? Steal credit card numbers and wallet keyphrases for a handful of popular clients? Why not just try to pwn the app itself, or phish people, which is a lot less effort?
I don’t want to sound like I’m making this claim because it sounds better if it’s not used for widespread attacks. It absolutely can be used for this, which is why its capabilities are very concerning. But the reasoning behind this is based on what the market for exploits looks like, not just speculation. Large-scale uses of them are typically cheap reuses of n-days by unsophisticated attackers (which is something I do actually deal with personally). In the very rare cases you see actual 0-days used (I can actually mention one now, search for “Pinduoduo”!) they are not of the baseband variety but typically sandbox escapes and abuse of APIs that allow for background execution, accessibility access, and the like.
Thanks for your thoughtful reply. Maybe Google could benefit from having you train customer service for a few days ;)
> you don’t really want to be noisy with how you’re using an exploit because then people will catch on and try to defend against it
My initial reaction was that the vulnerability was already published so why would they care, but I can also imagine how the actual payload could be something to hide as well. That said, couldn't an exploit simply turn off security updates? It sounds like this vuln has full access to everything on the phone.
> In the very rare cases you see actual 0-days used
But that's the issue--it's not a 0-day. It was publicized before the patch went out for millions of users. Was the patch force-updated for everyone else? If not, that number of unpatched users is probably an order of magnitude greater.
This isn't an issue of some state-level actors sitting on a secret 0-day, it's a use-it-or-lose-it moment for anyone who's heard about it straight from Google's mouth.
Full access to SMS 2fa and email accounts seems like everything. That gives you access to most people's bank accounts. You could search emails for crypto accounts and MITM non-SMS 2fa apps if you have root access to the phone. Sending money requests to contacts using real names. I could think of a million ways to use root access. I don't know the cost of exploiting this vulnerability, but I know that sort of access is valuable to a lot of people.
Why wouldn't this have been a goldrush to exploit by unsophisticated attackers? Maybe I'm missing something?
> Maybe Google could benefit from having you train customer service for a few days ;)
Customer service? What customer service? :P
> That said, couldn't an exploit simply turn off security updates?
Sure, but I was thinking more along the lines of if you have a widespread issue then people will write about it and how to restart the device to clear the infection, turn off remotely exploitable surface area, etc. For example I know a lot of people would turn off iMessage when the effective power stuff was going on since it was so easy to exploit and used widely to troll.
> Why wouldn't this have been a goldrush to exploit by unsophisticated attackers? Maybe I'm missing something?
Right, this isn’t an 0-day anymore, because Google knows about it. Some of the bugs also have patches available, making those effectively public. Apparently, some are not fixed yet and also easy to exploit, for which Project Zero has made a rare exception for and not disclosed.
In general, if an exploit remains unpatched for a while, it will actually start being exploited by opportunistic attackers. Some exploits are actually really easy to launch, because they are simple or someone left a PoC online. Those can and do get spammed en masse by things like ad networks and generic malware.
For more complex exploits, or partial patches, you’ll often need a sophisticated attacker to actually design the exploit once the bug is known. Those ones are not generally in the business of hacking a million people and trying to get their credit card information. Top vulnerability developers are frighteningly fast in how quickly they can make a working exploit out of a patch that they diffed to my knowledge it’s more reliably lucrative and safer for them to sell it to people who use them for targeted attacks, so that’s what they do.
Anyways, here I suspect the answer is “the ones that are public are hard to exploit” and “the ones that are not public might actually be dangerous and were withheld for exactly that reason”.
> Google have guaranteed at least one person and their family to never purchase another Google product or service.
They did that when they waited more than a month to patch the phone call bug in Pixel 6 series. What if someone has an emergency? Nope, Google thought that can wait.
Interesting that earlier coverage of this also indicated VoLTE as vulnerable, but a lot of phones don't have a way to turn that off - particularly since older protocols that support voice directly have been turned off.
I am curious whether attacks on this can be blocked at the carrier level.
Worst case you could do carrier level forwarding (via website or code so the call never hits your phone) to another number that you can also use on your device independent of the modem call handling. Obvious candidates would be Google Voice, Zoom Phone or other VOIP options. Google and Zoom may be the simplest options unless you're already using a SIP provider with a decent app, standalone SIP apps seem to be a weak area for app development. Last time I looked Zoiper and Grandstream Wave seemed like the best options not tied to specific VoIP providers.
Edit: Obviously this will then involve using that app for receiving calls, but you should be fine making outbound calls with your regular number.
Edit2: if using Zoom keep in mind that it limits the number of devices you can be simultaneously signed in on which may impact either receiving calls on your phone or being on Zoom conferences from larger devices like tablets.
> Interesting that earlier coverage of this also indicated VoLTE as vulnerable
The initial reporting on Project Zero's findings was pretty clear that this was the case.
>"Tests conducted by Project Zero confirm that those four vulnerabilities allow an attacker to remotely compromise a phone at the baseband level with no user interaction, and require only that the attacker know the victim's phone number," Willis wrote in a breakdown of the security flaws.
Willis suggests turning off Wi-Fi calling and Voice-over-LTE (VoLTE) to protect against baseband remote code execution, if you're using a vulnerable device powered by Samsung's silicon.
Willis suggests turning off Wi-Fi calling and Voice-over-LTE (VoLTE) to protect against baseband remote code execution, if you're using a vulnerable device powered by Samsung's silicon.
The problem is that that's a very sterile way to say "turn off all voice calling features on affected devices" unless I'm misunderstanding how modern cell networks function. Without VoLTE in pretty sure devices need to fall back to 3G (effectively off in most of the world) or 2G (not much better, though it's still around on one carrier in a lot of places for longer distance coverage as I understand it).
Maybe my understanding is completely off, but this seems like writing an article about terrible flaws in automotive wheel bearings and closing with "we recommend that everyone avoid doing things that require use of wheel bearings."
Well, this was an awkward way to realise my phone hasn't been receiving security updates for years. Apparently Google quietly dropped support for it? The phone is otherwise in excellent condition. Any recommendations for a good third party OS that still supports Pixel 2?
I've been a (happy) Lineage OS user since 2013, and Pixel 2 is still supported by them, so you can check them out. But note that the security updates provided by Lineage OS only pertain to the Android part, not the modem part. This isn't something that a third party OS vendor can fix, as the modem/firmware updates are supplied by the device vendor. And even those are reliant on their suppliers, so ultimately unless they have the negotion power of a multi trillion dollar company (not every vendor has that), they don't have the power to support devices for a long time either (see Fairphone's struggles with qualcomm for example).
For Lineage OS, they maintain the kernels released by the vendors and backport patches to them. But this often means that the backports only address the publicized CVEs and might gloss over a lot of changes between kernel versions that might not have had famous bugfixes. A lot of patches don't end up in a kernel, and often while the version number reads of that of a modern kernel, only a small percentage of the patches in that kernel release was applied compared to the upstream kernel. For this it's important to note that the kernel doesn't have a clean separation between "bugfix" and "CVE fix" for patches, this is already a problem that their officially maintained LTS versions have.
From the security point of view you are definitely better off than staying on something that's unpatched, but I have to mirror what parker_mountain is saying. It's way _way_ better to just get an iPhone as that also gives you modem security updates for half a decade. I am really unhappy about the lack of freedom these devices give me, but I have switched to an SE one year ago. It's just such an incredibly good TCO for really good security.
I am always diverged in my personal opinion about open source and the problems that come with it.
LineageOS has improved a lot over the years, and Android 12 (10+ with GSI images) finally has a working OTA update workflow.
But honestly, the "Android is not Android" problem is hard to communicate and endusers have so many pitfalls.
If you tell them "oh yeah I actually use RethinkDNS as an adblocker, combined with Fennec via F-Droid and its uBlock Origin extension that only somewhat works on mobile due to their messy UI" then you lost already 99% of users that will never figure out how to flash their device with the custom ROM, let alone understand what you just said.
It's so sad that you also have to tell them "but use only one of maybe 10 devices, all other Android devices are either totally outdated with their kernel or cannot be supported anymore"... and when I read your comment I kind of have to agree with your point.
iPhones have zero maintenance. It's a golden cage but it's a well built one, and most users just don't want to spend days and weeks learning how to maintain their smartphone.
No but if their Pixel 2 is no longer receiving security updates then figuring out a replacement plan (even if you don’t plan to do it yet) seems like a good idea.
With a cursory search I found CVE-2021-0316. This one's just for bluetooth, but it's an RCE with no user interaction discovered in 2021. Pixel 2 had its last security patch in November 2020.
Yes, it exists, but is it actively exploitable? A cursory search turns up no working exploit code. Given modern exploit mitigations many theoretical vulnerabilities turn out to be nothing-burgers, as far as I can see there's certainly no worm running around popping phones with it.
For sure, if you're paranoid or a high-value target, update, buy a new phone. But normal users don't need to care unless there's actually something on the line.
Not sure what to say about encouraging users to throw caution to the wind. We got to this point of such good exploit mitigation because it's good for everyone for these devices to be secured.
A bit silly to link a page about malware that Play Protect prevents, largely local privescs that are being detected by the OS or Google Play beforehand.
An average user installing apps from Play Store has nothing to worry about for those. That's kind of the point.
It's great for these devices to be patched - I'd love it if Google would take more control over the ecosystem to be able to patch this sort of thing, but it's much worse for users to just throw out otherwise working devices with limited-to-no real-world security issues.
Google Play Protect has limited capabilities to protect against in-the-wild exploits of the kind Maddie described. It knows about certain packaged implementations, which means that it can offer some defense from off-the-shelf uses of an exploit, but it definitely does not reduce the risk to anywhere near zero. The only correct way to mitigate against exploits like this is a patch, end of story.
GPU bugs are particularly concerning because they have significant power (the GPU can often map all of physical memory if convinced to do so) and widely exposed (lots of things need graphics). Turning one of these into a full chain can often require zero bugs if the buggy API is callable from JavaScript, or one to escape the VM and poke the driver.
Um, no? Most of the RCE's I'm seeing are at the OS level and would require upgrading to a newer Android OS version that older devices won't have support for.
To fully patch, yes, but the point is that Play Protect is detecting them before installation before they can be exploited, ie: on submission to Play Store or on installation on devices.
Yes, this is still a risk - if you tend to install random apks from the internet and disable Play Protect or run across an undetected modification of the relevant exploit code. But most users don't do that.
Gotcha. Still, it's a lot of RCE's coming out per month to depend on blackbox machine learning for something people use every day for their personal/business needs.
I would like to see stats on what percentage of android phones were exploited in the wild for malicious purposes (ie. excluding cases where the user deliberately is jailbreaking them).
Personally I have never seen any friends or relatives get malware on their phone that gets outside the app sandbox (ie. Uninstalling the bad app seems to solve the issue). Compare that to MS Windows where it seems common for regular users to have malware infested systems.
Generally the fraction is fairly low, because the bar for a full chain these days is pretty high. That said, it is important to not be lulled into a false sense of security because you don't seem like an attractive target. A chain worth $50k dollars can be a good purchase if you think you can bring in a million dollars home with it.
I guess, but it sure is nice that on Apple hardware you generally don’t need to worry about doing this calculus because they deliver updates in a timely manner to even five year old devices.
It bums me out that them doing this hasn’t been effective in shaming everyone else into following suit.
According to Wikipedia the Pixel 2 received security updates for less than 3 years. None of their devices got more than 3 years 3 months of updates. That should be illegal honestly, couldn't be more clear that they don't care about sustainability.
Qualcomm's lack of support for older chipsets has been blamed for the short lifecycles of these phones. Pixel 6 and 7, which don't use Qualcomm SoCs, both get at least 5 years of security updates.
I still remember when phones did not receive any updates, and the few lucky models required developer tools to manually upload the firmware updates, which most of those few selected models only got one in their lifetime.
Not sure if you’re referring here to the BlackBerry era or right back to side-sliders and razr flips, but either way, both the stakes and the attack surface were way lower back when there were no apps and phones really were just for calling and texting.
I wonder if Apple views the "iPod" branding as being more associated with gaming and consumption and therefore less important from a security standpoint. I don't think I necessarily would agree with such a stance when the exact same hardware can carry sensitive stuff like a password manager, banking and medical apps, and so-on. But I imagine their telemetry showed that that overwhelmingly wasn't the case, so it was easy not to prioritize it.
No, it's more that Apple has always released iPod with older chips, and in this case it also decided to discontinue that product line, which meant that they dropped software support for it relatively soon.
This may be a special case: "With the release [of iOS 16], Apple dropped support for iPhone and iPod Touch models with A9 and A10 Fusion chips (the iPhone 6S/6S Plus, the 1st gen iPhone SE, the iPhone 7/7 Plus and the 7th gen iPod Touch) due to hardware limitations and Chinese government's border stringent in response of COVID-19 pandemic." https://en.wikipedia.org/wiki/IOS_version_history#iOS_16_/_i...
Every flagship iPhone since 2011 has gotten at least five years of both OS updates and security updates, with some newer devices (including the $399 iPhone SE) getting as many as seven years.
Even after official support completely ends, Apple tends to go back and issue patches for active exploits. The nine year old iPhone 5s just got another security update a couple of months ago.
> The iPod Touch Gen 7 lasted just under 3 years from release.
It was released May 2019, and it just received its latest security update (15.7.3) January 23, 2023. Presumably that is not the last security update for iOS 15.
Well, I use a web browser on the phone. Chrome et al. are still receiving updates for my phone, but I'm guessing they use some system components that are not receiving updates? So my main worry is something like an ad network loading an exploit. You don't need to be a high value target to get caught in an extremely wide net like that.
(Yes, I know: get a better ad blocker, etc. — I'd rather have fewer weak links, though, and a lack of basic OS updates is a pretty big weak link.)
A phone (or any kind of internet-connected computer) that's been completely unsupported for years will presumably be low-hanging fruit for even the cheapest and crustiest of exploit kits.
That is, to put nicely, forced-obsolescence FUD. They want to scare you away with words like "unsupported" so they can keep you on their leash.
With the state of software development today, I'd be more worried about how many other holes they've added in the process of fixing something or introducing unwanted new "features"[1].
Here's some interesting statistics to look at and compare...
It ignores a whole lot more than that. For instance, are we seriously going to pretend that the threat landscape in the Windows 98 and XP eras was anything like what it is today?
Well, I'm not. If he wants to daily drive Windows 98 because it had fewer documented RCE vulns, godspeed to him---and he probably will be more secure, just by virtue of good ol' security through obscurity---but that is not a reasonable solution for 99.999howevermanyninesyouwant% of computer users today.
The threat was arguably exponentially worse during the XP era - Windows boxes with a huge default attack surface were directly connected with public facing IPs to a 32-bit IP space that could be trivially brute-forced by worms. There's a reason we haven't seen anything as bad as Blaster in the past decade: NAT.
The rate of finding exploits and what the definition of a vulnerability is really what has changed - now the definition of is much broader while at the same time, exploitability has dropped off due to mitigation in modern operating systems, compilers and CPUs. Overall, we get far more exploits, but far less of significance.
Yes, it was not my intention to imply that those old operating systems were fundamentally more secure in some way. You're getting at it here: the space has broadened, and asserting that old software is more secure than new software based solely on documented RCE counts is laughable.
Most code that interacts with the internet is updated via other mechanisms. For example, web browsers are kept up to date via Play Store: Firefox for Android, Chrome and even the embedded WebView are all updated there.
How was this quiet? This is usually published by Google and other web sites when security updates have needed on the Pixel Phones.
Given you're a HN user I assume you are fairly tech savvy and knew when you bought your phone it was only going to get security and system updates for 3 years.
I guess I haven't had any time to actively care about this stuff for the last 2.5 years (new parent). So when my phone tells me "Your device is up to date" with the reality in small text further down the page, apparently I am able to miss this.
Sure, I have to take some responsibility for poor digital hygiene or whatever, but I don't think that negates Google's awful management of this. I shouldn't _have_ to be vigilant/proactive to stay safe in something as basic as this.
Aside: Google spams me with all kinds of noise in notifications these days; couldn't they at very least put something in there saying "by the way, your device is now EOL; buy a new one"? Ockham's razor suggests to me that a _lot_ of people are running unsupported devices still, and Google doesn't want the collective backlash of putting that uncomfortable reality in people's faces.
I think it's "quiet" in the sense that they don't send a push notification to affected phones when they're about to go EOL, so you don't know it happens unless you go out of your way to check.
Or put the EOL in the final OS update for that phone, with a permanent status icon / notification warning that the device is EOL. It's not like they decide at their morning stand-up, "hey, Pixel 2 has been out for a while; anyone object to killing it off today?" There's plenty of time to roll that sort of thing out, however it works under the hood.
You could try to put Graphene on your phone. There is a version for your phone, but they are not updating it anymore. However I think that it is a good option for a more secure, private, operating system.
https://grapheneos.org/faq#device-support
I hate to say it, but get an iPhone SE. 5 years of updates /from when the device was last sold in stores/. If you sideload any Android apps, you'll have to wait in a cold until the latest pixels are patched, and then get one of the a-models.
> Pixel 6 and later phones will get updates for at least 5 years from when the device first became available on the Google Store in the US.
That's not really the same thing as "updates for at least 5 years". The date the device first went on sale in the US isn't particularly relevant. They'll still sell it to you long after that, and then end support not long after it's out of warranty. That's what happened to mine.
The lessons I'm learning here (if I'm running a first party OS) are:
- Check very carefully how long different vendors actually support their devices. Google is pretty rubbish on this front, it turns out.
- Always buy the latest model when buying a new phone, even if it doesn't have anything I need, or I'll just have to "upgrade" twice as frequently instead.
And yet Google used Exynos for those designs. Somehow Samsung must have told project zero that they didn't need to release a fix - a project run by their customer for this SoC. But promptly after disclosure a fix appears. I guess it's good that they'll come out for five years, but it's probably worth a little bit of doubt on our part whether Samsung will actually deliver on that promise.
Oh my god is that why Apple has yet to put modems in their laptops? I could totally see Apple unable to compromise on support for a Qualcomm modem for something like 8 years.
Apple's designed Qualcomm out of next-generation iPhones (again) [1], only this time they've acquired the Intel/Infineon modem design team instead of buying the parts. So if Apple were to make a Macbook with a modem next year, it'd be their own.
Honestly, I think it's because they believe anyone with a macbook should have an iphone - their easy and transparent tethering works embarrassingly well.
Maybe, but they were looking for a phone that'll last a long time, and I hope my answer makes them reconsider. The Android OS-updates situation is seriously dire, and it seems very difficult for Google to fix.
but.. their old phone is still operating fine, it isn't even affected by the Samsung modem exploit, and best-of-all the pixel 2 is well supported by many third-party Android roms.
Parent literally has one of the best supported older phones available for third party OS installation (which, incidentally, is what parent was asking about..)
so, in the interest of e-waste/recycling/keeping old things going I hope they reconsider the value of their already-owned hardware and how it may still continue to serve them.
fwiw, third-party android roms are only part of the story. And, in an article about the baseband being compromised, I would hope people would take that into consideration.
>so, in the interest of e-waste/recycling/keeping old things going I hope they reconsider the value of their already-owned hardware and how it may still continue to serve them.
In the interest of security, both theirs and the people they communicate with, I hope they consider upgrading their device to something that has a very long lifespan of active security updates.
Thanks. I don't mind that you didn't address my question directly, because this is all relevant food for thought.
Every year I'm more disappointed by Google on pretty much every front. They really do seem to have jumped the shark.
If I do decide to upgrade...
Unfortunately I can't stand iOS. No kidding, I'd rather have a Nokia 5110. I've tried repeatedly, thinking "I'm just not used to it", but there's too much about the design philosophy that I find actively obnoxious. Strangely, I don't have this problem with macOS.
Maybe I can find another Android vendor with a better support policy, or if none of them are any good then just suck it up and buy the very newest of whatever to at least push the planned death of my device back a couple more years.
I'm getting a bit sick of this treadmill. I don't buy the defence some people offer that it's too much work to support the older devices. Having a security-only backports release series for old devices would be _trivial_ compared to the enormous piles of money Google sets on fire for shits and giggles on a daily basis. It's planned obsolescence, plain and simple.
> Unfortunately I can't stand iOS. No kidding, I'd rather have a Nokia 5110. I've tried repeatedly, thinking "I'm just not used to it", but there's too much about the design philosophy that I find actively obnoxious. Strangely, I don't have this problem with macOS.
That's how i feel with iOS and macOS, the whole design philosophy and UX feel alien to me, and makes me hate every actual issue I encounter even more.
> I'm getting a bit sick of this treadmill. I don't buy the defence some people offer that it's too much work to support the older devices. Having a security-only backports release series for old devices would be _trivial_ compared to the enormous piles of money Google sets on fire for shits and giggles on a daily basis. It's planned obsolescence, plain and simple.
From what I've understood, it's mostly the hardware components' vendors' fault - Qualcomm and co that provide the SoC and modem. It's their firmware which isn't kept up to date by the manufacturer (because it isn't easy to do so), thus phone lifecycle is inherently limites. There have been massive recent advances in that area though, with on one hand more vendors (MediaTek, Samsung) that could maybe be forced to compete and thus have to differentiate from one another, but also big changes to Android and the way updates are done, to keep firmware/driver/kernel updates as simple as possible to develop and roll out. We can see the effects with multiple Android vendors (e.g. Google, Samsung) now supporting phones for much longer.
So hopefully soon things will improve.
Not if it was done well, unfortunately... I suppose there's always sending a text to a friend saying "I'll leave the money in a blue bag on the corner of 4th ave at 10am tomorrow" and hiding in the bushes (but sadly we'd expect an attacker who was halfway across the world, not across town). I am pretending everything is fine until I can't.
I am not sure I understand this. I have a S22 Galaxy Ultra. I do not see anywhere in my settings to turn on or off wifi-calling. Did we already get an update disabling this? I have googled this for about 10-15 minutes now and none of the results match anything to do with my screen settings.
FYI if you bought your S22 Ultra in the US, it probably isn't necessary. Only the European models were shipped with the Exynos chipset and would be vulnerable. The US version was shipped with a Qualcomm chipset, so it shouldn't be an issue.
(This is what I recall on the top of my head though, so you might want to double check this info)
Confused, is this OS-level or baseband-level? If it's OS-level, how is there no mention of an Android version? If it's baseband-level, how can the OS fix it?
I don't know if it's true for this particular OS, but some OS's bundle the baseband, bootloader, and other vendor-specific images so that they're automatically updated, like with the stock OS.
Very nice for people who have reliable cell coverage at home and everywhere they go. I am not going to effectively disable my phone living on the hills, my family may need to reach me. Come up with a fix, VoLTE presumably goes through some server that can do data validation.
There are two versions of the S22, Exynos (Europe) and Snapdragon (everywhere else). Is it correct to assume that the Snapdragon S22 is not affected by this?
Turning off VOLTE and WiFi calling on phones sold in the USA means using airplane mode - there is no VOLTE switch and most carriers in the USA no longer have 3G service anyway.
Edit: I mean Pixel phones sold in the USA, I'm not sure about the other ones on the list. My 6 Pro does not have a VOLTE toggle.
At this point I'd have to say that Wi-Fi calling is a dead feature, putting this particular issue aside.
I just don't see the benefit in 2023. It made sense back when cellular networks were less mature. It also made sense when it could cut down on your wireless bill.
But all you have to do is walk out of your house while on a phone call and realize how much the feature is degrading overall reliability.
The LTE network on my phone has less downtime than my home Internet. Heck, for some people their LTE network is faster than their home network.
I'm struggling to figure out where Wi-Fi calling is helpful. On a cruise ship?
It really depends on where you live or where you commonly use your phone. In the US at least, there are huge areas all over that have little or no cell coverage. In the SF Bay Area, home of Silicon Valley, we have plenty of spots where people live where there's zero coverage. In those places, if you walk too far away from your house (and Wi-Fi) your cell phone is useless.
Where I live, I basically agree, but as far as I can tell Wi-Fi calling is much better audio quality.
> as far as I can tell Wi-Fi calling is much better audio quality
I don't doubt your experience, carriers can absolutely be stupid/frustrating in how they operate their networks, but there's usually little excuse for this. These days its all the same possible codecs, its the same kind of handshake. There's little excuse to not support wideband codecs in regular phone calls with VoLTE and what not.
You're struggling to figure out where wifi calling is helpful, really?
Maybe a house that doesn't get cell reception inside, especially older ones with thick walls. Or one that doesn't get cell reception outside either. ??? was that difficult?
And when you're new to an area, your carrier probably has your entire region colored as 'Excellent' on their coverage map, even though the only places you can actually get a signal is if you stand in the middle of the highway interchange out on the west side of town or up on one of the rooftops downtown. You have to ask around among the locals to find out which carrier _actually_ works in your town so you know which to switch to. Until then, wi-fi is your only comm link unless you can still find an old payphone.
And naturally if you're just visiting or passing through, you're not going to want to change carriers every time you stop at a new town.
You're thinking in terms of on-the-map coverage. Real-world coverage is affected by stuff in the way. I know plenty of people who can just barely get texts on a good day unless they go outside and wave their phone around. Phone calls are out of the question without Wi-Fi.
Wifi-calling is basically required for rural, semi-rural, hilly, or mountainous areas around here. Huge chunks of the western United States has terrible cellular coverage. I regularly travel to a region with a population density of 0.25 people per sq km, no one is going to erect new towers out there.
I think homes with back-plastered walls can be essentially faraday cages, depending on the aggregate content of the plaster. I have very dodgy 4g/5g unless I stand by a certain window, or go outside of the older part of my house, while the new part (metal roof, wallboard) has outdoor-like reception.
Its not even just the aggregate of the plaster, often the walls practically have chicken wire supporting the plaster in places.
But even then, its really not too crazy to find yourself inside any kind of building and not having strong cellular connectivity. Lots of commercial buildings I've been in have had some pretty poor cellular connectivity in any internal room; they've got tons of concrete and plumbing and wiring all throughout it!
Leaving the country to a place this is not included in your calling plan. We did this recently and would get voice calls via the hotel WiFi, pretty cool.
i'm in the bahamas now and had a nice conversation with someone who won't install whatsapp. 6 months ago I was in Colombia and was able to take care of some banking problems back home.
Plus, texts are delivered and sent while you're away.
(And...I do know people in the US who are in cell weak spots that wifi calling solves)
My lab at work is in the interior of a big building, and has no cell phone service. Hell, they seem to have put some RF shielding on the windows since my office barely has reception...
1) not all phones
2) chipsets in phones vary by where they are sold.
3) only exynos chipset phones are affected. in some economies. sold by some vendors. Not all models with a given name and code number (pixel 7, samsung 22) will be affected. "it depends"
4) not all manufacturers declare their chipset so
5) it is almost impossible for anyone but the cogniscenti to know if they are exposed to the problem, and a huge amount of FUD is flying around right now about exactly which models, which versions, which economy variants are affected, patched, can be patched, will be patched
6) the "turn off" button has been removed from some phones, presumably at the behest of the carriers to have to gatekeep VoLTE and VoWIFI and decide if they want it on or not, and do not always permit users to decide this for themselves.