I’m just waiting for linux phones to be as viable as linux on the desktop, which I already use. I’ll take whatever drawbacks come with that decision.

I don’t know why Google have allowed their bootloaders this freedom, but I can’t imagine that a company with a reputation for killing anything they touch would allow it to continue for much longer.

They’ve historically always been very pro-developers, and they know Pixels are attractive to developers as sort of the defacto successor to the Nexus line, which was aimed specifically for developer as a way to have a close to AOSP ROM.

Google’s also responsible for the entire bootloader specification, which does include provisions to provide your own keys and allow relocking the bootloader with a custom OS. So it’s quite fair that their phones implements the full spec completely. If they didn’t want people to be able to do this, they wouldn’t have written a spec that calls for people to be able to unlock and relock. They also provide ways to authorize Gapps on any device/emulator, if they didn’t want that they wouldn’t let people do that either. But ultimately most people flashing their Pixels end up still using Google services and spending money on the Play Store and other Google products.

It probably also works to their advantage because it lets people poke at the security which helps people uncover bugs in AOSP so they can fix it.

The bigger concern is more about Google abandoning the Pixel project entirely rather than closing the bootloader.

There are many phones you can unlock/relock the bootloader on. That’s not why pixels are used. https://grapheneos.org/faq#future-devices

"Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.

Devices need to be meeting the standards of the project in order to be considered as potential targets. In addition to support for installing other operating systems, standard hardware-based security features like the hardware-backed keystores, verified boot, attestation and various hardware-based exploit mitigations need to be available. Devices also need to have decent integration of IOMMUs for isolating components such as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image processor, etc., because if the hardware / firmware support is missing or broken, there’s not much that the OS can do to provide an alternative. Devices with support for alternative operating systems as an afterthought will not be considered. Devices need to have proper ongoing support for their firmware and software specific to the hardware like drivers in order to provide proper full security updates too. Devices that are end-of-life and no longer receiving these updates will not be supported.

In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.

Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware."

I think basically the higher standard of security on pixel devices allows/makes it easier to setup verified boot so you can relock the bootloader and retain that chain of trust it provides. Rather than an leave it unlocked in something like lineageOS where there is no verified boot and therefore all software isn’t coming from a trusted (verified) source.

There is no such thing as a private cellular device. It does not matter if it’s a smartphone, dumb phone, or simple internet access device.

Cellular devices are location tracked and their owners profiled. All devices have proprietary cellular modems that communicate over the network and have full access to your system. Nothing you do on device will stop that.

The only exception I’ve heard of is from Purism. The Librem 5 claims to separate the base system from the cellular modem, but that still won’t stop the location tracking.

Point blank, you can’t carry a connected cellular device, and have privacy. They are mutually exclusive goals.

So I’m hesitant to mention this, but I have been noticing similar problems trending worse and worse over the entire Android ecosystem. I love the projects that are trying to solve this, but I don’t see them gaining traction or building top notch phones with high end cameras that compete with Samsung or Apple.

So I recently decided to start trying out something else: after avoiding it like the plague, I’ve been using an iPhone 14 fairly regularly and have been pleasantly surprised by the privacy and security features. Everything seems to be implemented to give you control over what apps can do.

I’m not trying to start and Apple vs Android fight, there are many aspects I hate still, notably all their proprietary nonsense. But that aside, what’s everyone’s opinions on the privacy aspect of iPhones?

Edit: forgot to chime in on the key question: no, I don’t see Apple ever allowing custom ROMs unless it’s legally required. But I don’t see that entirely as a bad thing as long as the platform is appropriately secured and privacy friendly, which is why I’m asking this question and hoping those who know better can explain more.