Qfuse on 6P

I'm sure there are other hardware features on the 810 that Google will also never use.

If Google ever does anything with the lock-fuse, I swear I will build a cross and find some nails. In the meantime, I'm not worried :)
 
Thanks for the input Jerry. Found those couple discussions bubbling out there.

Posted via the Android Central App
 
This isn't a new issue, rather more of a new concern -- check out this Azimuth Security blog entry from 2013, regarding Moto's bootloaders. Aside from having plenty of technical detail for those interested, there are a few key points to pick up on. First though, recognize this bit, written by Jerry:

What is an 'unlocked' phone? (And why do I care?)

The bootloader on your phone came locked from the factory. This is a good thing, because having a bootloader that's not locked will allow modification to the software, and is not secure at all. But the ability to modify the software on our phones is precisely why many of us want an unlocked bootloader.

Here's where things get a little dicey. We've seen that most manufacturers are OK with allowing you to unlock the bootloader (using a token or key they supply) as long as you're OK with potentially voiding your warranty. This is a good thing. This is what freedom smells like and all that. Seriously, once we've paid for a phone it should be ours to break as we like.

The people who own and operate the network that your phone runs on (this is mostly a U.S. thing) feel differently. They want to decide exactly what software is running on the phones and tablets that use their network. And that's their right. Besides potential issues custom software could create on the network itself, they have customer service and warranty concerns to manage. It's their network, and they get to try and decide (for the most part) what can be running on it. The way they (try) to make this happen is by offering their own version of a phone that can't be easily bootloader unlocked.

Now, building from the above quote and the linked Azimuth Security post:

  1. Having these physical, 'irreversible' mechanisms allows for generally greater and more predictable device security at the boot level, which (albeit vague) is a win-win for consumers and OEMs alike
  2. Having these mechanisms establishes a sort of middleground in the relationship between OEM and consumer, at least in the context of aftermarket software modifications; they facilitate the development of straightforward bootloader unlock utilities like we've seen from Motorola, HTC, ASUS, etc. (which allow you to register your device and receive a bootloader unlock code in exchange, thereby preserving your right to modification and their right to warranty status assurance). It isn't worthwhile for manufacturers to provide such a utility without a reasonable measure of control over and assurance behind the process on the device itself.
  3. Building from the previous point, this paradigm provides a high-level distinction between devices intended for your average consumer (with factory-status security), and those intended for developers, enthusiasts, purists, et al. (potentially with aftermarket software modifications). The result? "Developer" models of popular devices. Sure, this may restrict the "unlockable" options to a relative handful of devices (compared to being "able" to unlock any phone at will), but...
  4. ...the Azimuth Security entry was written to outline the process behind developing a workaround to the initial Qualcomm QFuse security. We still have the ability to work around the security on many "standard" devices thanks to some very intelligent community contributors.
  5. There are now entirely separate options for those so inclined (for example, a Nexus device on Project Fi), which changes the traditional OEM/carrier/consumer relationship at each level.

I'm all for awareness of the hardware and software security governing one's devices, but the presence of the security itself shouldn't be immediate cause for alarm. We're at a point where manufacturers and carriers recognize our position and are willing to support devices that support us. If this effects a small selection of "supported" unlockable devices elected to fill this role, it may seem like a step backwards, but then again, there was a point when developer devices and unlock utilities didn't exist at all.

All in all, considering the points above, I think we're in good standing. Plus, as Jerry more or less said in his reply, I'd be very surprised if Google were to implement such measures on the Nexus devices.
 
I'd be surprised as well since these are straight Google phones that can serve as a platform for developers and enthusiasts.
 
I am aware that Android Pay is not supposed to be allowed on rooted phones, are Google using the qfuse to disable Android Pay?

Posted via the Android Central App
 

Trending Posts

Forum statistics

Threads
957,282
Messages
6,972,223
Members
3,163,756
Latest member
tuananh3105