If you're talking about simply unlocking the bootloader, that's as simple on most phones. I'm more referring to the general barriers put up to doing anything with your phone, either before unlocking (the OS itself is restrictively HTC-oriented) or after unlocking (S-ON, etc.)

> Naturally HTC will from there on out decline responsibility for bricked phones, but which company doesn't?

The fact that this is an accepted norm is another part of the problem. Why "naturally"? Some manufacturers (like Google, Fairphone, Motorola on a limited number of phones) don't void the warranty, but even if none did: why do you think this "naturally" an acceptable thing other than it being the norm?

If you don't damage the hardware by flashing, there's no reason it should be out of warranty. If you do "damage" it because of some malicious hardware fuse installed by the manufacturer, then it seems to me that could reasonably be considered a faulty device.

You can actually permabrick the hardware with a non-compatible or buggy flashed OS. It's an embedded device, so the Linux kernel has access to a lot of stuff that it wouldn't, e.g. on an ordinary PC.

Kind of ironic that said embedded device is supposed to have at least nontrivially-above-average security.

But flashing itself can also go horribly wrong due to poor bootloader quality etc.

> The fact that this is an accepted norm is another part of the problem. Why "naturally"? Some manufacturers (like Google, Fairphone, Motorola on a limited number of phones) don't void the warranty, but even if none did: why do you think this "naturally" an acceptable thing other than it being the norm?

Because I want to be allowed to install software that will damage the phone. Holding the phone manufacturer responsible for code I wrote is not in fact a natural thing to do.

> Holding the phone manufacturer responsible for code I wrote is not in fact a natural thing to do.

I'm sorry but I'm really struggling to understand what you mean by this. What hardware should I be running the code I write on without fear of voiding the warranty.

If it's the fact I wrote the code that constitutes voiding the warranty, exactly who's code should we be permitted to run on hardware we've purchased? Only code which has been written by/provided by the manufacturer themselves?

What's the precedent for this absurd restriction?

You shouldn't be running the code you write on any hardware without fear of voiding the warranty. The point of a general-purpose computer is that the code you write might do anything at all. There is no warranty to cover that, and there shouldn't be. You should get over your desire for a warranty.

Why is this acceptable for the computers that go in our pockets when its clearly not the case for those that go in our backpacks or datacenters?

I've bought a handful of used HTC devices in the past. Only "real" HTC devices are go to dev page and unlock. If they've been through a carrier that isn't T-Mobile, it's very likely permanently not unlockable. Try entering a Verizon-issued HTC or Sprint-issued HTC on the page.

Yes, entirely possible (I wouldn't know, I'm not US based). When the carrier breaks the phone, is it the original manufacturer's fault though?

The carrier's contract with the manufacturer or something explicitly demands that the manufacturer not unlock the bootloader.

I believe you can unlock Pixels without voiding the warranty.