If security patching is important to you, you aren't carrying an Android. This has never not been true. Even here, on a Google phone, where Google can't blame manufacturers for dragging their feet on releases. Over a year after Microsoft officially abandoned Windows Mobile, I was still getting security patches faster and more often than Android phones ever did.
If security is important to you, you carry an iPhone. That's a sad state of affairs, Apple has all sorts of problems and a ton of things I just find weird about the way their devices tend to do things and organize information, but it's just the only actual option right now.
On the contrary, Android is the only somewhat sane popular mobile OS today. I don't want to reboot my phone to update the web browser the way MacOS and iOS update Safari and the way Windows used to update IE. The browser is the application I use the most, and it has the largest attack surface. It should update transparently and not stop updating after the OS falls out of service, like Macs with Nvidia GPUs.
The problem in this case isn't Google dragging its feet on releases. It releases Chrome updates frequently and OS updates monthly. The problem here is Google failing to include security patches for known vulnerabilities in those releases. What's ridiculous is that this is something that can be automated, and after multiple failures, it should have been automated, but here we are.
Don't get me wrong, having to reboot your device to update your browser is silly. But if the choice is between that and waiting until a vulnerability is actively exploited before it's patched, anyone who cares about security will choose the former.
It's very obvious when something like Heartbleed comes around which affects a ton of operating systems, and Windows and iOS and major Linux distros are patched in like a week and then there's a chart to look at for which manufacturer and model and carrier on whether or not you'll see a fix in the next couple months or ever.
Except if you get your OS from a particular vendor, like Apple, Google, or Ubuntu, you only have to check with the vendor to see when it will be released. All three have track records of timely updates.
It used to be the case that iphones were way ahead of security in android. With the efforts that have gone into improving things in the last few years and Google stepping up the quality of their hardware security with their Pixel lines that is no longer the case.
iPhones also have nasty (sometimes unpatchable) vulns. Android gets ever stronger protections against malicious apps, doesnt rely so much on Malware being screened from the store (malware regularly gets through onto both Play Store and Apples App Store)
> If security is important to you, you carry an iPhone. That's a sad state of affairs, Apple has all sorts of problems and a ton of things I just find weird about the way their devices tend to do things and organize information, but it's just the only actual option right now.
Are you aware that the state of security on iPhone is even worse nowadays? At least on Android the system surface has been reduced to its minimum. In iOS, pretty much every system component depends on the OS update and nothing has been decoupled yet.
It's not just Android. I think every Linux device has this problem. I seriously doubt my TV has any of these patches for example.
That's not an excuse of course, but a lot of the blame does lie with the Linux devs and their general disregard for security. I suspect it is a major motivation for Fuchsia.
There are security vendors that provide services for keeping track of vulnerabilities in your third party dependencies and making sure they're patched. Eventually, device makers will use such services as standard practice, but I'd expect Google to be ahead of the ball here with its own implementation, given what they spend on security engineering. This is not a completely new type of issue but one that has bitten them many times before.
This is why regular Linux distros ship the upstream Linux stable releases. Android should too, but I guess they have too many non-merged patches/drivers.
> Learn about the details of CVE-2022-38181, a vulnerability in the Arm Mali GPU. ... the exploit that used this vulnerability to gain arbitrary kernel code execution and root on a Pixel 6 from an Android app.
How is this blanket approval system acceptable? The majority of hardware vendors have lost all credibility in producing secure software, and Microsoft think it is ok to let them load a Logitech/HP wizard toolkit for funsies? Few of them offer any features of note, but I would not be at all surprised they run with elevated permissions and contain trivially exploited code.
Are they? Does that include exploits for a specific model of an Android phone? The exploit in the article applies to a GPU driver for a GPU that's used on a minority of the phones sold in US.
Maybe I'm getting it wrong, but what's the problem in Google flagging this bug as "won't fix"? It's the third party driver that has a bug, not their software. Once the bug is fixed by the third party then automatically it will be fixed for Google.
Maybe the author has a stricter and more negative definition of "won't fix" so it sounded wrong to him?
We all know not 100% of the hardware is made by google. If there was a problem with the touchscreen, fingerprint sensor or camera drivers we all would be aware it came from a third party.
The author knows full well the GPU is not actually made by Google, he is not an ignorant consumer being duped by marketing, so the label is actually 100% accurate for people in-the-know
Even if they're not developing the code, it would be good for them to push the third party to get it fixed, given that the 3rd party is used in their product.
> Once the bug is fixed by the third party then automatically it will be fixed for Google.
The article explains why this isn't a safe assumption and documents numerous cases where patches were not deployed to Android devices until well after the vulnerability was publicly disclosed. https://github.blog/2023-01-23-pwning-the-all-google-phone-w...
Thus is seems obvious to me that closing the bug as "won't fix" is the wrong response. The issue shouldn't be closed until the security patch makes its way into the Android Security Bulletin.
You're assuming that Google isn't keeping track of security bugs they forward to their vendors. Almost certainly they opened a ticket in a different system and tracked it there.
Im not assuming anything, Google has a track record to failing to incorporate patches in a timely manner. I don't see how closing a high priority security bug on their public tracker as "won't fix" helps them do better.
how can they stop using proprietary drivers if they are still relying on third party partners? until google becomes like apple they won't have access to the drivers
Do the same as the Linux kernel community, don't allow proprietary drivers in Android. Linux doesn't allow proprietary drivers and now it has an open source driver for ARM Mali GPUs, Android should stop using the proprietary driver and use the open source driver. Whenever a vendor wants to have a proprietary driver, say no thanks, or reverse engineer the driver. A bunch of volunteers working part-time figured out how to make open source Apple M1 GPU drivers and Google has a ton of money so it could easily hire say 100-1000 people to reverse engineer proprietary drivers full-time and rewrite them from scratch.
It should really say all-Google in the title, as it's otherwise confusing to read. The article even uses all-Google in the first paragraph - but not the title, oddly.
No such thing as an all Google phone. Trying to market the latest pixels as "Google silicon" is a complete joke. Not only the SoCs used are mildly customized Samsung Exynos, they are also terrible at performance and battery life even by Android standards.
as far as I can tell GrapheneOS doesn't have the patch, yet.
the most recent mention on their releases page is for the 2022120300 release:
> kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro): update Mali GPU driver to r37p0 (current release is r41p0 but there are substantial changes to the driver for the Tensor SoC on Pixels and it will take substantial work to upgrade all the way)
> The Arm security team were very helpful throughout and released a public patch in version r40p0 of the driver on 2022-10-07 to address the issue [...]
The writeup of the bug states that it was patched in the January update for Pixels, which GrapheneOS has. But previous work on applying mali patches early led to GarpheneOS having a fix earlier than stock Pixels
https://github.com/GrapheneOS/os-issue-tracker/issues/1914#i...
Android 13 QPR2 Beta 1 came out on December 12th. This included backports of the ARM Mali GPU driver security along with a separate update to r38p1. GrapheneOS shipped these for the kernel driver. We had already done earlier work on updating the Mali GPU kernel drivers, but it's a lot more difficult for us because ARM doesn't make the standalone security patches available to the public and we don't currently have partner access to obtain them directly. We can ship them once Google or another vendor publishes the code. Generally, this will mean we can ship them once the next Android quarterly release Beta becomes available because they ship kernel patches months early in quarterly releases.
> as far as I can tell GrapheneOS doesn't have the patch, yet.
That's not correct. Android 13 QPR2 Beta 1 came out on December 12th. This included backports of the ARM Mali GPU driver security along with a separate update to r38p1. GrapheneOS shipped these for the kernel driver.
> the most recent mention on their releases page is for the 2022120300 release:
That's not the most recent mention on our releases page. This is the most recent relevant change:
> full 2023-01-05 security patch level
Here is a previous Mali GPU driver update:
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to QPR2 Beta 2 release
Here is another previous Mali GPU driver update:
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream)
Looking at the version number is not enough. ARM makes separate security patches available to their partners. Google is primarily shipping the backported security patches and gradually upgrades the driver version. The reason for this is that there are massive changes to the Mali GPU kernel driver for the Tensor SoC GPU. This is why GrapheneOS can't simply update it to r41p0 immediately because there are a massive number of complex synchronization, GPU command quality of service and other changes conflicting with newer releases. It makes the most sense to apply the standalone security patches. Unfortunately, ARM doesn't publish the standalone security patches for the public and we need to obtain them from a vendor choosing to include and ship them since they have to publish the code.
My confusion stemmed from the fact that the bug is supposed to affect pixel 6 devices, which aren’t listed in the QPR2 updates but were explicitly mentioned in the update to r37p0.
We were unable to update the Pixel 6 devices to r38p1 due to more changes being required beyond the kernel driver update. The security patches were shipped regardless, and that also happened upstream for AOSP and the stock Pixel OS for the January update.
All of the security fixes first shipped with QPR2 Beta 1 on December 12 which we shipped on December 14th were then shipped in the AOSP / stock Pixel OS January stable release despite it still using r36p0.
The security patches are available without updating the major release, at least if you're either an ARM partner or an ARM partner has published an update with the patches and therefore released them. In our case, we can't get the standalone security patches directly from ARM but we can ship the kernel backports as soon as they're in an Android quarterly or major release beta. We can't necessarily ship the major releases of the driver just because they're in a quarterly or major release since they can depend on other changes which is what happened with the Pixel 6. It crashes without updating the userspace driver, not just the kernel driver, and updating the userspace driver seems to require other changes. It's not blocking any security patches though.
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream)
Our December 14th release was the release fixing this vulnerability and a bunch of others based on the Android 13 QPR2 Beta 1 release on December 12th which included these fixes. The January release of AOSP and the stock Pixel OS also included the security patch backports without including the update to r38p1. The update to r38p1 is nice to have since it fixes more bugs than the security bugs and has other improvements, so it's nice that we were able to ship it early but it's not really a security feature.
This isn't like the Linux kernel where there are an enormous number of changes and no serious attempt at determining which ones are security bugs. ARM does a good job determining which are security bugs and making security patches available separately. Unfortunately, ARM is not very friendly towards people building on their platform that are not partnered with them. They don't make the standalone security patches publicly available, even after a delay. It's possible they see making the patches available separately as helpful to attackers but that's a bit ridiculous because the code is available either way and it doesn't take long to identify the security patches which are one of the main things being done in the releases.
If ARM made the standalone security patches public available, we could get them to our stable channel within days of release instead of needing to wait for their partners like Google or Samsung to do their own releases and publish the patches. It would be very helpful to us if an ARM partner collaborated with us since we would be able to ship these fixes faster. The reason we can't simply upgrade to the new major releases of the driver immediately is because there are thousands of lines of changes to the kernel driver for the Tensor SoC with many invasive optimizations switching to finer grained locking across the driver, adding quality of service for GPU commands, etc. They made substantial changes to the driver and seemingly also the firmware/hardware to an extent, although likely just in between the actual GPU and the OS where they handle IOMMU, quality of service, etc. If they had a barely modified ARM Mali GPU and driver, we could easily update to each new major release in days, but that's not the case. We could do that on another device without so many changes to the driver though. It's entirely device specific. ARM provides a base for vendors to build on and how much they optimize/improve things downstream varies a lot. Google decided to do a ton of downstream optimization for the Pixel 7 GPU. They decided to focus on the GPU with that generation and let the CPU get neglected, which they'll almost certainly fix next year. Part of the initial growing pains for Tensor has been that they released the Pixel 6 with a great CPU but weak GPU and then the Pixel 7 with a great GPU but outdated CPU. These delays with Mali patches are another example, although other Android vendors almost all did worse not better.
OT: With the current state of smartphone operating systems, I would need one of those to be release every other month or so. I cannot get to data on 'my' system, because an app decided to put it in their app folder, which I cannot access at all for 'security' reasons...
I mean, I get it. It should not be easy to just unlock my phone and dump all my 2FA tokens. But if I want to back them up, i.e. because steam blocks my account for 7 days if I change to a new device, I want an option to get them!
Make me reboot the thing into a special state, connect it to a computer on blood moon and dance in front of the cam to authenticate myself if you must, but for fucks sake, I want to access my data.
That's why I still root my phone. It's hard to explain, but it's simply the only way to actually be in control of my own device.
For the specific use case you mentioned, however, I recommend Aegis with Syncthing. Very easy to set up a periodic back up and sync, encrypted at rest and on transit.
It does (or at least did a couple months ago) - you could have it import Steam keys and generate the codes in the actual Aegis app. I'm not sure if it requires root or not.
Nope. You can use a special app on PC that will simulate the authenticator and extract the OTP key, which you can then enter in Aegis. I'm using it like this and have no problems.
I'm not trying to say it's great, just that a few websites insist on using their own home-brewed 2FA and therefore don't work with the apps that support the standard. For example Twilio/SendGrid, Steam, etc.
Someone in this thread already pointed out that I'm wrong and although they don't use the standard, Steam is supported by Aegis.
The problem with rooting the phone is that it actually compromises features like verified boot and selinux namespacing. I still want those security features for daily use. I still need a way around this, but it at least has to be technically secure. It will obviously still be open to social engineering attacks.
For your suggestion, sadly you somehow need to get steam's otp secret first, which is held in the apps data directory. Therefore you would need root/priv-esc to get to it.
> compromises features like verified boot and selinux namespacing
It only compromises those features because vendors refuse to build in the functionality to have full control over your purchased hardware out of the box. Make it protected behinds loads of warnings and even hidden behind a trick like what you have to do to enable developer mode, but leave it baked into the OS.
Well, I don't deny that there should be an option. Look at the parent post.
But having root in the running OS seems to be a bad idea. I got this position after an extensive talk on this with some of the graphene os developers. They explained pretty good how rooting the device would impact the security measures taken in graphene.
This is why I suggested putting the access behind a special boot mode.
Can you be more specific about your concerns? It's not like "having root" means "everything runs as root". You can enable/disable it per app, you always grant it explicitly when you want to - it's not very different from sudo on Linux.
> The problem with rooting the phone is that it actually compromises features like verified boot and selinux namespacing
I'll grant that on most phones you can't use ex. magisk with verified boot (although on ex. the Pixels I think you could? just more work), but AFAIK there's no problem with having root and selinux enforcing at the same time? Obviously it gives you the ability to bypass those protections, but overruling the usual protections is kind of the point of giving an app root, and you shouldn't give that level of access to apps you don't trust completely (like running `sudo someprogram` on a desktop).
I'm constantly frustrated with techies on HN and other social media claiming my rooted phone is somehow not secure. I've always rooted my phone ever since Android was a thing and have never had any issues.
I was spoiled for years with rooted phones, and ended up making a lot of assumptions because of it, one being that I could always access apps' SQLite databases and cached files if I needed to.
I ended up with a new phone, decided not to root it, and found myself in a situation where I needed to get some cached data out of an app I could no longer access normally. That's easy on a rooted phone, but it's next to impossible on a locked down phone.
There needs to be some way to tell the device that the user is authorized, otherwise it can never do anything that could possibly be security sensitive - forget taking a backup; why should the 2FA app give you a one-time code if you could be an attacker?
Edit: Thinking about it more, I suppose it all comes down to a cost/benefit analysis. It's true that taking a backup of 2FA secrets does give an attacker more than a single code. But when that trade is leveraged against the legitimate user being unable to control their own device, I think it's a terrible trade, to the point that I'm not convinced it's ever worth taking. And of course my real objection is that the user is rarely if ever actually asked; rather, a company tells the user that they can't control their own device, which is unacceptable.
>why should the 2FA app give you a one-time code if you could be an attacker?
Because the app aims to prove that someone has possession of the device. If someone has the key instead they can give back the device and generate codes later without possession. They can also resell the key online without having to ship a physical device. They can sell the same key to multiple people.
I'm waiting for a public exploit for the pixel 7 so that I can do some modifications to my phone (enable call recording outside countries that google supports call recording in). I could unlock the bootloader and root the phone via "normal" methods, however, that means having something that will then fail google safetynet and the like. A root exploit enables me to make the changes to on flash DBs, and then update the device and the DB changes will persist and my phone will be secure.
Of course, such an exploit could be used for more nefarious things, but as google wants to limit functionality that the phone has (that is legal where I am), I'll be patient.
I perfectly understand not wanting to spend time on working around Safetynet, but in case you're not aware, I just want to point out that safetynet is pretty reliably broken (Google clearly doesn't use it for security. I'm pretty confident that it's 99% for passing audits, and 1% for shows). Current stats of the Safetynet workarounds is maybe 7 days of down time per year.
Also, my personal point of view of the matter is that apps that require Safetynet, 1. doesn't care about their users, 2. Do just-for-the-show security, and thus users would be better off not using them. I personally don't use any app that require it.
Some apps suggest they use it when they dont. Some (most) apps use a weaker form which an android/AOSP operating system can comply with, without being registered with Google (licencing Play Services) see eg. https://grapheneos.org/usage#banking-apps
Very few apps use the full strict version of safetynet that requires hardware attestation
Sometimes. Several banking websites only allow login through their apps. There was even a bank here who did a minor update in which they decided to block rooted phones, locking many people suddenly and without warning out of their banking account, I was evaluating them (luckily, it was worse for people who had DKB as actual bank) and had to contact support to close my account.
Don't fool yourself: locking devices from user control should be plain illegal. This is not even a matter of argument or discussion as this is a red line.
The real issue is why this is still not the case in "free" countries.
You have to remember that Arm and other chipmakers are separate companies and do not listen to anyone. CEO escalations only happen if there is major press, otherwise you need to convince some random software engineer in charge of bug triage that your issue is more important than 20 other claimed emergencies AND that he or she can figure out how to do anything about it. The last part becomes much easier when talking engineer to engineer without intermediaries, especially intermediaries from other companies. Sounds like this is exactly what happened. It's not all bad, because decentralized ecosystem means a lot of hardware choices and component makers only hiring small development teams means good value for the money. But there are definitely times when everyone drops the ball and its not clear where to go for help.
As a nit, Arm does not make chips. There are no semiconductors you can buy that contain Arm processors and are manufactured by Arm. They strictly do business around licensing their various intellectual properties (i.e. designs for processor and graphics cores) [1] and let their customer integrate that and build actual chips.
102 comments
[ 4.9 ms ] story [ 181 ms ] threadIf security is important to you, you carry an iPhone. That's a sad state of affairs, Apple has all sorts of problems and a ton of things I just find weird about the way their devices tend to do things and organize information, but it's just the only actual option right now.
The problem in this case isn't Google dragging its feet on releases. It releases Chrome updates frequently and OS updates monthly. The problem here is Google failing to include security patches for known vulnerabilities in those releases. What's ridiculous is that this is something that can be automated, and after multiple failures, it should have been automated, but here we are.
It's very obvious when something like Heartbleed comes around which affects a ton of operating systems, and Windows and iOS and major Linux distros are patched in like a week and then there's a chart to look at for which manufacturer and model and carrier on whether or not you'll see a fix in the next couple months or ever.
The real problem is patch-gapping across updates (instead of within an update), which Apple also suffers from: https://blog.theori.io/research/webkit-type-confusion/
I'd expect both Apple and Google to spend the resources to automate this problem away, but the article shows this hasn't happened.
Ever heard of NSO's Pegasus? xD
Apple's security model is about securing App Store revenue first and foremost.
Are you aware that the state of security on iPhone is even worse nowadays? At least on Android the system surface has been reduced to its minimum. In iOS, pretty much every system component depends on the OS update and nothing has been decoupled yet.
That's not an excuse of course, but a lot of the blame does lie with the Linux devs and their general disregard for security. I suspect it is a major motivation for Fuchsia.
> Learn about the details of CVE-2022-38181, a vulnerability in the Arm Mali GPU. ... the exploit that used this vulnerability to gain arbitrary kernel code execution and root on a Pixel 6 from an Android app.
Maybe the author has a stricter and more negative definition of "won't fix" so it sounded wrong to him?
You do not get to sell hardware as "100% google" AND shitcan a kernel bug. you only get to do one of those two, and you must pick and stick with it.
Turns out you totally can.
Wish that were true!
The author knows full well the GPU is not actually made by Google, he is not an ignorant consumer being duped by marketing, so the label is actually 100% accurate for people in-the-know
It's their job to support their SOC and the GPU they chose to integrate onto it.
The article explains why this isn't a safe assumption and documents numerous cases where patches were not deployed to Android devices until well after the vulnerability was publicly disclosed. https://github.blog/2023-01-23-pwning-the-all-google-phone-w...
Thus is seems obvious to me that closing the bug as "won't fix" is the wrong response. The issue shouldn't be closed until the security patch makes its way into the Android Security Bulletin.
the most recent mention on their releases page is for the 2022120300 release:
> kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro): update Mali GPU driver to r37p0 (current release is r41p0 but there are substantial changes to the driver for the Tensor SoC on Pixels and it will take substantial work to upgrade all the way)
https://grapheneos.org/releases#2022120300
from the article:
> The Arm security team were very helpful throughout and released a public patch in version r40p0 of the driver on 2022-10-07 to address the issue [...]
That's not correct. Android 13 QPR2 Beta 1 came out on December 12th. This included backports of the ARM Mali GPU driver security along with a separate update to r38p1. GrapheneOS shipped these for the kernel driver.
> the most recent mention on their releases page is for the 2022120300 release:
That's not the most recent mention on our releases page. This is the most recent relevant change:
> full 2023-01-05 security patch level
Here is a previous Mali GPU driver update:
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to QPR2 Beta 2 release
Here is another previous Mali GPU driver update:
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream)
Looking at the version number is not enough. ARM makes separate security patches available to their partners. Google is primarily shipping the backported security patches and gradually upgrades the driver version. The reason for this is that there are massive changes to the Mali GPU kernel driver for the Tensor SoC GPU. This is why GrapheneOS can't simply update it to r41p0 immediately because there are a massive number of complex synchronization, GPU command quality of service and other changes conflicting with newer releases. It makes the most sense to apply the standalone security patches. Unfortunately, ARM doesn't publish the standalone security patches for the public and we need to obtain them from a vendor choosing to include and ship them since they have to publish the code.
My confusion stemmed from the fact that the bug is supposed to affect pixel 6 devices, which aren’t listed in the QPR2 updates but were explicitly mentioned in the update to r37p0.
All of the security fixes first shipped with QPR2 Beta 1 on December 12 which we shipped on December 14th were then shipped in the AOSP / stock Pixel OS January stable release despite it still using r36p0.
The security patches are available without updating the major release, at least if you're either an ARM partner or an ARM partner has published an update with the patches and therefore released them. In our case, we can't get the standalone security patches directly from ARM but we can ship the kernel backports as soon as they're in an Android quarterly or major release beta. We can't necessarily ship the major releases of the driver just because they're in a quarterly or major release since they can depend on other changes which is what happened with the Pixel 6. It crashes without updating the userspace driver, not just the kernel driver, and updating the userspace driver seems to require other changes. It's not blocking any security patches though.
https://grapheneos.org/releases#2022121400
> kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream)
Our December 14th release was the release fixing this vulnerability and a bunch of others based on the Android 13 QPR2 Beta 1 release on December 12th which included these fixes. The January release of AOSP and the stock Pixel OS also included the security patch backports without including the update to r38p1. The update to r38p1 is nice to have since it fixes more bugs than the security bugs and has other improvements, so it's nice that we were able to ship it early but it's not really a security feature.
This isn't like the Linux kernel where there are an enormous number of changes and no serious attempt at determining which ones are security bugs. ARM does a good job determining which are security bugs and making security patches available separately. Unfortunately, ARM is not very friendly towards people building on their platform that are not partnered with them. They don't make the standalone security patches publicly available, even after a delay. It's possible they see making the patches available separately as helpful to attackers but that's a bit ridiculous because the code is available either way and it doesn't take long to identify the security patches which are one of the main things being done in the releases.
If ARM made the standalone security patches public available, we could get them to our stable channel within days of release instead of needing to wait for their partners like Google or Samsung to do their own releases and publish the patches. It would be very helpful to us if an ARM partner collaborated with us since we would be able to ship these fixes faster. The reason we can't simply upgrade to the new major releases of the driver immediately is because there are thousands of lines of changes to the kernel driver for the Tensor SoC with many invasive optimizations switching to finer grained locking across the driver, adding quality of service for GPU commands, etc. They made substantial changes to the driver and seemingly also the firmware/hardware to an extent, although likely just in between the actual GPU and the OS where they handle IOMMU, quality of service, etc. If they had a barely modified ARM Mali GPU and driver, we could easily update to each new major release in days, but that's not the case. We could do that on another device without so many changes to the driver though. It's entirely device specific. ARM provides a base for vendors to build on and how much they optimize/improve things downstream varies a lot. Google decided to do a ton of downstream optimization for the Pixel 7 GPU. They decided to focus on the GPU with that generation and let the CPU get neglected, which they'll almost certainly fix next year. Part of the initial growing pains for Tensor has been that they released the Pixel 6 with a great CPU but weak GPU and then the Pixel 7 with a great GPU but outdated CPU. These delays with Mali patches are another example, although other Android vendors almost all did worse not better.
I mean, I get it. It should not be easy to just unlock my phone and dump all my 2FA tokens. But if I want to back them up, i.e. because steam blocks my account for 7 days if I change to a new device, I want an option to get them!
Make me reboot the thing into a special state, connect it to a computer on blood moon and dance in front of the cam to authenticate myself if you must, but for fucks sake, I want to access my data.
For the specific use case you mentioned, however, I recommend Aegis with Syncthing. Very easy to set up a periodic back up and sync, encrypted at rest and on transit.
[edit: yes it does, although Steam doesn't use the standard, Aegis has special support for it]
Someone in this thread already pointed out that I'm wrong and although they don't use the standard, Steam is supported by Aegis.
For your suggestion, sadly you somehow need to get steam's otp secret first, which is held in the apps data directory. Therefore you would need root/priv-esc to get to it.
It only compromises those features because vendors refuse to build in the functionality to have full control over your purchased hardware out of the box. Make it protected behinds loads of warnings and even hidden behind a trick like what you have to do to enable developer mode, but leave it baked into the OS.
But having root in the running OS seems to be a bad idea. I got this position after an extensive talk on this with some of the graphene os developers. They explained pretty good how rooting the device would impact the security measures taken in graphene.
This is why I suggested putting the access behind a special boot mode.
I'll grant that on most phones you can't use ex. magisk with verified boot (although on ex. the Pixels I think you could? just more work), but AFAIK there's no problem with having root and selinux enforcing at the same time? Obviously it gives you the ability to bypass those protections, but overruling the usual protections is kind of the point of giving an app root, and you shouldn't give that level of access to apps you don't trust completely (like running `sudo someprogram` on a desktop).
I ended up with a new phone, decided not to root it, and found myself in a situation where I needed to get some cached data out of an app I could no longer access normally. That's easy on a rooted phone, but it's next to impossible on a locked down phone.
Lost a bunch of pictures and whatnot as a result.
There is not a great way for a phone to know whose system it is. Possession of the device doesn't necessarily mean that it is theirs.
>But if I want to back them up, i.e. because steam blocks my account for 7 days if I change to a new device, I want an option to get them!
Do you not see the irony in this? If you make it possible to switch to a new device without the 7 day lock then an attacker can bypass it too.
Edit: Thinking about it more, I suppose it all comes down to a cost/benefit analysis. It's true that taking a backup of 2FA secrets does give an attacker more than a single code. But when that trade is leveraged against the legitimate user being unable to control their own device, I think it's a terrible trade, to the point that I'm not convinced it's ever worth taking. And of course my real objection is that the user is rarely if ever actually asked; rather, a company tells the user that they can't control their own device, which is unacceptable.
Because the app aims to prove that someone has possession of the device. If someone has the key instead they can give back the device and generate codes later without possession. They can also resell the key online without having to ship a physical device. They can sell the same key to multiple people.
Of course, such an exploit could be used for more nefarious things, but as google wants to limit functionality that the phone has (that is legal where I am), I'll be patient.
Also, my personal point of view of the matter is that apps that require Safetynet, 1. doesn't care about their users, 2. Do just-for-the-show security, and thus users would be better off not using them. I personally don't use any app that require it.
But I am aware that some apps work just fine, 4/7 banking apps I've used just work on aosp. Still haven't ridden a scooter via aosp though.
1. https://calyxos.org/
The real issue is why this is still not the case in "free" countries.
[1]: https://en.wikipedia.org/wiki/Arm_(company)#Operations