[HN Gopher] Pixel phones are sold with bootloader unlocking disa...
___________________________________________________________________
Pixel phones are sold with bootloader unlocking disabled
Author : pabs3
Score : 249 points
Date : 2023-05-07 15:00 UTC (7 hours ago)
(HTM) web link (www.fitzsim.org)
(TXT) w3m dump (www.fitzsim.org)
| azalemeth wrote:
| If I wanted to buy a new phone that I could root, install a
| custom ROM on, and use without voiding the warranty, what's the
| current best bet? One Plus used to be pretty good, but they've
| gone down in freedoms and up in price. Samsung are an obvious no.
| The entire design of the iPhone is specifically aimed at keeping
| the user out of it. Linux phones aren't usable yet. The shop on
| the /e/ foundation website seems to be selling flashed Samsung
| devices.
|
| Is there an alternative?
| the_pwner224 wrote:
| Pixel and 1+ are the options. 1+ cripples the camera on non-
| official ROMs, so Pixel is better. Both of them have this
| unlocking system - when you get a new phone, you have to
| connect it to the internet (and nothing else - just connect it
| to the internet), and within a few minutes the bootloader will
| automatically become unlockable and stay unlockable forever.
| pbasista wrote:
| > connect the device to the Internet before they are allowed to
| install the operating system they want
|
| Phoning home before undertaking such an activity takes away the
| ownership rights from the customers. They do not actually own
| these devices even after they have purchased them.
|
| The reason is that an important part of their ownership rights,
| i.e. the freedom to use the software of their choice, has been
| withheld from them. With a _promise_ that it will be given to
| them on request. Unless, of course, the manufacturer changes
| their mind.
|
| Unfortunately, there are cases when the manufacturer did not even
| make such a promise and disabled bootloader unlocking permanently
| with no way of enabling it again. On Pixel phones.
|
| This used to happen (and perhaps still happens) to some Pixel
| phones purchased in the USA from Verizon. They have been known
| [0] for disabling the bootloader unlocking and for giving their
| customers no way to enable it. Not even after phoning home.
|
| Some people claim [1] that they paid someone from China to unlock
| their Pixel 1 phone remotely using some shady approach. I assume
| that someone with inside information from Google has leaked some
| software and instructions for doing so. It is unclear whether
| later Pixel phones sold by Verizon with locked bootloaders could
| be unlocked in a similar way.
|
| As a result, it seems like the only way to have a chance at
| unlocking such Pixel phones, which have been made by a US company
| and purchased from a US carrier, is to pay someone in China and
| hope for the best. It has gotten that far.
|
| [0] https://forum.xda-developers.com/t/how-to-unlock-
| bootloader-... [1] https://forum.xda-developers.com/t/how-to-
| unlock-bootloader-...
| [deleted]
| bitL wrote:
| Can Pi Hole block these "phoning home" attempts?
| bdcravens wrote:
| I assume the device isn't just phoning home, but is expecting
| some sort of response, and likely isn't static.
| bitL wrote:
| So I guess one should activate the phone at some Wifi
| caffee first before unlocking bootloader and flashing a new
| OS otherwise Google could make a direct link to ownership
| during the lifetime of the device.
| ls65536 wrote:
| > With a promise that it will be given to them on request.
| Unless, of course, the manufacturer changes their mind.
|
| Or if the manufacturer decides to simply shut down those
| servers after some time, at which point the effective default
| situation will almost certainly be a denied request. In this
| case, they may not necessarily even be actively changing their
| mind, but rather just trying to reduce some overhead for those
| devices they deem to be "no longer supported" but which are
| nevertheless still out there being used.
| userbinator wrote:
| _As a result, it seems like the only way to have a chance at
| unlocking such Pixel phones, which have been made by a US
| company and purchased from a US carrier, is to pay someone in
| China and hope for the best. It has gotten that far._
|
| That reminds me of the right-to-repair article about patched
| John Deere firmware created by Ukrainian hackers.
|
| It wouldn't surprise me that China has the same skills. I
| remember coming across a lot of products made to unlock/unbrick
| Apple's products too, although that was many years ago and I'm
| not sure if they've gotten through Apple's security for the
| newer models yet --- and it wouldn't surprise me if they knew
| but won't easily disclose.
| xg15 wrote:
| > _Phoning home before undertaking such an activity takes away
| the ownership rights from the customers. They do not actually
| own these devices even after they have purchased them._
|
| Is this just philosophically speaking or were there some actual
| rights granted by law being violated?
| bombcar wrote:
| > Some people claim [1] that they paid someone from China to
| unlock their Pixel 1 phone remotely using some shady approach.
| I assume that someone with inside information from Google has
| leaked some software and instructions for doing so. It is
| unclear whether later Pixel phones sold by Verizon with locked
| bootloaders could be unlocked in a similar way.
|
| This usually involves someone who has bribed a Verizon support
| rep or otherwise obtained access to their internal systems so
| they can "unlock" you.
| j1elo wrote:
| Xiaomi does the same (or at least did until my latest phone
| change i.e. around 3 years ago). You must unlock the bootloader
| before being able to install a custom recovery image such as
| TWRP, which itself is used to install custom ROMs.
|
| This unlock involves: creating a user account in the Xiaomi
| services website, logging into that account from your phone's
| system, then _having the phone logged in for at least 7 days_ ,
| then using a Windows software which sends a request for
| unlocking, which they will grant (at least in my experience).
|
| The most outrageous part of all this process (apart from the
| fact that it exists at all) is the 7 days of usage with the
| phone logged in. If you attempt an unlock earlier than that,
| the software will say: "You have to wait X days and Y hours
| before you can unlock this device."
|
| EDIT: This Reddit wiki page explains the process. I'm
| flabbergasted that it actually takes _720 hours_ aka 30 days:
|
| https://www.reddit.com/r/Xiaomi/wiki/bootloader/
| solarkraft wrote:
| The wait time differs based on the device. I had to wait a
| week until I could use my Pocophone F1.
| tpm wrote:
| Luckily there are reputable companies (warranty and all that)
| that do this as a part of the purchase process.
| RicoElectrico wrote:
| The rationale for the hoops and waiting period is IIRC that
| shady sellers were tampering with phones sold through
| AliExpress etc.
| WeylandYutani wrote:
| Xiaomi heavily subsidizes their phones. The idea is that they
| make it back with people using their apps.
| grishka wrote:
| Yep. All their stock apps, including those that have no
| business having any kind of network access as part of their
| functionality, come with a privacy policy, show it to you
| in a modal on first launch, and quit if you decline it. The
| calculator app has a privacy policy, so does the clock, the
| media gallery, the file manager, and the local music
| player. I was also told that there are actual ads sprinkled
| throughout the system.
|
| I'm highly doubtful that it's possible to sell a phone for
| the equivalent of $100 at a profit.
| mschuster91 wrote:
| Samsung does the same fwiw for their newest phones. Pretty
| annoying.
| jesprenj wrote:
| You don't need an account, but it's still terrible. I
| experienced this yesterday:
| https://news.ycombinator.com/item?id=35854287
| dingledork69 wrote:
| So google is going through all this effort and some guy in
| China will just bypass the bootloader lock for $30.
|
| There is absolutely no way that the intelligence agencies don't
| have this same capability, which makes all of this security
| posturing utterly pointless, other than to prevent regular
| users from owning their devices.
| shmichael wrote:
| That's exactly the purpose of this measure - to prevent
| consumers from fully owning their device. Presumably the
| carriers are selling you the device at some discount for
| longer term loyalty (through constraining the phone). This is
| not a security measure and government agencies being able to
| bypass it seems irrelevant.
| dingledork69 wrote:
| You are confusing Verizon's motives with Google's motives.
| Verizon disabling the bootloader on phones that users are
| still paying off, or bought at a discount together with
| special terms of condition, is something that might be
| defensible.
|
| Google however made it so that _any_ Pixel phone bought
| _anywhere_ , even by customers who pay 100% of the price
| themselves with no carrier involved are not actually owned
| by those users until they connect it to the internet and
| Google blesses the device.
| amw wrote:
| > is something that might be defensible.
|
| I would like to propose that it never is, and only seems
| so sometimes because our society is insane.
| damisanet wrote:
| "Magic hostname" mentioned in article (afwprovisioning-
| pa.googleapis.com) makes me believe this may be related to zero-
| touch enrollment of Android Enterprise/Android for Work
| (https://support.google.com/work/android/answer/7514005). I'm
| sure devices sold to regular customers and enterprises are
| identical and nobody is going to unbox and pre-provision them
| before shipment, so unboxed phone needs to contact provisioning
| server at least once to verify that there is no pending zero-
| touch enrollment configuration prepared for it (which may prevent
| bootloader unlocking if device is enterprise-owned).
| IshKebab wrote:
| Yes this is obviously the reason they do it. They don't want to
| have to flash different firmware for carriers, consumers,
| enterprises, etc. I think it's kind of reasonable.
| dingledork69 wrote:
| That just sounds like "you don't get to own your device"
| mlyle wrote:
| You get to "own your device" after you connect it to the
| internet once, to make sure it's not pre-provisioned for
| enterprise use.
| MereInterest wrote:
| If the servers are running. If the servers deign to give
| permission to own the device you purchased. If they
| correctly recognize that this device is owned by the user.
| After I've purchased the device, the seller has no right to
| withhold ownership, and the existence of enterprise devices
| doesn't change that in the slightest.
| Dylan16807 wrote:
| If the process doesn't work then return it as defective.
|
| Transfer of control isn't happening exactly at sale time
| but a few hours later isn't a big deal.
|
| Though of course that depends on it staying unlocked.
| dingledork69 wrote:
| And it depends on the user being willing to connect it to
| the (public) internet without a firewall in between.
|
| I wonder if any of the countries that implement a
| country-wide firewall block this domain. That would
| disable bootloader unlocking for the entire country.
| kortilla wrote:
| This is incorrect. Have you considered that the delay
| between getting the device and getting it connected could
| be well outside of the return window or people could be
| purchasing them in countries without such consumer
| rights?
|
| Smartphones aren't only for the developed world.
| Dylan16807 wrote:
| Who buys a brand new phone but also has no internet
| connection for weeks? Do they have all the apps they need
| pre-downloaded? I don't think that's a big group.
| KennyBlanken wrote:
| It's quite common for people from elsewhere in the world
| to buy electronics in the US, Europe, Japan, etc and then
| bring them back to their home countries for a fraction of
| the cost of what the official or unofficial importer(s)
| want. That's why you end up with all sorts of region-
| locking nonsense, companies trying to protect their
| importers who have a monopoly on distribution of a
| particular device.
| dingledork69 wrote:
| So you don't own it when you buy it. At best Google still
| owns it and they graciously allow you permission to change
| the bootloader after you submit to their terms of service.
| Also, better hope their servers are online and reachable,
| and that you have functional internet.
| leni536 wrote:
| The best you can do is to consider it as part of the
| transaction of buying the device. If it fails for
| whatever reason, return the device.
| LiamPowell wrote:
| This is correct, people generally don't get to own a device
| provided by their employer. Not allowing the bootloader to be
| unlocked on company-owned devices seems like a very desirable
| feature.
| dingledork69 wrote:
| Even if you buy it yourself you don't get to own it before
| having google bless your device, which you can only hope
| they will.
| fkarg wrote:
| except that their employer[0] doesn't own it either
|
| [0] except for the employer being google in this case
| MereInterest wrote:
| Not allowing a bootloader to be unlocked on a company-owned
| device does sound like a desirable feature, but only for
| company-owned devices. Applying that setup to all phones
| assumes that the default phone is a company-owned device
| and is subject to external control.
| tapoxi wrote:
| It assumes that company owned and managed phones are more
| common than people who want to unlock the bootloader. I
| know this isn't ideal, but that's the correct assumption
| to make.
| kortilla wrote:
| That's a stupid false dichotomy caused by a poor
| onboarding workflow. "Well we either make it easier for
| businesses or deny the right to literally every customer
| to own their device. It's okay because most people won't
| notice."
| judge2020 wrote:
| A different SKU for enterprise managed devices would
| cripple IT departments that don't pay the big bucks to
| e.g. verizon to manage their device provisioning & MDM
| enrollment.
| KennyBlanken wrote:
| Has it occurred to you that the feature you're defending
| allows Google to lock customers into their
| provisioning/MDM? That this is worse than Verizon
| controlling provisioning/MDM, because at least Verizon is
| subject to market competition (ie you can buy the device
| from other parties), whereas Google doing it means you
| have no choice whatsoever?
|
| You're also grossly exaggerating things. We're not
| talking about a change that would prohibit management,
| just one that would not allow them to do zero-touch
| enrollment into their management systems.
| KennyBlanken wrote:
| But the provisioning check is forced on everyone.
|
| I don't think it's reasonable to enforce a provisioning
| process on every single person just because a small number
| of the devices go to enterprise-sized companies that want
| "zero touch" and Google (and their distributors) don't want
| the expense of stocking two SKUs, one set to require
| provisioning, and another not.
|
| I shouldn't have to prove ownership of my device to said
| device straight out of the box.
|
| A company should not have the ability to render millions of
| devices useless because they purposefully or accidentally
| shut off a provisioning service
|
| All this bullshit is so that Google and their enterprise
| customers save a few dollars.
| [deleted]
| Wowfunhappy wrote:
| Do you need to actively be connected to the internet while
| enabling bootloader unlocking, or does the phone merely need to
| have connected to the internet once at some point?
|
| The latter seems reasonable to me in light of your point about
| enterprise enrollment. However, I'm confused by nelblu's post
| downthread[1], which describes using wifi to unlock _used_
| phones.
|
| [1] https://news.ycombinator.com/item?id=35853135
| damisanet wrote:
| According to "Locking/Unlocking the Bootloader" docs (https:/
| /source.android.com/docs/core/architecture/bootloader...),
| "(...) the user needs to boot to the home screen, open the
| Settings > System > Developer options menu and enable the OEM
| unlocking option (...). After setting, this mode persists
| across reboots and factory data resets.".
|
| My guess would be that if OEM unlocking stays disabled, phone
| reverts to "greyed-out" setting after each factory reset
| (yeah, that would be an issue if Google suddenly decides to
| send Android to graveyard...). I believe actual bootloader
| unlocking happens inside fastboot mode, outside regular OS
| and without access to WiFi/cellular data - enabling OEM
| unlocking is only a prerequisite to actual unlock.
| chenxiaolong wrote:
| In case anyone is curious which Android components are
| responsible for this:
|
| * There are 3 boolean states: 1. whether the
| bootloader is unlocked 2. whether the bootloader
| unlocking ability is enabled by the user ("OEM unlocking" toggle)
| 3. whether the bootloader unlocking ability is allowed to be
| enabled (carrier restriction)
|
| * The Android Settings app grays out the "OEM unlocking" toggle
| if `isOemUnlockAllowedByCarrier()` returns false [1].
|
| * The state of `isOemUnlockAllowedByCarrier()` is changed by a
| call to `setOemUnlockAllowedByCarrier(boolean allowed, @Nullable
| byte[] signature)`, which is done by the
| `android.apps.work.oobconfig` package (/product/priv-app/OTAConfi
| gNoZeroTouchPrebuilt/OTAConfigNoZeroTouchPrebuilt.apk) on the
| Pixel's stock firmware. This is the same package that handles the
| Android Enterprise zero-touch provisioning. It's not obfuscated
| and can be trivially reverse engineered. Prior to the December
| 2022 update, it was actually possible to bypass the check just by
| disabling this package via `pm` [2]. This is now blocked both by
| [3] and also the bootloader's requirement of a signed blob to
| lift the carrier restriction. This package is also responsible
| for preventing the removal of the carrier restriction (for the
| bootloader) when the SIM is locked.
|
| * The Android framework talks to `android.apps.work.oobconfig` at
| all because the stock firmware ships an overlay
| (/product/overlay/framework-res__auto_generated_rro_product.apk)
| that contains `<string name="config_deviceProvisioningPackage">co
| m.google.android.apps.work.oobconfig</string>`.
|
| * The communication with the bootloader is done via the `oemlock`
| HAL: /vendor/lib64/android.hardware.oemlock@1.0-impl.nos.so. Its
| implementation of `setOemUnlockAllowedByCarrier()` seems to
| require a signed blob from Google (passed in from
| `android.apps.work.oobconfig`) before the state of the setting
| can be changed (see: `carrierUnlockFromSignature()`). Once
| unlocking is allowed, the setting is persisted by the bootloader
| unless something calls `setOemUnlockAllowedByCarrier()` again to
| disable it. Without the carrier restriction, the bootloader
| allows the user to freely toggle the "OEM unlocking" state.
|
| I don't know for sure since I haven't tested, but I believe even
| SIM-unlocked Pixels purchased from the Google Store use this
| "carrier" restriction mechanism. It's just that when the device
| asks Google's servers for the signed blob to lift the carrier
| restriction, it's always granted. (EDIT: Though there are reports
| that refurbished devices from warranty claims for bootloader-
| unlockable devices may sometimes have a carrier restriction that
| Google's servers don't allow removing.)
|
| [1]
| https://cs.android.com/android/platform/superproject/+/andro...
|
| [2] https://nvd.nist.gov/vuln/detail/CVE-2022-20611
|
| [3]
| https://android.googlesource.com/platform/frameworks/base/+/...
| plorg wrote:
| The title of the article is misleading. The author says the phone
| cannot be bootloader unlocked without first connecting to the
| Internet. Once they have connected they are able to unlock the
| bootloader.
| jkaplowitz wrote:
| Possibly misleading indeed, but not wrong: the state that the
| phone is in at the moment ownership of the phone changes from
| Google to the customer has bootloader unlocking disabled.
| quadrangle wrote:
| The title is precisely correct, but it is easy to infer wrongly
| "and you can't enable it".
| p1mrx wrote:
| The title actually is accurate for the Pixel 2. There are a
| bunch of those that nobody ever figured out how to unlock:
|
| https://jacobhall.net/2022/01/29/000177/
|
| https://support.google.com/pixelphone/thread/14920605/google...
| croes wrote:
| [flagged]
| jffry wrote:
| The _very_ next text in the article after what you quoted
| (following the image) is:
|
| > I consider this a customer-hostile practice. I should not
| have to connect a piece of hardware to the Internet, even
| once, to use all of its features. If I hadn't connected the
| Pixel 7 Pro to the Internet, then "OEM unlocking" would have
| stayed greyed out, thus I would not have been able to unlock
| the bootloader, thus I would not have been able to install
| GrapheneOS
|
| The author then describes connecting the phone to a
| networking sandbox and monitoring its traffic, all the way
| through where they were eventually able to unlock it after
| giving it internet access.
| stavros wrote:
| Have you read that part?
|
| > If I hadn't connected the Pixel 7 Pro to the Internet, then
| "OEM unlocking" would have stayed greyed out, thus I would
| not have been able to unlock the bootloader, thus I would not
| have been able to install GrapheneOS.
| sowbug wrote:
| _> Have you read that part?_
|
| _> >Google sold it to me with "OEM unlocking" greyed out._
|
| _> So no unlocking even with internet access._
|
| Reading the whole article reveals that the option is enabled
| after providing internet access.
| croes wrote:
| Overread that, my bad.
| nelblu wrote:
| Yup, I am quite annoyed too with this practice. I have had 3
| pixel phones and first thing i do is to unlock and flash calyxos
| or graphene. Since I always purchase used phones only, I just
| make it a practice to buy them in cash and unlock at a public
| WiFi.
| glenstein wrote:
| I just got myself an old used Pixel phone as a daily driver,
| and I intend someday to flash it with a lineageOS. It already
| was somewhat tricky for me, at my skill level, to successfully
| do this on "ordinary" devices (Nexus 7 and Pixel C tablet), and
| it seems like getting the Pixel to truly unlock is going to be
| an added layer of complexity.
| ewoodrich wrote:
| Not sure if there is an equivalent for LineageOS but
| GrapheneOS offers an almost completely automated flashing
| process in Chrome via WebUSB and gives instructions for the
| actions you need to take on the phone itself when necessary
| throughout the process (on my Pixel 4a I just needed to press
| volume up and power to unlock the bootloader when prompted by
| the installer).
|
| The whole process was amazingly easy when I did it and took
| less than 15 minutes.
| 1vuio0pswjnm7 wrote:
| "Here is the rest of the network activity, all of which is TLS-
| encrypted by keys buried in the stock Google operating system,
| and thus not controlled by the device purchaser:
| Hostname Downloaded to phone Uploaded from phone
| storage.googleapis.com 383 MiB 8 MiB fonts.gstatic.com 137
| MiB 3 MiB afwprovisioning-pa.googleapis.com 18 MiB 1 MiB
| www.gstatic.com 8 MiB 287 kiB
| googlehosted.l.googleusercontent.com 8 MiB 345 kiB ota-
| cache1.googlezip.net 3 MiB 175 kiB dl.google.com 3 MiB 86
| kiB instantmessaging-pa.googleapis.com 1 MiB 300 kiB
| www.google.com 46 kiB 24 kiB ssl.gstatic.com 25 kiB 3 kiB
| ota.googlezip.net 17 kiB 6 kiB
| digitalassetlinks.googleapis.com 17 kiB 4 kiB
| clients.l.google.com 14 kiB 7 kiB gstatic.com 13 kiB 3 kiB
| mobile-gtalk.l.google.com 8 kiB 1 kiB mobile.l.google.com
| 5 kiB 1 kiB lpa.ds.gsma.com 5 kiB 4 kiB
| connectivitycheck.gstatic.com 3 kiB 3 kiB app-
| measurement.com 1 kiB 0 bytes time.android.com 180 bytes
| 180 bytes
|
| Only Google knows precisely what all that data is and what it is
| used for."
|
| Why should the owner of the computer be allowed to see what is
| being sent to Google? (Maybe the strange folks at Google cannot
| think of any reasons.)
|
| Who pays for transport of the data to Google? (Is there any
| reason Google should not pay?)
|
| Putting the data sent aside, there is the question of whether the
| computer owner should have a _choice_ in whether they want to
| send it, and there is the fact that these unauthorised
| connections are all pings to the mothership.
|
| Using NetGuard, it's possible to block all these connections
| without rooting or installing GrapheneOS. It's also possible to
| log all the DNS lookups and attempted connections, without
| rooting or installing GrapheneOS. The log will indicate which
| software is making the connection attempts. One can also create
| PCAP files showing the patterns of network activity, again
| without rooting or installing GrapheneOS. It's relatively easy to
| determine what connections are actually necessary for the
| computer to work as desired.
|
| After installing GrapheneOS, I wonder if it is possible to
| selectively stop connections to GrapheneOS servers. There are
| probably some connections to Graphene server enabled by default.
|
| Would be fun to compare PCAP files from a device running NetGuard
| versus one running GrapheneOS.
| jacooper wrote:
| Honestly be glad that google still allows bootloader unlocking.
| And the WiFi requirement is very small, and the article is
| overblowing it.
| JeremyNT wrote:
| Yeah, the state of affairs with Google is better than any other
| mainstream vendor.
|
| It seems lame that you have to phone home to unlock a new
| device, but it's nothing compared to what they _could_ be
| doing.
| Ch4otic wrote:
| For all we know it's just Google activating the device to
| ensure it wasn't stolen and reflashed with another OS. Apple
| requires a device to be activated before it's usable.
| nimbius wrote:
| I got sick of this malarkey years ago with HTC.
|
| Oneplus phones just unlock when told 'OEM unlock' over the adb.
| No big brother home to phone, no bullshit begging for the rights
| to my device. If I decide to unlock it the worst I get is a
| nagscreen at boot with a scary warning about security.
| joecool1029 wrote:
| > 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.
| gruez wrote:
| 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.
| rfoo wrote:
| The two reasons are invalid for Pixel phones:
|
| 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.
| joecool1029 wrote:
| > 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.
| yellowapple wrote:
| > 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.
| AaronFriel wrote:
| 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.
| rfoo wrote:
| 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).
|
| [1] https://www.androidauthority.com/wp-
| content/uploads/2018/10/...
| AaronFriel wrote:
| Ah, that's much better than the thread had me believe!
|
| Kudos to the security folks at Google.
| solarkraft wrote:
| > 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
|
| So burn an e-fuse like Samsung does.
| metiscus wrote:
| 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.
| flangola7 wrote:
| 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.
| joecool1029 wrote:
| 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.
| rvba wrote:
| Maybe make a phone that cannot be bricked by any software?
| A phone that can always be reset to a clear state with a
| factory reset?
|
| I'd argue that it's possible in 2023.
| Squeeze2664 wrote:
| 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?
| wldcordeiro wrote:
| 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.
| andrepew wrote:
| I don't think that clause would be enforceable because of the
| Magnuson-Moss Warranty Act.
|
| They can't deny warranty coverage because of a user
| modification unless they can prove the modification caused
| the damage?
| pbasista wrote:
| > 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.
|
| There might be similar laws elsewhere.
| Bran_son wrote:
| 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.
| jvanderbot wrote:
| 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.
| Bran_son wrote:
| > "I must connect to the internet once" problem is a very
| fair tradeoff
|
| Very fair. All Google requires is this: a simple offering
| of earth and water. A token of submission to its will.
| pessimizer wrote:
| > Pixel's are locked down a very tiny bit
|
| Other people might instead say "Pixels are locked down."
|
| > I don't think this is some kind of dystopian over-reach
| with security as an excuse.
|
| Why?
|
| > "I must connect to the internet once" problem is a very
| fair tradeoff from the user's perspective.
|
| Speak for yourself.
| jvanderbot wrote:
| > Speak for yourself.
|
| I am, that's what a "comment" is.
|
| And the second (I dont think...) follows from the first
| (very tiny bit). I'd just be repeating myself.
|
| This is opinion-based. We just disagree, that's fine.
| Zak wrote:
| 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.
| ouid wrote:
| 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.
| [deleted]
| jvanderbot wrote:
| 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.
| yellowapple wrote:
| And what happens when that server on the Internet stops
| authorizing bootloader unlocks, or disappears entirely?
| rezonant wrote:
| It is already the case with Pixel as others have described.
| https://www.androidauthority.com/wp-
| content/uploads/2018/10/...
|
| And the warranty thing is moot, unlock does not void Pixel's
| warranty
| r00tanon wrote:
| ELI5 - everything about a phone only works when the carrier
| allows it to connect to the network.
|
| So, the way this is done is to, well, connect to the network and
| allow the phone to be unlocked - which according to the article
| is what happened?
|
| So the real complaint is that the Pixel can't be loaded with a
| customized Android OS (or Linux, etc.) without being connected to
| the internet first and this is bad because the vendor might put
| bloatware, spyware, etc. on the phone, which, once you install
| your OS will be gone anyway?
|
| OK, well then other than the underlying hardware needing to still
| be recognized on the carrier's network, which pretty much means
| you still have to be connected. The point is you aren't going to
| be stealthy using the carrier network on a phone, so at the EOD
| you have a pretty expensive device you can really only use on
| WIFI using your own VPN without the Vendor's software.
|
| So what's the advantage over a small tablet based on OTS SOC
| hardware that you have full control over? IOW why buy the phone
| in the first place?
| justsomehnguy wrote:
| > this is bad because the vendor might
|
| Because the vendor can anytime say 'fuck you' and
| disable/remove the process which allows unlocking the
| bootloader.
|
| Edit: already happened with Pixel 2:
| https://news.ycombinator.com/item?id=35854552
| r00tanon wrote:
| So anyone who has already unlocked their Pixel 2 is good to
| go right? Getting the latest Pixel unlocked requires an
| internet connection, but once done it's done.
|
| So the complaint is that in the far future the vendor might
| not support that on a six year old phone (by that time)? But,
| it is supported now, so what's the beef?
|
| My old Pixel 2 only works now plugged into power and on WIFI
| because the battery is dead. I can get super-pissed off at
| Google for not supporting battery replacement on the Pixel 2,
| but it's a 6 year old phone. How long should I expect them to
| support it knowing at the time about the sealed battery. I
| can't get that pissed seeing as I bought it knowing the facts
| at the time :)
| chaxor wrote:
| One issue for this process that I have seen when talking about
| the Pixel is: - ***You can't actually back
| up your Pixel***
|
| It's enormously frustrating, because this is the typical advice
| before moving to a different OS. But apparently, actually
| mounting the device or seeing it via `lsblk` is from what I can
| tell impossible. I tried for a while to simply make a direct
| image with `dd` to try out other OSes etc but I couldn't even
| figure out a way to mount it, or in the cases it could be
| mounted it was using some insanely stupid fuse fs that was
| specifically made to be difficult to use. They want you to use
| some ridiculously complex and idiotic idea that revolves around
| using the cloud for backups, which I couldn't figure out
| precisely what was done because it isn't open source, so I
| refuse to use it. It's insane that you can't just `dd
| if=/dev/sdX of=phone.img` or something simple.
| lopkeny12ko wrote:
| This behavior is not new. This has been the case since at least
| Pixel 3.
| smnrchrds wrote:
| > _I bought a Pixel 7 Pro from store.google.com (Canada) ...
| being sold "unlocked" by Google_
|
| Carrier-locking is not permitted in Canada, so all the
| discussions about where the phone was bought and that the full
| price was paid are immaterial.
| abeyer wrote:
| But carrier locking is irrelevant, as the article is about
| bootloader locking.
| public_defender wrote:
| It is relevant because the excuse made for disabling
| bootloader unlocking is that unlocking the bootloader can
| defeat a carrier lock. They are interrelated.
| lern_too_spel wrote:
| I thought so too, but in order to show that the device was
| sold as unlocked, the article has a footnote (#7) about
| carrier unlocking.
|
| > Keep in mind that I bought this phone full price6 from
| store.google.com, where it was advertised right in the FAQ as
| an "unlocked smartphone"7
| ShadowBanThis01 wrote:
| Disgusting. Google has taken the fraud of Android to a new level.
| The great "open-source" OS that was supposed to free us all from
| vendor and telco tyranny has spectacularly failed to do so, and
| to cripple fully-owned hardware in this manner just adds further
| insult.
|
| Say what you want about "socialist" countries in Europe, but I
| don't think this kind of bullshit would stand in France. Based on
| laws they've passed over the last decade or two, Europeans seem
| to protect consumers; while the U.S. government abets
| corporations in ripping them off.
|
| Google apologists busily downvoting...
| jesprenj wrote:
| I got a Samsung S21 FE 5G as an award on a programming
| competition.
|
| OEM unlocking wasn't even an option in the developer settings
| until I connected the phone to the internet and set the date to
| one month in the past (I assume this has something to do with the
| warranty -- you can't even unlock the bootloader right away).
|
| An internet connection was required before even using the phone
| on the Android initial setup screen.
|
| Apart from that, developer settings can't even be enabled before
| agreeing with Samsung EULA. Initial setup screen can be weirdly
| manipulated into opening settings (Accessibility, Additional
| apps, Live transcribe, Connectivity settings (only shows if
| there's no inet connection), back), but spamming the Build number
| does not enable developer settings.
|
| Granted that I did not buy the phone, but it's still disgusting
| that such devices are being sold.
| zeagle wrote:
| I liked my Samsung phones but after the a couple of them went
| end of life despite being very usable I am never buying one of
| their devices again and sticking with Pixel. There should be an
| Android code of ethics or regulation to unlock bootloaders of
| these devices when discontinued to minimize eWaste.
| KennyBlanken wrote:
| Why on earth would Google institute a policy that runs
| completely contrary to the cell phone industry's business
| model, making their devices as useless as possible as fast as
| possible?
|
| It always cracked me up that Apple gets bashed for planned
| obsolescence when they support their phones longer than
| anyone else in the industry.
| m_kos wrote:
| One thing I find very annoying about Samsung is that it tries
| to get people to use Bixby (Samsung's "Google Assistant") by
| remapping their phone's power button to Bixby. Due to the
| nature of my current project, I talked to many Samsung owners
| in their 50s and 60s who don't know how to turn Bixby off and,
| consequently, don't know how to, e.g., shut down or reboot
| their phones.
| Dylan16807 wrote:
| Another way of looking at it is they had a bixby button and a
| power button, and decided to remove the power button.
| quaintdev wrote:
| This does not make any sense. GrapheneOS supports all pixel
| phones. In fact, they support pixel phones only.
|
| I am thinking of buying pixel just for this.
| Georgelemental wrote:
| Bootloader unlocking is disabled _until you connect to the
| internet._
| theK wrote:
| Just out of curiosity, is it "just" the Internet or "connect
| to the internet, log in to a foogle account"?
| rfoo wrote:
| Just the Internet.
|
| You have to click Skip when the phone prompts you to log in
| to a Google account though, as it does this by default.
| Fire-Dragon-DoL wrote:
| What's special about GraphenrOS? It's the first time I'm
| hearing about it
| quaintdev wrote:
| Make phone Google free. More features here
| https://grapheneos.org/features
| lostgame wrote:
| So I'm guessing with this you'd use an alternative store
| like F-Droid instead of the Play Store? (Pardon my
| ignorance, I'm an iOS dev and have been for a decade; I
| don't really know the Android landscape.)
| ajayyy wrote:
| There are also FOSS front-ends for Google Play such as
| Aurora Store
| aesh2Xa1 wrote:
| No, not necessarily.
|
| The project officially develops secure, private access to
| the Play Store and its apps. My interpretation is that
| the project's authors prefer users to use the secure Play
| Store implementation over alternatives like Aurora, even
| if Aurora works fine.
|
| https://grapheneos.org/faq#google-services
| solarkraft wrote:
| This is also a big part of the special sauce that
| GrapheneOS offers. I haven't seen the Play Services
| sandboxing built into any other OS.
| George83728 wrote:
| > _So I'm guessing with this you'd use an alternative
| store like F-Droid instead of the Play Store?_
|
| Not necessarily, but that's the best way to do it.
| Between apps from F-Droid and a browser, you don't need
| any apps from the play store. Your bank doesn't have an
| app on F-Droid you might say? Well that's what the
| browser is for.
| lostgame wrote:
| Ha. Your example is rather specific seeming to me, as I
| actually work on one of the big 5 Canadian banking iOS
| apps here in Toronto.
|
| For obvious reasons; we don't ship to alternate stores -
| even if such a thing as iOS sideloading existed; we
| wouldn't support it, and we of course do not support
| anything but the Play Store on Android.
|
| It's obviously partly a support cost issue - there would
| be less than 1% of our millions of users using F-Droid,
| etc - and, more importantly; it's a security and support
| issue.
|
| I think for a while we even had some sort of check that
| would detect a jailbroken iPhone or rooted Android device
| and attempted to refuse to run on them. Security is so
| far above the #1 priority working in banking it's insane.
| We'd never consider anything outside of Apple or Google's
| official solutions. We actually have real life contacts
| at Apple to help address specific security or approval
| concerns; which is practically unheard of.
| Zak wrote:
| > _I think for a while we even had some sort of check
| that would detect a jailbroken iPhone or rooted Android
| device and attempted to refuse to run on them._
|
| Your uncertainty about this suggests it's not something
| you decided, but please let anyone involved in making
| decisions like that know that's a dick move. It's the
| user's device, not the bank's.
| lostgame wrote:
| Oh, I certainly have absolutely no control over those
| types of decisions. I'm a soldier, not a general, I just
| do what I'm told, tbh.
| logifail wrote:
| > rooted Android device
|
| (I'm sure I'm missing the obvious here) but why are you
| happy to have customers log in using a browser on a
| device they fully control, yet not do the same using your
| app on a device they fully control?
| yellowapple wrote:
| The obvious answer is that they're _not_ happy about it,
| but that browsers don 't give them the access necessary
| to detect whether the device running said browser is
| rooted (let alone do anything about it), so they can't
| pretend they know better about my own device's security
| than I do.
| smeej wrote:
| Security in banking apps in the U.S. is an absolute joke.
| I'm glad to hear Canada takes it more seriously.
|
| I've used everything from giant multinational banks to
| local credit unions in the U.S., and none of them will
| even let me sign in with U2F. Many of them still have
| password character limits.
| mindslight wrote:
| Erm, why would you ever want an app for your bank _on
| your mobile phone_? So that when you get mugged, it can
| turn into a kidnapping?
|
| I use some bank apps because they're quicker than the
| websites. But I do this with a cheap Nexus 7 tablet that
| stays at home with a label saying "full take" stuck to
| the top to remind me to not trust it with any sensitive
| information.
|
| Segregating apps onto different devices is the way to go
| to protect yourself from corporate malware.
| Koffiepoeder wrote:
| You can also just have multiple banks and then choose one
| of them to be the account where you put your 'working
| money'; i.e. an amount that you can afford to lose. This
| way you still get the convenience of having a bank app
| (quick payments, transfers & stuff), but not the risk of
| losing it all.
| yellowapple wrote:
| > Erm, why would you ever want an app for your bank on
| your mobile phone?
|
| To easily check balances and make transfers wherever I
| am. This is possible without the app, but the app makes
| it easier/quicker than the mobile site in most cases.
|
| > So that when you get mugged, it can turn into a
| kidnapping?
|
| How do you suggest a mugger to find out whether such an
| app is even installed, let alone do anything about it, in
| this day and age of full-device encryption being the
| default? Even assuming a mugger somehow has access to the
| nation-state-level compute resources and exploit tools
| necessary to gain access to anything on my phone, by the
| time the mugger has finished using said tools and compute
| resources, I'll have already changed my passwords and
| invalidated existing login sessions.
|
| Also, kidnapping involves considerably more effort and
| risk than mugging, so this is a weird argument in
| general. The vast majority of people with both
| smartphones and bank accounts almost certainly have
| banking apps installed on their phones, and I know of
| precisely zero cases of muggers deciding "oh you have a
| banking app? lemme go find my windowless van and kidnap
| you, drawing considerably more attention to me and giving
| you considerably more reason to violently defend yourself
| instead of cooperating; surely nothing will backfire from
| that, no siree!".
|
| Muggers quite frankly don't give a flying fuck about the
| apps on your phone. They want your cash and/or whatever
| they can quickly fence.
|
| > Segregating apps onto different devices is the way to
| go to protect yourself from corporate malware.
|
| Having firmware that gives you fine-grained app
| permissions that you can freely grant/revoke also
| accomplishes this. If apps on the Play Store are
| subverting that, then banking apps are probably the least
| of your worries.
| smeej wrote:
| > How do you suggest a mugger to find out whether such an
| app is even installed, let alone do anything about it, in
| this day and age of full-device encryption being the
| default?
|
| They make you do it, the same way they made you give them
| the device in the first place.
|
| I don't know why anyone thinks it would turn into a
| kidnapping, but it's pretty easy for someone who has
| already forced you to give them your phone to use the
| same technique to force you to unlock it.
| lostgame wrote:
| Doesn't this risk also apply to, like; carrying cash or
| even a debit card too close to an ATM? :/
|
| I just don't see this as enough of a risk to be concerned
| about it, maybe it depends on where you live.
| squarefoot wrote:
| Don't bank apps complain if the phone is rooted or runs
| anything than a stock OS?
| bravoteam5 wrote:
| [dead]
| distantsounds wrote:
| not only is the title misleading and click-baity (connecting to
| wifi is the only pre-requisite) the format of the blog doesn't
| format correctly (text and media is cut off on the right) . maybe
| spend less time writing misleading articles and more time fixing
| its viewability?
| prettyStandard wrote:
| Does this help prevent supply chain attacks... at all?
| taco9999 wrote:
| Probably not, since there will be a warning screen displayed on
| boot if the bootloader is unlocked.
| hexagonwin wrote:
| I have a much older Google phone, a Verizon sold Pixel 2 which is
| not unlockable even after connecting to the internet. I got the
| phone second hand hoping to run LineageOS but I couldn't, so I
| just left it on my drawer. They really need to put an end to this
| ewaste generating policy. I should be able to do what I want with
| my device.
| williamDafoe wrote:
| Google has a console called panopticon where they can see every
| Chromebook in the world. This monitoring facility is used to
| measure bug / crash prevalence in e.g. 802.11 driver software and
| to determine how much of each fleet is running the latest
| ChromeOS security patches.
|
| They can do this because Unlike Microsoft Google ports ChromeOS
| onto new laptops and tests the crap out of them (including the
| verification that the manufacturer meets about 25 min performance
| requirement standards for Chrome hardware like LCD viewing angles
| and speaker volume). They also test the laptops by giving them to
| employees and then demand hardware improvements of the
| manufacturers to get the Chrome branding logo.
|
| I bet the have a similar system for for their HTC phones. So your
| Pixel is probably registering with a panopticon type system
| because 99.9% of customers are gonna use the stock OS. They do
| this so their users perceive and experience higher hardware
| reliability. So it may sound creepy but the goal (100% fleet
| registration) is hard to meet without forcing 1 internet
| connection at the 1st boot. It will be hard to meet your freedom
| goals and google's reliability goals at the same time ..
| martius wrote:
| Source for this?
|
| There is a well known tool named Panopticon (abbreviated pcon)
| internally and this is not at all what you describe.
|
| (I work at Google)
| neximo64 wrote:
| I im honest I don't see the big deal with this practice.
|
| a) You can unlock the device
|
| b) You can connect via WiFi, why is the device 'phoning home'
| such a big deal when its brand new and has no data on it?
| [deleted]
___________________________________________________________________
(page generated 2023-05-07 23:00 UTC)