As someone not swimming in piles of cash, I can't bring myself to get a framework laptop. Ironically enough, new ThinkPads, which are on sale pretty regularly, end up being much nicer, solidly built, more performant, and with an awesome warranty, even in my shithole region.
Elaborate please. PI on its own is just an insurance API for banking and similar apps to ensure that they can do secure compute on the device. It can also be used to check if the device that the app is running on is a genuine Android device, since no VMs or custom ROMs can pass hardware integrity.
Very old, unpatched and rooted devices can fairly easily pass device integrity check.
It primarily assures the software vendor that the phone is running Google buttplug in the privileged mode.
Remember, handsets running on ANCIENT versions of Android with no patches for years. Whilst seems to be important to raise under the Forbes article (rightly) fussing about a couple of zero-days.
"Custom roms" (whatever that means) can easily spoof the checks in the specific situation (mainly hardware that allows for several things).
What sense is does it make to certify an insecure device that may be subject to all kinds of remote exploits and elevated code execution as 'unmodified'. The argument of the banks is: the device is insecure (even with the latest patches). We all know the whole compliance is a bit more complex, so it might make sense on that level...
> It's quite surreal how unsafe the standard Android
Well that's untrue. I'd even venture to say that with how many OEMs there are it's insane how safe Android is. Google for one updates their devices for 7 years since Pixel 6, they can't control OEMs who might have ~10 people working on their devices.
If I don't misunderstand you, you're suggesting the Pixel 8 line is shown red/discontinued? If that's it, you're probably on a mobile browser which might cut off right after the Discontinued column. The table goes on next to that where you'll see that all Pixels since 6 are currently still supported.
You misunderstood. He’s saying that Google provides 7 years of device updates only for the Pixel 8 and later. That’s true: Pixel 6 and Pixel 7 only get 5 years of updates.
I replied to a poster who said the seven years of updates began with the Pixel 6 with "Pixel 8" and a link which showed when support expires on these devices, because... it began with the Pixel 8, not 6.
Yep. And GrapheneOS's changes to the kernels of devices they ship are laughably small, 20-30 commits at most. I don't think they even do any basic CVE checks on any of the source code.
Fuzzing, actual security analysis - all those things are done by Google.
Their contributions upstream go way back, I think someone could misread this comment that they've not contributed, and that would be an unfortunate misunderstanding.
GrapheneOS has made substantial upstream contributions to the Linux kernel and Pixel drivers including vulnerability reports. Many of our kernel changes are for the out-of-tree drivers needed for Pixels which are in a separate repository from the Generic Kernel Image code from the upstream Linux kernel. We make important downstream changes including enabling many more of the upstream security features and adding important protections not yet available there. We worked with multiple upstream Linux kernel developers to get many of the changes we used to have upstream and therefore no longer need them. We have major kernel security improvements in development including more security-focused integration of hardware memory tagging, but indefinitely maintaining those downstream is not the way we try to do things.
We use much newer Generic Kernel Images than the stock Pixel OS as the base. Android 16 QPR2 was released this month and they finally shipped 6.1.145 from July 2025 for the Pixel 6 through Pixel 9 compared to us being on 6.1.158 which was the latest until yesterday (6.1.159) which will be incorporated soon. It's similar for our 6.6 and 6.12 branches compared to theirs. 6.6 is the current Pixel 10 and near future Pixel 6 through Pixel 9 branch. They only update the kernel revision every 3 months in quarterly/yearly releases so this is the smallest the delay gets right after a quarterly release. They'll still be on 6.1.145 until the next major release in March 2026 so the current delay of having the July 2025 kernel in December 2025 is not representative but rather is the small side of the delay. Shipping the newer LTS revisions is not easy due to frequent regressions both in the upstream code and to a much lesser extent in the out-of-tree drivers needed for Pixels which often need small changes to adapt them to the new LTS revisions.
GrapheneOS does a lot of deep security analysis and has proposed firmware, kernel and userspace exploit protections adopted by Google. We helped them get a bunch of vulnerabilities being exploited in the wild blocked off as whole classes of vulnerabilities including perf events, reset attacks on fastboot mode and much more. GrapheneOS is focused on addressing classes of vulnerabilities rather than individual bugs. Google puts a decent amount of resources into finding and fixing individual bugs and that isn't our focus. We get the bug fixes from the upstream project many months earlier and the Pixel driver fixes from them other than cases we fix them early due to finding them with hardware memory tagging which they don't use for the kernel even in Advanced Protection mode (or most of the base OS processes either, while we always use it for both with a much better implementation in userspace).
Most of our changes are in userspace where we don't try to collaborate with upstream developers as much as we do with the Linux kernel. Most of userspace is not developed as openly in a way we can properly collaborate.
Google most likely reimplemented AWDL, and the article is wrong. Sure the EU's actions will affect the optics, but Apple will be in the clear if they decide to nuke this.
reply