> Request to Google: ungrey the “OEM unlocking” toggle in the factory, before shipping store.google.com devices to customers. Do not make your customers connect the device to the Internet before they are allowed to install the operating system they want.
That won't happen. I can think of two big reasons off the top of my head:
1. Supply-chain attacks, someone gets a hold of the phone before it gets to you and unlocks the bootloader and then proceeds to modify or install another OS.
2. Warranty reasons, very likely they want to have it phone back and send a record that it was unlocked so they can deny warranty in cases where user damaged the device through software.
3. anti-theft. AFAIK the way that anti-theft features are implemented in android is that the owner's google account information is stored on a partition that survives a wipe, but the actual enforcement of the anti-theft feature is done by the OS itself. If you flash a third party os (eg. grapheneos), you can bypass it. Having phones being "unlocked" in the warehouse or during shipment increases their value to thieves, because they can easily bypass any anti-theft features.
1. Pixel phones display an "unlocked bootloader" warning (which can't be disabled) during boot. In case it is re-locked with an additional signing key installed (Pixel-s are literally the only phones which you can do this currently in the market), a similar screen with the SHA256 hash of the public key is displayed.
2. Unlocking does not void warranty.
The only reason Google is doing this is they do not want to have two separate SKUs and pay extra cost to configure each phone physically as unlockable or not in the factory.
I don't think the average user would understand what "unlocked bootloader" means, and may even mistake it for a feature or enhancement.
It is a supply chain risk. The Android & Pixel teams walk a fine line here: they risk upsetting an important (but small) user group if they change the language and defaults to "THE BOOTLOADER IS UNLOCKED: USE AT YOUR OWN RISK" or even stronger language and shipping these devices to end users.
The unlocked bootloader warning screen isn't very different from what you described [1]. It says:
> The bootloader is unlocked and software integrity cannot be guaranteed. Any data stored on the device may be available to attackers. Do not store any sensitive data on the device. Visit this link on another device: g.co/ABH
It's already pretty strong language (and very accurate! which is a rare combination).
That's actually not exclusive to Pixel phones. The custom signing key part probably is, just because no other phone allows you to lock the bootloader with a custom key. But the "bootloader is unlocked" screen is built into AOSP
> 1. Pixel phones display an "unlocked bootloader" warning (which can't be disabled)
Yet. Other manufacturers have the same warning and have had them disabled. (I did it to one of my older moto phones a few years back)
> 2. Unlocking does not void warranty.
Not by itself, but having a signal in place that it was unlocked lets the manufacturer look for common problems caused by doing things like flashing the wrong device images to critical partitions (go search around a bit for people corrupting EFS on their phones).
Critically Pixel devices do not have a debrick tool that's leaked, at least not for the Qualcomm-based Pixel devices. This means that a brick on any of those partitions means the phone needs a trip back to the depot or a service center that has these tools. Can't be fixed by end-user. Maybe this situation has changed for the Tensor/Samsung pixels but the point is screwing up your device due to flashing incorrect images shouldn't be something the manufacturer needs to foot the bill on.
> Maybe this situation has changed for the Tensor/Samsung pixels but the point is screwing up your device due to flashing incorrect images shouldn't be something the manufacturer needs to foot the bill on.
Then maybe the manufacturers should be more forthcoming with making said tools available to the public, such that they don't have to foot the bill for said mistakes to be corrected.
> someone gets a hold of the phone before it gets to you and unlocks the bootloader and then proceeds to modify or install another OS
Doesn't the splash screen clearly show some scary warning when the phone was unkocked?
> very likely they want to have it phone back and send a record that it was unlocked so they can deny warranty in cases where user damaged the device through software
It definitely does. Anytime you reboot under graphene you see what looks like an error message with a web address to visit for several seconds from the phone, before the OS loads.
You don't have access to the data that's sent to Google when you connect the phone to the internet, so how does that help you mitigate or at least be aware of a supply-chain attack?
Conversely, if you got a brand new phone, the bootloader is supposed to be locked, so wouldn't you immediately be aware of tampering if it wasn't?
I swear it's been a clause in their phones since they were called Nexus instead of Pixel where you breach the warranty when you unlock the bootloader. I never bother anymore but when I used to swap the Android versions myself I recall running into something saying as much.
> breach the warranty when you unlock the bootloader
Under the Magnuson-Moss Warranty Act in the USA, activities such as unlocking the bootloader, launching a service menu, removing a sticker or opening a case cannot by themselves void a device's warranty.
If I understand correctly, in order for the warranty to be voided, it is the manufacturer who has to prove that what you did to the device has indeed damaged it or made it otherwise unsuitable for further warranty service.
Unlocking the bootloader is a reversible action. The phone might implement some one-way unlocking mechanisms though. For example, a fuse which needs to be blown. Or some encryption chip whose private key needs to be erased while a new valid private key can only be generated by the manufacturer. Then it would be a process that is irreversible for a regular customer.
That being said, undertaking such activity would only result in some control mechanism being triggered and some software flag being set. It might be permanent, similar to you scratching the case of your phone. But that does not mean it makes the phone unfit for warranty service.
The phone's functionality would remain unaffected.
It would be on the manufacturer to prove that the presence of a flag indicating an open bootloader is in some way detrimental to the device's functionality.
2 is probably not legal. The onus is on a manufacturer to prove that the customer's changes caused damage sufficient to negate their warranty responsibilities.
When you buy a new car they have the VIN of the car and log any recall repairs done. So not sure how you think the same wouldn't be legal on a phone?
Having a device in their database as NEVER_UNLOCKED takes away any onus from having to look for this in the first place for a large % of users.
Additionally this is kind of important for a company that's had a history of selling devices with hardware defects. It'd be very useful for them to know the RMA rate and whether damage was caused by such a defect or whether it was from a 3rd party software issue.
The PinePhone can boot from an SD even if the eMMC install isn't working, so it kinda fits the description. You can either run an OS from the SD or boot an image to fix/reinstall on the eMMC.
Maybe not a great example. The PinePhone relies on software to manage its battery charging parameters. Thermal limits are controlled entirely in software and sent to the PMIC by the kernel, if this isn't done correctly or at all it's not just possible to have a brick, but a flaming brick. Another post on the matter: https://xnux.eu/log/#017
While this is absolutely true, and it should never have been implemented this way, I have been following the topic very closely and have not come across a single report of a flaming PinePhone in over three years. With five-digit numbers of PinePhone's out there in the hands of people who don't know what they are doing, this IMHO thus is fortunately mostly a theoretical issue.
BTW: PINE64 did better on the PinePhone Pro, and (since it's also going to be Rockchip (RK3566) based in all likelihood) is unlikely to replicate the mistake on the PinePhone 2.
It's pretty common. Apple Silicon devices (at least) have a BootROM feature to pull a signed boot image over USB which can be used to provision the device from a blank flash.
Why would I cite a court case here? I just cited a very common scenario in a better regulated industry. If you have concerns over legality, why don't you cite some law or examples that illustrate why you think this wouldn't be legal?
Collecting that data is about not wasting time looking for issues caused by unlocking and not grouping unlocked device issues in with locked device issues.
As usual, security is used as an excuse to lock down more than is necessary. To prevent the supply chain attack you mention, the boot lock just has to be tamper evident, such as showing a "Bootloader unlocked" message during boot. As is already the case in some phones. Additionally, a way to reset to a factory-verified state could undo such an attack.
Warranty could also easily be achieved by flipping a non-reversible bit that the phone was unlocked at least once. Though even if it couldn't, warranty troubles are not a justification for user-hostile behavior. If it were, they'd use it for all sorts of invasive logging/spying with the excuse they have to know if you used your phone in a way not covered by warranty.
Pixel's are locked down a very tiny bit, and I don't think this is some kind of dystopian over-reach with security as an excuse. For all the security listed in this thread the whole "I must connect to the internet once" problem is a very fair tradeoff from the user's perspective.
This would only be a problem not when you first buy the phone but only if you buy a very very old used phone that has never had the OS replaced and google has exited the phone business and if you wanted to replace the OS.
One of the problems with this is that Google can change the behavior at any time. We have no shortage of examples of big tech companies changing something that's valuable to users because it no longer aligned with their business goals.
The internet is not a thing you connect to, what you must actually do is register your intent to disable the bootloader with an adversarially controlled server, and that server must respond with a yes.
If the root comment is to be believed, this (connecting via the internet to Google's servers), is required to provide additional security. I'm just taking that as true and deciding that connecting to the provider of my phone's hardware and software _once_ as a purchaser of their hardware, is fine for me. I also imagine it's not too burdensome for others.
Scenarios in which that's not possible are hypothetical (disaster, totalitarian takeover, alien invasion, sudden policy change), and I'm fine calculating that into the risk calculus and deciding that, yep I don't mind driving home and unlocking it the same day I bought it and praying nothing changes in their policy during the drive.
That's basically what I did. We can disagree on this, but it has worked out OK so far.
In return for this feature a class of lower income users are able to buy hundreds of millions of phones and pay for them over an extended period using monthly payments on their phone account. This is the trade-off Google makes.
That won't happen. I can think of two big reasons off the top of my head:
1. Supply-chain attacks, someone gets a hold of the phone before it gets to you and unlocks the bootloader and then proceeds to modify or install another OS.
2. Warranty reasons, very likely they want to have it phone back and send a record that it was unlocked so they can deny warranty in cases where user damaged the device through software.