It does. They obscure the usage of non-free hardware/firmware by not shipping it as part of the OS, but as a bundle on separate flash storage that is loaded into the OS by initrd. That blob is updatable as "firmware". The 100% free open-source is just marketing. It's just for the OS. A lot of the hardware and firmware is proprietary.
Depends where you draw the line. There is not a single non-free blob in the OS that runs there once the bootloader is up (unless you put some there by yourself, which you're of course free to do).
I think you misunderstand what the Purism Firmware Jail is. I don't blame you though. They seem to make it purposefully misleading. It doesn't isolate what runs in the OS. It just isolates the OS updates from the non-free blob updates. The OS still runs the non-free blobs. It just loads it from separate flash.
It is you who is confused here. The first link is completely irrelevant to the Librem 5, and the second one points to a thread where the actual information present has been written by me.
The only non-free piece of code executed by the ARM Cortex-A53 cluster on the Librem 5 is the SoC's mask ROM bootloader. Once the control is passed to u-boot/ATF there is not a single non-free blob that runs there. Some peripherals may need blobs to be uploaded onto them to work, such as DP, DDRC and one of the used Wi-Fi cards (handled by ROM/u-boot/Linux respectively), while others boot from their own internal memories. Not all of those firmwares are non-free, but most are.
In the end, as I said earlier, the assessment depends on where you draw the line. I happen to draw it at the main CPU and the blobs that need to run within the user-controlled OS, which are unacceptable for me and which aren't present on the Librem 5.
Ah. I see. So the blobs are loaded into the separate microprocessors. Either way, it's the same as pretty much any modern phone, where the modem (and other secondary processors) are running some proprietary firmware and is communicating with the OS processor.
I don't see how it's different from running a free open-source ASOP OS. On the mainstream Android devices, the wireless hardware is also isolated and communication is done via IOMMU.
There's some debate as to whether using the USB stack for communication to the modem in the Librem 5 is less secure than IOMMU as well.
Pretty much any modern phone is also full of blobs that run on the main CPU to ensure basic functionality, with only a handful of exceptions. Just consider how many features stop working or get severely degraded on various phones when you use a clean AOSP build on them (provided that you can do it at all in the first place). Android's driver infrastructure effectively encourages non-free blobs in "vendor" partitions, and many things are purposely moved from the GPLv2 kernel to the userspace so they don't have to be copylefted. If you want to run a non-Android OS on these devices you either have to fill the gaps yourself or use these blobs through compatibility layers.
> at that point you still are trusting external communication to those devices with their proprietary blobs
Just as you do with any kind of peripheral, whether it implements what it's doing purely in hardware or with an embedded microcontroller.
> There's some debate as to whether the USB stack for communication to the modem is less secure than IOMMU as well.
You can have "some debate" on absolutely anything, but that doesn't yet mean it makes any sense. You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack, so whatever debate you're referring to is unlikely to be held in good faith. I wonder why you mention it unprompted, as it's fairly off-topic here.
> Just consider how many features stop working or get severely degraded on various phones when you use a clean AOSP build on them.
That's mainly because of device trees. The firmware also isn't distributed via separate flash storage on the device, but I don't consider that making a difference. It's still proprietary firmware running on proprietary hardware. On Qualcomm-based Pixel devices, cellular, WiFi, Bluetooth, and GNSS are all isolated and sandboxed.
> It's also interesting that you mention it unprompted, as it's fairly off-topic here
A primary reason people complain about proprietary blobs is security. People claim that the Librem 5 is more open and secure, but it still uses the same proprietary modules as a Pixel running GrapheneOS. Does Librem 5 have signature checks for the firmware and a tamper-proof bootloader to load the firmware and OS, or can someone sell you a compromised Librem 5?
Is it more free, open, and secure than a Pixel running Android? Because, the only difference I'm seeing is how the firmware is stored and Google Play Services. And with GrapheneOS, only how the firmware is stored. Everything else points to a more insecure system with Librem 5.
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.
>> 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 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.
> 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.
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]
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.
> You can have "some debate" on absolutely anything, but that doesn't yet mean it makes any sense.
Sure, but from the fact that anything can be debated it does not follow that any given debate is nonsensical, which is kind of what you did there.
> ...whatever debate you're referring to is unlikely to be held in good faith.
I don't know which is odder, that assertion, or the notion that two completely different security models can't be debated in good faith because they're effectively identical, because of hand-wavy reasons like, "You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack..."
Certainly there's some kind of argument to be made that the Librem 5 is relevant to this post as its adherents see it as a viable alternative to iOS and/or Android-based devices. I disagree, but everyone's willing to make different compromises and that's fair.
I only mention that because a contingent of voices as high in volume as they are few in number endlessly shoehorning the Librem 5 into numerous threads no matter how much of a non-sequitur it takes, has me suddenly paying more attention these days to what's coming from the Purism camp. The more I do the more disingenuous the rhetoric seems.
It may just be a coincidence, but for a project with such a fraught history and tarnished reputation, it doesn't do anything to increase my trust in it.
I have to admit that I had a kind of knee-jerk reaction there, as this "debate" is very often brought up in FUD pieces without much substance behind it.
It does. They obscure the usage of non-free hardware/firmware by not shipping it as part of the OS, but as a bundle on separate flash storage that is loaded into the OS by initrd. That blob is updatable as "firmware". The 100% free open-source is just marketing. It's just for the OS. A lot of the hardware and firmware is proprietary.
https://github.com/linuxboot/heads/blob/c859c28b88b7bc197c16...
https://forums.puri.sm/t/the-librem-5-blob-list/28815/26
> The 100% free open-source is just marketing.
100% FLOSS is in the OS: https://news.ycombinator.com/item?id=25504641. It is not the end of the road, but this is the only phone that can run such OS.
See also: https://news.ycombinator.com/item?id=47943487
Depends where you draw the line. There is not a single non-free blob in the OS that runs there once the bootloader is up (unless you put some there by yourself, which you're of course free to do).
I think you misunderstand what the Purism Firmware Jail is. I don't blame you though. They seem to make it purposefully misleading. It doesn't isolate what runs in the OS. It just isolates the OS updates from the non-free blob updates. The OS still runs the non-free blobs. It just loads it from separate flash.
https://github.com/linuxboot/heads/blob/c859c28b88b7bc197c16...
https://forums.puri.sm/t/the-librem-5-blob-list/28815/26
It is you who is confused here. The first link is completely irrelevant to the Librem 5, and the second one points to a thread where the actual information present has been written by me.
The only non-free piece of code executed by the ARM Cortex-A53 cluster on the Librem 5 is the SoC's mask ROM bootloader. Once the control is passed to u-boot/ATF there is not a single non-free blob that runs there. Some peripherals may need blobs to be uploaded onto them to work, such as DP, DDRC and one of the used Wi-Fi cards (handled by ROM/u-boot/Linux respectively), while others boot from their own internal memories. Not all of those firmwares are non-free, but most are.
In the end, as I said earlier, the assessment depends on where you draw the line. I happen to draw it at the main CPU and the blobs that need to run within the user-controlled OS, which are unacceptable for me and which aren't present on the Librem 5.
Ah. I see. So the blobs are loaded into the separate microprocessors. Either way, it's the same as pretty much any modern phone, where the modem (and other secondary processors) are running some proprietary firmware and is communicating with the OS processor.
I don't see how it's different from running a free open-source ASOP OS. On the mainstream Android devices, the wireless hardware is also isolated and communication is done via IOMMU.
There's some debate as to whether using the USB stack for communication to the modem in the Librem 5 is less secure than IOMMU as well.
Pretty much any modern phone is also full of blobs that run on the main CPU to ensure basic functionality, with only a handful of exceptions. Just consider how many features stop working or get severely degraded on various phones when you use a clean AOSP build on them (provided that you can do it at all in the first place). Android's driver infrastructure effectively encourages non-free blobs in "vendor" partitions, and many things are purposely moved from the GPLv2 kernel to the userspace so they don't have to be copylefted. If you want to run a non-Android OS on these devices you either have to fill the gaps yourself or use these blobs through compatibility layers.
> at that point you still are trusting external communication to those devices with their proprietary blobs
Just as you do with any kind of peripheral, whether it implements what it's doing purely in hardware or with an embedded microcontroller.
> There's some debate as to whether the USB stack for communication to the modem is less secure than IOMMU as well.
You can have "some debate" on absolutely anything, but that doesn't yet mean it makes any sense. You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack, so whatever debate you're referring to is unlikely to be held in good faith. I wonder why you mention it unprompted, as it's fairly off-topic here.
> Just consider how many features stop working or get severely degraded on various phones when you use a clean AOSP build on them.
That's mainly because of device trees. The firmware also isn't distributed via separate flash storage on the device, but I don't consider that making a difference. It's still proprietary firmware running on proprietary hardware. On Qualcomm-based Pixel devices, cellular, WiFi, Bluetooth, and GNSS are all isolated and sandboxed.
> It's also interesting that you mention it unprompted, as it's fairly off-topic here
A primary reason people complain about proprietary blobs is security. People claim that the Librem 5 is more open and secure, but it still uses the same proprietary modules as a Pixel running GrapheneOS. Does Librem 5 have signature checks for the firmware and a tamper-proof bootloader to load the firmware and OS, or can someone sell you a compromised Librem 5?
Is it more free, open, and secure than a Pixel running Android? Because, the only difference I'm seeing is how the firmware is stored and Google Play Services. And with GrapheneOS, only how the firmware is stored. Everything else points to a more insecure system with Librem 5.
> 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.
>> 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.
> 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.
> You can have "some debate" on absolutely anything, but that doesn't yet mean it makes any sense.
Sure, but from the fact that anything can be debated it does not follow that any given debate is nonsensical, which is kind of what you did there.
> ...whatever debate you're referring to is unlikely to be held in good faith.
I don't know which is odder, that assertion, or the notion that two completely different security models can't be debated in good faith because they're effectively identical, because of hand-wavy reasons like, "You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack..."
Certainly there's some kind of argument to be made that the Librem 5 is relevant to this post as its adherents see it as a viable alternative to iOS and/or Android-based devices. I disagree, but everyone's willing to make different compromises and that's fair.
I only mention that because a contingent of voices as high in volume as they are few in number endlessly shoehorning the Librem 5 into numerous threads no matter how much of a non-sequitur it takes, has me suddenly paying more attention these days to what's coming from the Purism camp. The more I do the more disingenuous the rhetoric seems.
It may just be a coincidence, but for a project with such a fraught history and tarnished reputation, it doesn't do anything to increase my trust in it.
I have to admit that I had a kind of knee-jerk reaction there, as this "debate" is very often brought up in FUD pieces without much substance behind it.
No true Scotsman would ever use binary blobs.