| |
| ▲ | fsflover a day ago | parent [-] | | > A GrapheneOS phone is just as open as the Librem 5. No, it's not. Try to run a completely free OS on you hardware (like Replicant) and watch the lack of camera, GPS and more. Related discussion for other: https://news.ycombinator.com/item?id=47942070 | | |
| ▲ | 555244466 a day ago | parent | next [-] | | The Librem 5 uses a bottom of the barrel, standard industrial CPU from 2017 with no updates. It is no more open than a Google Pixel or any other mobile device. it lacks proper updates, isolated radios, and any form of hardening.
The kill switches are also useless if your device is fully compromised and turned into a spying device, all of your data is already gone. The only thing the switches do as a last resort is block voice recording, which is an improper way of doing it since speakers are essentially just microphones in reverse. | | |
| ▲ | fsflover a day ago | parent [-] | | > CPU from 2017 with no updates This is false. Please stop writing false statements without any links. NXP promises to produce the i.MX 8M Quad until Jan. 2033. The support will be even longer. > it lacks proper updates This is FUD. > isolated radios They are isolated with USB. This might be slightly weaker than IOMMU, but for me the benefit of freedom is worth it. There is no shared memory. > it lacks proper updates, isolated radios, and any form of hardening FUD and false information. Please stop this. > The kill switches are also useless if your device is fully compromised This is false again. It doesn't matter how much my device might be compromised. The attacker will not get any access to the shut down sensors, radios or voice/video, if I use the three kill switches. > since speakers are essentially just microphones in reverse Librem 5 speakers do not support this. | | |
| ▲ | kuhsaft 21 hours ago | parent [-] | | Not OP, but > This is false. Please stop writing false statements without any links. NXP promises to produce the i.MX 8M Quad until Jan. 2033. The support will be even longer. I think they meant that the processor itself is old. It supports ARMv8 and is lacking the enhanced memory protection and execution features of the ARMv9-A processors on newer phones. > This is false again. It doesn't matter how much my device might be compromised. The attacker will not get any access to the shut down sensors, radios or voice/video, if I use the three kill switches. The problem is that your device can be compromised quite easily and without you knowing. The kill switches are moot at that point. | | |
| ▲ | fsflover 21 hours ago | parent [-] | | The kill switches will work independently on a compromise. Why are they moot? Also, it's possible to completely reflash the device in case of doubt. "quite easily" strongly depends on what exactly you are doing. For example, if I use Firefox with NoScript, then it is not very easy. | | |
| ▲ | kuhsaft 20 hours ago | parent [-] | | > The kill switches will work independently on a compromise. Why are they moot? Kill switches only work as a security feature when you activate them before you know you're compromised. But that's impossible. It's a reactive "security" feature not a proactive one. > For example, if I use Firefox with NoScript, then it is not very easy. Security vulnerabilities aren't only JS related. https://www.mozilla.org/en-US/security/advisories/mfsa2026-3... https://www.mozilla.org/en-US/security/advisories/mfsa2026-3... Adding an extension that can access all your browsing data doesn't seem very secure either. Required permissions: - Access browser tabs - Access browser activity during navigation - Access your data for all websites | | |
| ▲ | fsflover 20 hours ago | parent [-] | | Good links, thank you. I agree that my protection is not perfect in general. Fortunately I do not open random websites on my phone; I have my laptop with Qubes OS for that. > Adding an extension that can access all your browsing data doesn't seem very secure either. This is not just a random extension but an officially recommended one, https://support.mozilla.org/en-US/kb/recommended-extensions-.... It's also regularly verified by the community. I trust it as I trust Firefox. | | |
| ▲ | kuhsaft 20 hours ago | parent [-] | | > Fortunately I do not open random websites on my phone That's the main use for almost everyone. You're suggesting people use a less secure device and are stating that it's more secure if they don't use it in the way it's mostly used? That doesn't sound like freedom. That sounds like living in paranoia. You bring up FUD in so many comments, but you seem to be living it. Ironically though, you choose to use systems that enable FUD when there are systems that let you not worry. There are people building secure software and hardware, so people don't have to live in fear when using their devices. That's the freedom that many people care about. There's the freedom to shoot yourself in the foot. Most people don't care about that. | | |
| ▲ | fsflover 18 hours ago | parent [-] | | You missed that I do not recommend Librem 5 to "almost everyone". We are not on a normies forum but on HN. Also, I do not recommend Librem 5, when somebody asks for a secure device. I mention it, when somebody asks about alternatives to the duopoly, a possibility to have a full, general-purpose computer in a pocket allowing you to tinker with it, or wants to run GNU/Linux baremetal. Such people aren't the audience of GrapheneOS anyway. And I'm not against GrapheneOS. I never said it was less secure than Librem 5 for typical tasks. I only say, that if you want to have a third option, you can have it today. There will be compromises, which can be dealt with by technical users. | | |
| ▲ | kuhsaft 18 hours ago | parent [-] | | > We are not on a normies forum but on HN. Being on HN does not mean that you are familiar with the intricacies of hardware and low-level software. > I only say, that if you want to have a third option, you can have it today. There will be compromises, which can be dealt with by technical users. I think it’s irresponsible to promote it as an alternative device without noting that it’s less secure and full of footguns. Also, disingenuous to promote it as FOSS when it only fits that definition under FSF technicalities. And lastly, to promote it as more open than phones with AOSP distros that utilize the same set of proprietary hardware, just with different communication mechanisms/boundaries. | | |
| ▲ | fsflover 16 hours ago | parent [-] | | This is not a forum with legal advises. I inform people about an option, which they asked for. GNU/Linux phones have a similar security approach to GNU/Linux on desktop. People explicitly seeking GNU/Linux should know this. They can also ask or search the Internet. > I think it’s irresponsible to promote it as an alternative device without noting that it’s less secure and full of footguns I disagree with you here. Informing about options is better than not informing. "Less secure" depends on a threat model. GNU/Linux on desktop is working well enough for millions of people. So it is a viable security approach for many. Saying that your threat model is the only one that should exist and be promoted is crazy. > only fits that definition under FSF technicalities This is one of the strictest definitions there is. By which definition does GrapheneOS run FLOSS? > same set of proprietary hardware, just with different communication mechanisms/boundaries More choice is always good, isn't it? If it is not for you, you are free to use and promote the duopoly. (Yes, I consider AOSP obeying Google's development strategy long term. It will not end well. See: this topic.) | | |
| ▲ | kuhsaft 6 hours ago | parent [-] | | Relevant conversation about those technicalities: https://news.ycombinator.com/item?id=30042576 Though with a username of fsflover, I think you'll be biased. Also, another relevant thread (that you were even a part of!) discussing the pointlessness of what Purism did to fit the technicalities: https://news.ycombinator.com/item?id=29841267 It's actually worse than I thought. There's the initramfs /lib/firmware loading workaround for the FSF certification of the OS. But even before that there is code run by the main CPU that loads instructions for the secondary core to load a blob from separate flash memory to pass to the memory controller to initialize it. All that just to attempt to fit the technicalities of the FSF RYF hardware certification while still loading a blob like every other phone microprocessor. --- It's interesting that I could make a device that burns efuses to make it obsolete and it could still be considered FSF Respects Your Freedom certified. |
|
|
|
|
|
|
|
|
|
| |
| ▲ | TommyTran732 a day ago | parent | prev [-] | | Quite frankly, the whole Librem ecosystem is significantly less "open" than GrapheneOS or any desktop Linux variant to anyone who look at things objectively instead of using weird FSF semantics. Instead of loading firmware in sensible manner like GrapheneOS or desktop Linux distros with the linux-firmware package, they keep PureOS "free of blobs" by having the bootloader inject all of the blobs into memory in an extremely shady manner. Since when was having the bootloader tamper with system memory about freedom and openness? Oh, and they even have the audacity to market this as the "firmware jail" as if it is any more contained than the linux-firmware package too. Truly impressive stuff. | | |
| ▲ | fsflover a day ago | parent [-] | | > Quite frankly, the whole Librem ecosystem is significantly less "open" than GrapheneOS or any desktop Linux variant to anyone who look at things objectively instead of using weird FSF semantics. You will have a point when your Google phone runs Replicant. Now this is just empty words, i.e., FUD. Which blobs are running on the Librem 5 CPU? Which blobs are running on GrapheneOS CPU? | | |
| ▲ | TommyTran732 21 hours ago | parent | next [-] | | Which blobs are running on the Librem 5 CPU? Which blobs are running on GrapheneOS CPU? Both the Pixel and Librem 5 have firmware baked into the SoC that is executed. On GrapheneOS, the firmware is signed and updated along with the OS. On the Librem 5, the firmware for Wifi/Bluetooth is stored on a NOR chip, which is read from and mounted into the OS by the initramfs into /lib/firmware. Not-withstanding the above, Librem 5 components such as the USB controller, touch screen controller, radios, battery, etc simply have closed-source firmware baked in (stored on some flash chip on these components), but it doesn't mean that they are not there or in use. In both cases, components either do not get proper firmware updates from the OS, or they are too old/low quality to get any firmware updates from the vendors to begin with. Storing firmware on the component is also a less secure approach than having signed firmware loaded by the OS, as it now means that these components have persistent storage which can be attacked. Aside from all of the above, they also use a dedicated CPU core to run firmware blobs for things like memory training. In essence, what the Librem 5 has achieved is shuffling proprietary firmware storage around instead of eliminating their existence or execution. It is not any more "free" or "open" than anyone else while also being less secure. | | | |
| ▲ | kuhsaft 21 hours ago | parent | prev [-] | | > Which blobs are running on the Librem 5 CPU? https://source.puri.sm/Librem5/fw https://source.puri.sm/Librem5/fw/firmware-librem5-nonfree https://source.puri.sm/Librem5/librem5-fw-jail/-/tree/pureos... > Which blobs are running on GrapheneOS CPU? Depends on the phone. Arguably though, GrapheneOS has the legacy of years of thousands of security researchers working to secure Android from third-party network and GNSS modules. --- Just so you know, I'm not using Librem or GrapheneOS. I'm looking at this objectively and have no skin in the game. | | |
| ▲ | fsflover 21 hours ago | parent [-] | | In this case I do not understand why you are ignoring the words of a Librem 5 developer saying that no blobs are running on the main CPU: https://news.ycombinator.com/item?id=47943487 | | |
| ▲ | kuhsaft 20 hours ago | parent [-] | | I'll take his word that no blobs are running on the main CPU. But the process itself is error prone. It's mounting flash storage with blobs into the filesystem of the OS. The OS can load modules directly from the storage. > 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). "unless you put some there by yourself, which you're of course free to do" also means unless someone else puts one there. --- I think the "firmware jail" loader also uses Smart Direct Memory Access (SDMA)? --- You can run blobs on the main CPU with strong isolation with TEE and other hardware security features. | | |
|
|
|
|
|
|
