> 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.
I have absolutely no idea what you're talking about. You're either misunderstanding something or something really needs to be changed in the docs.
Citing an article [0], a post[1] on the site states, "Security researchers over the years have discovered ways to detect what you are typing on the screen simply by looking at variations in the accelerometer." (Infomercial-esque strikethrough not retained here.)
Purism's solution, apparently, is hardware switches. As I understand it, the accelerometer isn't disabled via hardware switches unless all hardware switches are disabled, as there is no discrete accelerometer switch: "To trigger Lockdown Mode, just switch all three kill switches off. When in Lockdown Mode, in addition to powering off the cameras, microphone, WiFi, Bluetooth and cellular baseband we also cut power to GNSS, IMU, and ambient light and proximity sensors."[1]
[0] https://phys.org/news/2013-10-accelerometer-tracking-potenti...
[1] https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...
I'll try my best to take this seriously.
I don't care much about hardware kill switches myself - but many people clearly do. I've seen it when I was involved in the Neo900 project, I've seen it in discussions about the Librem 5 and PinePhone, I've seen it in reactions when Purism has released a tablet that lacked them. I guess it's because, unlike software, they're easy to understand and easy to trust. Most people don't understand or particularly trust software, for various reasons. Even with Android's security model, I don't think a regular user trusts that Google Play Services that run on their phone always do what they told them to, so they often long for something tangible that would give them a peace of mind. Hardware switches do that.
There's a matter of the modem being a whole separate device that's not really under the user control too. The only way to be sure that it's actually off is to not give it access to power. You can trust your OS, but the modem could still do its own thing regardless of what you asked it to, so I can get that too.
> The Purism model increasingly looks fatally flawed for anyone who doesn't have a very particular and narrowly defined threat model: one who trusts all software they run from the kernel to their applications completely, trusts their hardware completely, yet for [reasons] somehow fully mistrusts the sum total of the device at very specific, limited, and irregular intervals.
The Librem 5 is a general purpose computer that you can run whatever you want to on. I have no reason to distrust the GNU/Linux distribution that runs on it, but I could very well run Android, perhaps even with Play Services, on it if I had to for some reason, just like I used to boot into Windows on my PC many years ago. If I wanted to make sure that it won't access the radios or sensors while I do so, the switches would indeed not just be helpful, but effectively effortless.
The "lockdown mode" in particular is an answer to a UX issue. People want to have switches for various things, but if you just gave them all they ask for you'd end up with nothing but tons of switches around the screen. I believe the main motivation for the lockdown mode was squeezing the control over GNSS in when it was decided to use at most three switches, and the sensors then followed as adding them there could be done almost for free. You could do the thing PinePhone did, with plenty of tiny inaccessible switches behind its back cover; Purism opted for a limited amount of easily accessible switches, and I'm actually glad they did (it happened long before I got involved), because...
> Per Purism, it's perfectly usable in the same way any Linux slab with no radios or sensors of any kind is perfectly usable, yes, but that's stretching things in practical terms for a phone, and it's all very divorced from the reality of what most people expect from their phones.
I said that I personally don't care about the switches, but I also have to say that I surprised myself and ended up using them quite a lot. Not the mic/cam one, this one stays basically unused, but I'm using the cellular and Wi-Fi ones regularly - they're just super convenient. Whenever I want to save power or not be bothered by anything, I toggle the switches. If I had to unlock the phone and swipe through some menus, I probably wouldn't bother most of the time, but I don't have to, so I do. I used to be completely indifferent to these switches, but they ended up being really nice to have when I actually started using the phone. Let's not pretend that having an airplane mode option on a phone makes it a "slab with no radios", there are contexts where you do want to disable some things and continue to use the others.
> Still, it's entertaining. The marketing, the switches, the sweeping technical proclamations and bold self-assessments of high corporate ethics.
I don't see anything wrong in Purism providing what people have often requested. This is not exactly a kind of device that will just market itself, the more niches it can serve and differentiators it can tuck in without diminishing other aspects of the device the easier it will be to sell. I don't think the Librem 5 project would be economically viable if it only ever targeted people interested in Linux. Kill switches, modularity, smart card reader, replaceable battery, separate GNSS module, audio jack etc. are all attempts to extend its appeal and serve a yet another niche, as a device like this would never be able to compete on thinness or specs with what's offered mainstream. It makes perfect sense to me. Some of these things I enjoy, some I don't care about, but none bothers me.
> Beyond all that, installing packages from Debian stable on a mobile phone is a very enjoyable thing. I'm a former N900 and PinePhone user who's not opposed to making reasonable compromises for significant upsides, and would love a truly viable and fully open Linux phone that can run a variety of distros, but I remain unconvinced that the Librem 5 is that device.
I'm a former Neo Freerunner and N900 user, and a current Librem 5 user (with a PinePhone around too, but I already had a Librem 5 when I got it so I barely ever used it). Installing Debian packages is the only way I know how to use a smartphone. Well, okay, I used opkg in the past too :) I got involved in the project because it was clear to me that this was the device worthy of being the successor of my N900 and I'm happy with it and proud of what we, both Purism and the wider community, managed to achieve with it. In fact, I'm starting to get worried about it aging with no viable successor in sight. It's still fine today, but the arrow of time only points one way.
>> 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.
You don't have to lock things down to solve that either - see the measured boot process with Librem Key for an example.
(that said, this is a completely different threat vector that I doubt the common masses actually care about; and if I really had to choose between openness and evil-maid resistance, I'd choose the former)
I think the common masses just expect it in the first place. If you told someone that leaving their phone unattended could lead them to getting their data stolen, they would probably be surprised. I know this isn't a surprise to the HN crowd, but it is for regular people.
I would also guess that the common masses would choose the opposite as shown by them choosing convenience over openness. It's convenient to not have a separate key to prevent evil-maid attacks.
To be frank, I'm tired of this security theater. Yes, let's lock things down to prevent evil-maid attacks and bring in the technological dystopia in the process, who cares that the same evil maid could put your finger onto the fingerprint sensor and unlock the phone while you sleep without ever fiddling with the bootloader.
"The masses" used to use completely unencrypted devices for decades. That doesn't mean they don't deserve security, but it's up to us, the technologically savvy ones, to determine how to implement it and which trade-offs are worth making to provide it. The term "security" only ever has any meaning when paired with a threat model, and some threats are more plausible than others. Some people will absolutely require proper evil-maid resistance, some wouldn't care the slightest. The common masses would be equally surprised if you told them that they can't change the boot animation on their phone without preventing access to their bank app, so go figure.
I'm not terribly concerned about an evil maid entering my room at night and managing to authenticate my fingerprint without waking me.
I do, however, regularly have to check my phone in at [places] and am highly concerned about that.
I'm not interested in bringing about a tech dystopia to combat it, either, but I don't think those are our only two choices.
Threat modeling is important, and selectively false equivalences aren't helping matters, but only add to the theatrics.
I'm pretty sure that most of the actual evil-maids out there are phone owner's partners that they tend to share their bed with at night.
And yes, I don't think those are the only two available choices either. I already mentioned not just one, but two other ones above. They have some tradeoffs, but so does anything. Personally I'd choose a slightly less convenient option over a tech dystopia without second thoughts, but not everyone is tech savvy enough to even recognize the tradeoffs being made, and ultimately in the vast majority of cases it's not the users who make that choice, but Google and Apple.