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.

I think Google knows that many people use their phones for that reason, and i don’t see a monetisabil reason why they shouldn’t allow it, they buy it, Google makes money, they give the people freedom to do what they want with it.

I don’t think Google taking away their usp will happen and if they probably die, their phones aren’t the best from a technical perspective and people will just find a new brand that doesn’t fuck up the bootloader.

GrapheneOS was collaborating with some phone manufacturer for a while, looks like it didn’t work out but they’re trying different options.

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.

As much as I wish something like the PinePhone would be a decent substitute, here’s the problem.

Not enough people harden their Linux systems as it is. Mostly because people don’t know how.

And now we’re expecting consumers to know how to harden a Linux phone, out of the box?

Unless these start shipping with privacy-respecting settings defaulted to by the manufacturer, these will be far less secure than a Pixel.