[dtx1]

In newer pixel models, everything is glued together. The Backplate is glued to the front, the battery is glued in so hard you can barely remove it and on top of it there's a graphene pad glued ontop of it for cooling reasons.

Look at this: https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem...

That's not "swiss knife" replacement.

[wafflemaker]

Wow. I genuinely thought that the replacement process was maybe a little more complicated than on the Samsung Note from 8 years ago that I did myself. That if you just ripped out the backplate you could have an ugly phone (not water resistant either) with a replacable battery. This complicated, time consuming and requiring specialized equipment process is not what I expected. Especially the part where you have to replace the screen you've just broken.

Now I concur with the original poster in his lament on lack of new and fancy, yet fully owned by the user, phones that can cooperate with Graphene OS

[strcat]

> GOS's limited device support is disappointing, but I understand their reasoning. Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking.

> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.

It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).

Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.