This only talks about the Fairphone. The only mention of PinePhone and Librem 5 is that according to the author providing schematics is not enough to call it “open hardware”.
It’s a misconception that the Librem 5 and Pinephone are open source. Their hardware components including the CPU, GPU, Wi-Fi, Bluetooth, cellular, etc.
The word “open source” usually refer to software, but ok. Those companies provide schematics for the motherboard and Librem 5 also provides PCB designs. But they don’t provide those for the chips, so that is correct. I don’t think anyone says otherwise.
Their hardware/firmware/software is all much less private and secure
What? :D The person doesn’t even explain why. Then they talk about physical killswitches misunderstanding what they are really for (they are there so that you don’t have to fully trust the software/firmware to turn something off - especially the proprietary modem firmware) and claim that all of those devices are insecure somehow, because on GNU/Linux any program can access the microphone. But that’s exactly why we use free software, isn’t it?
I’m sorry, but this is ridiculous, so I won’t read the rest. I’m not a hardware expert, though, so maybe some of their other points were valid. I guess those phones’s hardware is probably as secure as any other computer’s. I don’t think anyone says otherwise, but the killswitches are always a good idea.
Pinephone doesn’t have features like IOMMU isolation or even verified boot. Also as a matter of fact, permission control, unless you’re using flatpak/bwrap/firejail is actually better on Android than Linux. Plus long before the first usable part of Linux written in Rust was released, large parts of low level AOSP code were already rewritten in it.
PinePhone’s modem is isolated through USB. I don’t know about other components, though.
Also as a matter of fact, permission control, unless you’re using flatpak/bwrap/firejail is actually better on Android than Linux. Plus long before the first usable part of Linux written in Rust was released, large parts of low level AOSP code were already rewritten in it.
I understand that, but none of that makes GNU/Linux insecure and that’s what the GrapheneOS developer has claimed. They said it was insecure. I can’t say if GrapheneOS is more secure than GNU/Linux, because I don’t know enough about it or how libre it is, so I’m not arguing with that. It’s possible that it is (I would have to check opinions of independent experts). My point was that those people can’t be taken seriously if they make such ridiculous claims. I don’t know if I can believe anything they say.
This person says that Android (a proprietary operating system) is more secure than GNU/Linux. Ridiculous. It’s nice that Android has all those security features, but it’s still proprietary, so can’t be trusted. Keep in mind that he didn’t just say GrapheneOS, which might be entirely free software, so unlike Android, it might have a chance to be secure.
PureOS also uses linux-libre. This will prevent the user from loading any proprietary firmware updates, which just so happens to be almost all of them.
I don’t think this is true at all. The firmware in Librem 5 is stored on some separate chips and I think users can flash new firmware to them. But even if he was correct, I’m not entirely convinced that you get a security benefit from being able to change from one proprietary firmware version to another, since both those versions can’t be trusted. I will need to read more about this at some point.
Then he says the same stupid thing about the killswitches and just like the GrapheneOS dev pretends that they have no benefit. I’m starting to wonder if they are the same person. Never mind, I can now see that he quotes him in his GNU/Linux article, so he is probably just repeating after that guy.
The microphone kill switch is useless since audio can still be gotten via the sensors (such as the gyroscope or accelerometer).
I doubt that. I’m pretty sure that in reality the audio levels you can get from those sensors is too low to be usable (unlike a microphone). Here is a fun fact that this person doesn’t know about. The microphone killswitch on one of the PinePhone versions doesn’t actually kill the microphone, it just disconnects the amplifier or something. So the microphone technically still works, but it’s not gonna pick anything up, even if you yell directly at it. I know this, because people have figured it out from looking at the schematics and tested it.
The unorthodox way in which the Librem 5 attempts to isolate the modem is via the Linux kernel USB stack, which is not a strong barrier, as shown in the Linux article.
I can’t find where he explains this, but I think the problem was that he just doesn’t know about USBGuard. The author’s two articles are full of errors or false information, they don’t understand that proprietary systems can’t be considered secure. I see no reason to trust their opinions on security.
AOSP is not proprietary. Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.
And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.
Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.
Being libre is the basic requirement to even being considering something as secure, but it is not enough by itself. I agree.
And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.
Generally that’s what people say, but is it really that simple? A new firmware version might fix some known vulnerability, but its developers might have also introduced a new one on purpose. So a known vulnerability might have been fixed, but you might have gotten a new one that isn’t yet known. So I don’t know if that’s really so much better. Also I assume that the only way to exploit those vulnerabilities is through malware? But if you only run free software, the risk of getting malware is very small.
I agree with you that every proprietary software must be presumed to be a trojan with a backdoor but still some critical, low level free software being decades old C codebases with oftentimes millions of LoC has proven to be a double-edged sword where on one hand most of it is super optimized (just compare launch times of lightdm or GDM to e.g. regreet) but on the other hand by pure probabilistics it’s more likely to contain some vulnerabilities accumulated over the years of imperfect code reviews.
Sure I believe it’s worth hoping and supporting initiatives that might one day bring us to something like RISC-V smartphone with high level of hardware security that’d run something like Alpine (a minimalist distro) but based on Redox OS. Maybe that’ll come true in a couple of years.
But right now GrapheneOS even despite proprietary hardware is the best option security-wise, unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!), but the optimization of basically any software is going to suck so badly. And forget compiling any Rust code on the currently available RISC-V CPUs. want memory safety? pick something with a VM/GC instead.
You are right that some projects are more likely to have vulnerabilities than others. But at least with libre software any expert can look into it, fix it and distribute the patch to others.
I don’t have much hope for RISC-V, since most SBCs that use it seem to require a custom Linux kernel, so it’s the same problem that we have with ARM. Maybe things will get better at some point, but unfortunately most people don’t seem to care. I haven’t heard of Redox before. It looks interesting, but it’s a shame that it’s not under a GPL license.
But right now GrapheneOS even despite proprietary hardware is the best option security-wise
Maybe you are right and Graphene with F-Droid is the most secure option. I don’t think it’s necessary to have all of its features, since we don’t have them on desktop either, but it would be nice to have them on mobile for sure.
unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!)
That’s crazy! Is RISC-V so much more efficient than ARM?
And forget compiling any Rust code on the currently available RISC-V CPUs
Apparently there are multiple crates but no official toolchain so unsure how that works in practice. You’re still limited to either waiting for hours or cross-compiling though since currently the best available RISC-V CPU is quad-core 2.5 GHz (which still looks hella promising, 2 years ago best we had was 1.5 GHz dual-core). This blog post by Drew DeVault goes into detail of how daily driving RISC-V looked like 2 years ago. I suppose these days it looks noticeably better, especially since Samsung and Apple have been eyeing RISC-V adoption due to ARM consortium doing some monopolistic shit with their licensing. But eventually, so far, not enough critical mass was attained and afaik the whole drama mellowed out a bit.
Regarding the energy efficiency, some experimental units managed to even be manifold better at this:
But on the other hand, studies involving some RISC-V models show quite the contrary when it comes to energy efficiency, although the thermal performance is much better:
And below is a screenshot from a comparison by Gary Explains using more microcontroller models. So it really depends on the specific model, but it seems like the design of RISC-V has some solid potential to beat ARM in terms of energy and thermal efficiency.
https://grapheneos.social/@GrapheneOS/111957964224325239
https://grapheneos.org/faq#future-devices
https://grapheneos.social/@GrapheneOS/111738765361100063
https://grapheneos.social/@GrapheneOS/111676448278523353
https://grapheneos.social/@GrapheneOS/111676423446810227
https://social.linux.pizza/@piracyy/111712189066209594
https://grapheneos.social/@GrapheneOS/111975424959573607
This only talks about the Fairphone. The only mention of PinePhone and Librem 5 is that according to the author providing schematics is not enough to call it “open hardware”.
No mention of PinePhone or Librem 5.
Same as above.
The word “open source” usually refer to software, but ok. Those companies provide schematics for the motherboard and Librem 5 also provides PCB designs. But they don’t provide those for the chips, so that is correct. I don’t think anyone says otherwise.
What? :D The person doesn’t even explain why. Then they talk about physical killswitches misunderstanding what they are really for (they are there so that you don’t have to fully trust the software/firmware to turn something off - especially the proprietary modem firmware) and claim that all of those devices are insecure somehow, because on GNU/Linux any program can access the microphone. But that’s exactly why we use free software, isn’t it?
I’m sorry, but this is ridiculous, so I won’t read the rest. I’m not a hardware expert, though, so maybe some of their other points were valid. I guess those phones’s hardware is probably as secure as any other computer’s. I don’t think anyone says otherwise, but the killswitches are always a good idea.
Pinephone doesn’t have features like IOMMU isolation or even verified boot. Also as a matter of fact, permission control, unless you’re using flatpak/bwrap/firejail is actually better on Android than Linux. Plus long before the first usable part of Linux written in Rust was released, large parts of low level AOSP code were already rewritten in it.
https://madaidans-insecurities.github.io/linux-phones.html
PinePhone’s modem is isolated through USB. I don’t know about other components, though.
I understand that, but none of that makes GNU/Linux insecure and that’s what the GrapheneOS developer has claimed. They said it was insecure. I can’t say if GrapheneOS is more secure than GNU/Linux, because I don’t know enough about it or how libre it is, so I’m not arguing with that. It’s possible that it is (I would have to check opinions of independent experts). My point was that those people can’t be taken seriously if they make such ridiculous claims. I don’t know if I can believe anything they say.
This person says that Android (a proprietary operating system) is more secure than GNU/Linux. Ridiculous. It’s nice that Android has all those security features, but it’s still proprietary, so can’t be trusted. Keep in mind that he didn’t just say GrapheneOS, which might be entirely free software, so unlike Android, it might have a chance to be secure.
I don’t think this is true at all. The firmware in Librem 5 is stored on some separate chips and I think users can flash new firmware to them. But even if he was correct, I’m not entirely convinced that you get a security benefit from being able to change from one proprietary firmware version to another, since both those versions can’t be trusted. I will need to read more about this at some point.
Then he says the same stupid thing about the killswitches and just like the GrapheneOS dev pretends that they have no benefit. I’m starting to wonder if they are the same person. Never mind, I can now see that he quotes him in his GNU/Linux article, so he is probably just repeating after that guy.
I doubt that. I’m pretty sure that in reality the audio levels you can get from those sensors is too low to be usable (unlike a microphone). Here is a fun fact that this person doesn’t know about. The microphone killswitch on one of the PinePhone versions doesn’t actually kill the microphone, it just disconnects the amplifier or something. So the microphone technically still works, but it’s not gonna pick anything up, even if you yell directly at it. I know this, because people have figured it out from looking at the schematics and tested it.
I can’t find where he explains this, but I think the problem was that he just doesn’t know about USBGuard. The author’s two articles are full of errors or false information, they don’t understand that proprietary systems can’t be considered secure. I see no reason to trust their opinions on security.
AOSP is not proprietary. Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.
And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.
I never said that it was.
Being libre is the basic requirement to even being considering something as secure, but it is not enough by itself. I agree.
Generally that’s what people say, but is it really that simple? A new firmware version might fix some known vulnerability, but its developers might have also introduced a new one on purpose. So a known vulnerability might have been fixed, but you might have gotten a new one that isn’t yet known. So I don’t know if that’s really so much better. Also I assume that the only way to exploit those vulnerabilities is through malware? But if you only run free software, the risk of getting malware is very small.
I agree with you that every proprietary software must be presumed to be a trojan with a backdoor but still some critical, low level free software being decades old C codebases with oftentimes millions of LoC has proven to be a double-edged sword where on one hand most of it is super optimized (just compare launch times of lightdm or GDM to e.g. regreet) but on the other hand by pure probabilistics it’s more likely to contain some vulnerabilities accumulated over the years of imperfect code reviews.
Sure I believe it’s worth hoping and supporting initiatives that might one day bring us to something like RISC-V smartphone with high level of hardware security that’d run something like Alpine (a minimalist distro) but based on Redox OS. Maybe that’ll come true in a couple of years.
But right now GrapheneOS even despite proprietary hardware is the best option security-wise, unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!), but the optimization of basically any software is going to suck so badly. And forget compiling any Rust code on the currently available RISC-V CPUs. want memory safety? pick something with a VM/GC instead.
You are right that some projects are more likely to have vulnerabilities than others. But at least with libre software any expert can look into it, fix it and distribute the patch to others.
I don’t have much hope for RISC-V, since most SBCs that use it seem to require a custom Linux kernel, so it’s the same problem that we have with ARM. Maybe things will get better at some point, but unfortunately most people don’t seem to care. I haven’t heard of Redox before. It looks interesting, but it’s a shame that it’s not under a GPL license.
Maybe you are right and Graphene with F-Droid is the most secure option. I don’t think it’s necessary to have all of its features, since we don’t have them on desktop either, but it would be nice to have them on mobile for sure.
That’s crazy! Is RISC-V so much more efficient than ARM?
Is that not possible?
Apparently there are multiple crates but no official toolchain so unsure how that works in practice. You’re still limited to either waiting for hours or cross-compiling though since currently the best available RISC-V CPU is quad-core 2.5 GHz (which still looks hella promising, 2 years ago best we had was 1.5 GHz dual-core). This blog post by Drew DeVault goes into detail of how daily driving RISC-V looked like 2 years ago. I suppose these days it looks noticeably better, especially since Samsung and Apple have been eyeing RISC-V adoption due to ARM consortium doing some monopolistic shit with their licensing. But eventually, so far, not enough critical mass was attained and afaik the whole drama mellowed out a bit.
Regarding the energy efficiency, some experimental units managed to even be manifold better at this:
https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/
But on the other hand, studies involving some RISC-V models show quite the contrary when it comes to energy efficiency, although the thermal performance is much better:
https://link.springer.com/article/10.1007/s11227-024-05946-9
And below is a screenshot from a comparison by Gary Explains using more microcontroller models. So it really depends on the specific model, but it seems like the design of RISC-V has some solid potential to beat ARM in terms of energy and thermal efficiency.