← Back to context

Comment by seba_dos1

20 hours ago

> That's mainly because of device trees.

Huh? The device tree is the one thing trivially recoverable from the blob. I'm talking about drivers, the same kind as when you install, let's say, the non-free Nvidia driver on a PC. They run as part of the OS and handle various stuff, most commonly comms like VoLTE/VoWiFi, but often also camera ISPs, GPUs, fingerprint readers etc.

> are all isolated and sandboxed

So isolated that you can break them by repartitioning your eMMC/UFS.

> A primary reason people complain about proprietary blobs is security.

The primary reason I care about blobs is freedom and practical aspects that come out of it. Dealing with blobs is always a PITA and severely limits what you can do with the hardware. The peripherals would be nice to have freed, but it's the main CPU and storage that is supposed to be my (the user's) domain and only mine. My Librem 5 came with a GNU/Linux distro on it, but if I wanted to port, say, FreeBSD to it there's all I need to be able to it. I can't do that with an AOSP device fed with blobs from the "vendor" image, at least not without spending years on reverse engineering.

The Librem 5 is one of the handful phones out there that make it this easy. It is also the only one I'm aware about that's still being sold where you have the hardware ECAD and MCAD designs available - and not just to look at, but published on a free license. I think it has earned its bragging rights when it comes to freedom and openness.

> can someone sell you a compromised Librem 5?

Of course, just like any other PC. You want to reflash it before use, obviously.

The SoC supports High Assurance Boot, you can burn your key into its efuses and have it only ever accept software that's cryptographically signed by you.

I see. So it is better in the sense that the drivers are open-source. Though the drivers in Android/GrapheneOS are not open-source, I believe the drivers are also isolated from full kernel-level access.

But it still brings the point that you can't make a phone without proprietary chips and firmware from the mobile industry giants.

> You want to reflash it before use, obviously.

I think that is non-obvious to the majority of users buying a phone.

> The SoC supports High Assurance Boot, you can burn your key into its efuses and have it only ever accept software that's cryptographically signed by you.

An important consideration for consumers is that their data is secure if they lose their phone. Without a secure boot process by default, that's a hard sell for the common masses.

  • The real question is whether it affects me as a user. The RF spectrum used by cellular networks is highly regulated, so I wouldn't be able to use it freely either way. The PC keyboard I type on right now most likely has some kind of microcontroller running some code in it, but it's of little consequence to me whether it's free or not. I do care about what runs on *my* system though, as that has tangible implications, and I care about it the same way whether it's my laptop or my phone.

    > that is non-obvious to the majority of users

    Yes, and the consequences of that can be seen in TFA - locking things down due to ill-defined security concerns. Why not go a bit further - the most secure device is the one you can't use to do anything at all.

    On a side note, app attestation is already unironically getting us there - you have to either accept that you have no control over "your" device or not be able to use it to interface with the world. For me, any platform that allows applications to attest the environment they run in is insecure by design, as it can be exploited against me.

    > An important consideration for consumers is that their data is secure if they lose their phone

    Well, it's a good thing that PureOS is LUKS-encrypted by default then. It even has a smartcard reader, so key storage can be decoupled from the phone's hardware.

    • > Why not go a bit further - the most secure device is the one you can't use to do anything at all.

      That's not far off a reasonable criticism of Purism's security model, that a device so wholly compromised it requires one to activate all physical kill switches to disable the hardware in order to so much as safely enter one's device PIN (per Purism's own site content), that it's no longer useful.

      Everyone has to make their own trade-offs, but for me that's a model so questionable that its utility value rapidly approaches zero.

      3 replies →

    • >> An important consideration for consumers is that their data is secure if they lose their phone

      > Well, it's a good thing that PureOS is LUKS-encrypted by default then.

      My bad, I meant leave their phone unattended. Wherein someone can compromise the device from boot, so that when unlocked, the device is fully compromised.

      6 replies →