You know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable.
> DomU (App Qubes) also run the Linux kernel and are just as vulnerable.
I think you misinterpret the Qubes approach to security. If you do everything in one VM, you get no protection from the virtualization. Moreover, there is no sudo password by design: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-s... This is not how to use Qubes.
You need to compartmentalize your workflows. It doesn't matter if my disposable VM is compromised. My secrets are in another, offline VM, where I never run anything. There is no way to use the discussed vulnerability, if one uses Qubes according to docs. See examples here: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to...
So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.
> So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash".
> "In-VM attack only". That's disingenuous.
It's really not. Hardening of guest OSes is out of scope of Qubes. You are supposed to not combine trusted and untrusted actions in a single VM, so intra-VM security is really secondary. I really recommend you to read my link about organizing the workflows.
You have a good point concerning the integrity issues though.
> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.
And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.
Ironically, I think regulation is what keeps them in power. They are major companies that comply with government regulations. Why would the government regulate to allow people to have devices that forgo government regulations?
If you want a successful mainstream operating system. It needs to work within the rules of society. It needs to comply with regulations. It needs to cooperate with mobile device manufacturers and network operators.
These small grassroots operating systems fail because, to do all those things, you need to be pragmatic.
The next major operating system will be backed by a business or government.
> If you want a successful mainstream operating system. It needs to work within the rules of society. It needs to comply with regulations. It needs to cooperate with mobile device manufacturers and network operators.
Which can be done with a small team by building on top of AOSP, like GrapheneOS does. How is that not pragmatic?
I would group GrapheneOS with Android. If you handed a layperson a GrapheneOS phone and asked them what OS was on the phone, they would probably say Android.
But considering it as a separate OS, I wouldn’t consider it mainstream. It’s not on any device by default. And it has an estimated 250k users out of ~3.9 billion Android users, or 0.0064%. It might seem mainstream for the tech community, but it goes to show how small the tech community is.
It might be mainstream once Motorola, a corporation, starts releasing phones preinstalled with it.
> If you handed a layperson a GrapheneOS phone and asked them what OS was on the phone, they would probably say Android.
Agreed, that's exactly it! The pain points of GrapheneOS/LineageOS are due to the fact that device manufacturers don't allow proper support (typically the bootloader story) and that big companies like bank choose (more and more) to ban whatever is not signed by Google (through Play Integrity). I argue that those things should be regulated.
> And it has an estimated 250k users out of ~3.9 billion Android users
I think it's more than 250k, but let's go with that. There are Android manufacturers that are in the same order of magnitude. What would you say if your bank banned your Fairphone (that runs Stock Android signed by Google) just because it is a Fairphone, and "a few hundred thousands of users is marginal"? I think even the regulators would directly understand how that is a problem. Microsoft Office shouldn't be allowed to just ban Framework computers running Windows just because they don't think Framework is big enough, right?
It's not "Google vs alternative Androids": there are many Android flavours, from Samsung to Sony through Xiaomi and Fairphone. We don't tell Fairphone that they have to be mainstream before they get the right to sell Android phones.
The very reason alternative Androids are (slightly) harder to use is that they are not mainstream, so banks ban them for no reason because they can, and Google is happy to do nothing about it because those are competitors.
> What would you say if your bank banned your Fairphone (that runs Stock Android signed by Google) just because it is a Fairphone, and "a few hundred thousands of users is marginal"? I think even the regulators would directly understand how that is a problem.
We're talking about different operating systems on devices, not the same operating system on different devices. Also, it's not the same as modifying the stock OS that does work with a non-stock OS that doesn't.
The hardware analogy would be closer to having a computer, replacing the GPU, then getting angry that there isn't a driver for the GPU that supports that operating system.
> Microsoft Office shouldn't be allowed to just ban Framework computers running Windows just because they don't think Framework is big enough, right?
Apple doesn't allow their operating systems to run on non-Apple devices. Likewise, Microsoft does have the right to restrict what systems Windows can run on. Any software provider has the right to limit their software's usage.
Conversely, device manufacturers have the right to restrict what operating systems can run on them. E.g. the majority of devices other than desktops and laptops.
Whether or not you should be able to run any software on any hardware is another debate. Even if you support that stance, there is a hard limit to user freedom via government regulations on hardware/software such as any RF transmitting device and cryptographic devices.
---
Google Android and iOS are regulated by governments.
With the upcoming age verification requirements made by governments (let’s not debate that here), only the corporate entities that governments can regulate will be allowed.
We can regulate to allow alternative Android OSes, but the alternatives will be ones that follow government regulations.
> Also, it's not the same as modifying the stock OS that does work with a non-stock OS that doesn't.
Again, the non-stock OS works, except for the parts that cannot work because they are being actively blocked. It's not that they are not ready: they are ready, but the mainstream players are blocking them.
> The hardware analogy would be closer to having a computer, replacing the GPU, then getting angry that there isn't a driver for the GPU that supports that operating system.
I disagree. It would be like having a computer, replacing the GPU with another GPU that is 100% compatible, but that doesn't run because the OS checks it and says "it would work, but it is not a GPU I like, so I will block it".
> Conversely, device manufacturers have the right to restrict what operating systems can run on them. E.g. the majority of devices other than desktops and laptops.
My point is that they shouldn't. I am saying that it would be better for society if we regulated that.
> We can regulate to allow alternative Android OSes, but the alternatives will be ones that follow government regulations.
> My point is that they shouldn't. I am saying that it would be better for society if we regulated that.
Playing devil's advocate here. Why should software developers be allowed to restrict where/how their software is used, while hardware developers can't restrict where/how their hardware is used?
Yeah it's a good question, and in the end it's arbitrary. I would say:
1. Because e-waste.
2. Because if I buy shoes, I own the shoes. If I buy an electronic device, I own the electronic device. It should not be legal to add a mechanism in my shoes that allows the manufacturer to make them stop working as shoes whenever they want.
Hardware manufacturers don't open source their firmwares because they see it as a competitive advantage (why not, sometimes). But they should allow someone else to write their own firmware. That is, they should provide minimum support for that. Right now it's not that they don't provide minimum support: they actively work on making it technically impossible to do. And the law, through the DMCA and the likes, makes it illegal to reverse engineer.
I’d say that it’s more of a cartel. The mobile network operators, the mobile device manufacturers, the mobile OS developers. They all work together in their consortiums to make money together.
It’s a bit obvious when you look at the supply chain where “competitors” supply each other with parts.
RF hardware is heavily regulated by governments, so a truly open-for-consumer hardware solution won’t exist.
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.
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
> 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.
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.
> 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.
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.
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.
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.)
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.
> Kill switches only work as a security feature when you activate them before you know you're compromised. But that's impossible.
Indeed, if you use the kill switches in a stupid way, you get no benefit from them. I use them whenever I want to be sure that I can't be tracked or listened to, either because of a potentially compromised device or closed modem that can connect to towers without my knowledge. In other words, they are a proactive feature. I can get 100% privacy whenever I want, independently on any software, which in principle might always get secretly compromised one way or another. Even the amazing, secure GrapheneOS!
How can you be sure your modem on GrapheneOS doesn't send your location to the mothership all the time, even in an "airplane mode"?
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.
> 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?
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.
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.
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
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.
And the firmware for Bluetooth/Wifi is loaded in by having the initramfs read it from the NOR flash, mount it in /lib/firmware, then it is business as usual like a desktop Linux distribution.
It's not something special. It's just a hackjob. They shuffle the files around and made it much harder to update.
I think it’s because the Microsoft Store barely has any apps that users use. The Microsoft Store didn't support the Win32 API, so developers had to rewrite their apps.
Wait, you lost me somewhere. The MS store didn't support the old way of doing things, people had to rewrite their software; yet iOS was... new as well? People had to start from scratch and so that worked?
iOS existed before the Microsoft Store. The apps developed were brand new. No backlash from a new SDK and platform.
Windows RT is closer to iPadOS though. For iPadOS, apps just worked since it’s based off of iOS.
The Microsoft Store only supported a new half-baked SDK that limited what applications were capable of. Developers already had Win32 apps and rewriting them with the new SDK seemed pointless just to support what seemed like a needless limitation.
People forget how much the mobile hardware industry relies on non-free infrastructure. Infrastructure developed by companies that make the standards. You really can't make a good open-source phone because you, pretty much, have to play by the rules of the companies in these consortiums.
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.
It's basically taking the blobs that would be normally shipped with the OS in a sensible manner, shuffle it around, then calling it "free" while the same blobs would still be there, just on different flash storage chips.
Because it's true, and I know what he said, I am not confused at all. Did you not read anything at all?
On the Librem laptop, the tampering is done by PureBoot and inject into /run/firmware. The other user was linking the stuff with the laptop.
*On a Librem 5, it is stored on a separate chip, then they read it with the initramfs, then mount it on top of the regular filesystem at /lib/firmware*.
For the record, the "jail" only exists so PureOS (or any other distro) does not have to distribute any blobs within its repositories or include them in their images - though distros still can if they choose to, like postmarketOS does for example. There's very little difference between a firmware blob that's stored in a peripheral's internal flash, NOR flash or OS rootfs when it comes to user freedom, in the end it gets executed the same way on the same hardware. Having a separate place for these blobs only simplifies their management and allows to put a clear distinction of what's free and what's not. The important thing is that, regardless of whether the "jail" is used or not, there's not a single blob that runs on the user's CPU within the user's system on the Librem 5, which isn't a unique property for a phone but rare nevertheless; the peripherals are a different thing and Purism has never claimed that there are no blobs there (in fact, the existence of e.g. the DDRC blob was being highlighted already in very early development).
(also, the NOR flash itself already had to be there because that's what TPS65982 boots from, so the "jail" is just using the 4MB storage that would otherwise remain mostly empty)
I'm tired of arguing with you. I see no effort from your side to come to some understanding or to clarify anything. Here's why.
> On the Librem laptop, the tampering is done by PureBoot
What do you mean by "tampering" here? Is uploading firmware to peripherals a "tampering"? Why is this a problem, compared with other devices? Does anybof those blobs run on the CPU? I don't understand what you are trying to say.
> If you don't know that the firmware for components/peripherals can either be
I do know. How is this relevant? I never denied that the device does have some proprietary blobs.
> I see no effort from your side to come to some understanding or to clarify anything.
Accusing me of your own sins.
> What do you mean by "tampering" here? Is uploading firmware to peripherals a "tampering"? Why is this a problem, compared with other devices? Does anybof those blobs run on the CPU? I don't understand what you are trying to say.
On the laptop, messing with the system memory (/run) and dumping firmware packages in there instead of just shipping it with the OS using a sensible approach like the linux-firmware package is a hack-job and nasty practice. And since it's messing with system memory, that's your "tampering" right there.
On the phone, once again, instead of using a normal, sensible approach like the linux-firmware package on desktop Linux or the vendor partition on Android, they just store the firmware in some chip, then have the OS (or more accurately, the initramfs) mount the content of the chip using overlayfs in /lib/firmware anyways. It's another implementation of the same hackjob. That, and they combine it with using peripherals whose firmware are stored inside of internal flash chips so the OS doesn't have to be shipped with firmware packages that it then needs to load into the peripherals.
What does this entire exercise do for freedom or openness? *Asbolutely nothing*. It's called shuffling the firmware storage around so you can market the OS as "blob free" when it's literally meaningless. If anything, it makes it harder to audit and figure out which firmware version is being run than if the firmware were to be shipped along with the OS.
---
To dumb it down a notch if you really do not understand what I am trying to say:
This makes about as much sense as if I were to take the SSD out of my laptop, destroy the M.2 socket, then advertise it as a "storage free and OS free laptop". To use the laptop, you must plug in external storage through the USB port and load up an OS. But hey, since there is no SSD or OS on the "main" part of the laptop, I am now qualified for some made up certification and can advertise my stuff as "freeing" the user from the shackles of the evil storage system and nastiness of having an OS. Definitely more "open" than other laptops.
> If anything, it makes it harder to audit and figure out which firmware version is being run than if the firmware were to be shipped along with the OS.
For fsflover, what Purism is doing is moving the non-auditable part of the OS onto a separate storage device so that they can claim that the OS is "Fully Auditable" and FSF certified even though the non-auditable and non-free part is mounted into the OS filesystem during boot. It's deceptive marketing and you're spreading that marketing.
Other open mobile OSes aren't trying to hide the fact that there needs to be proprietary components for hardware.
The only thing I concede is that the drivers are FOSS, which is why some performance and functionality is degraded compared to phones using non-free drivers. You could develop an AOSP phone using the same FOSS drivers as well, you'll just have the same issues.
> what Purism is doing is moving the non-auditable part of the OS onto a separate storage device so that they can claim that the OS is "Fully Auditable" and FSF certified even though the non-auditable and non-free part is mounted into the OS filesystem during boot.
Yup, that's part of it.
But remember, even if they didn't do it, there's still a matter of them by using components with internal flash storage for the firmware instead of shipping firmware with the OS and letting the OS upload them. Like that's not a hackjob like the /lib/firmware or /run/firmware stuff or anything, but it's not like it's any more "open" than any other system, if not being a bit more opague. Of course the marketing would still be deceptive then.
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.
> 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.
>> 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.
> 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 explained in the other comment why I thing that GNU/Linux phones are relevant, where I posted. You can discuss my arguments, but you can't just dismiss them all with a single general wording like this.
> a project with such a fraught history and tarnished reputation
Another unsubstantiated attack on a free software project from the GrapheneOS crowd, with no links or argumentation.
> 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 seems to be mainly fsflover. You can search “Librem 5” messages in HN and it’s flooded with messages by them.
At least I don't reply to every comment about GrapheneOS with "it's not as free as Librem 5 and you have to pay Google, and you have to rely on blobs running on the main CPU" etc. This is exactly what the GrapheneOS crowd is doing with my comments.
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.
The vendor lock-in scenario for desktop hardware already exists with the latest x86 generation of gaming consoles. Gaming consoles are locked down because the hardware is subsidized with the expectation of revenue from the digital marketplaces they provide.
The yet-to-be-released Steam Machine is not subsidized and is unlocked. Steam is a OS agnostic digital marketplace, so it doesn't matter what OS you install on the machine.
Microsoft doesn't see a threat in allowing other OSes on their Surface hardware because the majority of their revenue comes from M365.
It's just market forces really. In the end, phones provide enough utility for the majority of users while being locked down. There's nothing stopping you from buying a fully-open phone, but there's just very little utility in it for the majority of users.
This is a very HN view of Android. The "openness" of Android was for mobile device manufacturers, not app developers and end-users. Android's prominence was driven by the myriad of low-cost Android devices by multiple device manufacturers, whereas iOS is only available via iPhones.
The vast majority of users don't care about "openness" of the OS. They care about the utility of their phone in everyday life.
Can I access digital payment systems, social media apps, and entertainment apps? How's the camera on the phone? How big is the screen? Is it waterproof? How expensive is it?
These are the questions the majority of phone buyers care about. Not, can I download an app off of a random website and install it?
---
I would say that the majority of developers don't care about the "openness" either. They care about accessing a wide audience and getting revenue from their work. Free apps without ads or in-app purchases (zero-revenue apps) are the minority.
Google is also fine with losing the zero-revenue app developers because they provide no value for Google. Actually, they are probably a loss for Google, since Google provides Google Play Services.
Just because you're HN dweller doesn't make it HN view. The openness, freedom, customizability and accessibility (money wise) were the tenets that differentiated Android from Apple devices.
>The openness, freedom, customizability and accessibility (money wise) were the tenets that differentiated Android from Apple devices.
i have never heard someone outside of tech circles (e.g. HN) mention openness, freedom, or customization, even as a passing comment.
they use a phone to access mainstream apps (youtube, instagram, reddit, maybe their bank) and text/call. mention "apk" or "fdroid" and their eyes start to glaze over.
cheaper devices, sure, i agree with that as being the differentiator to the average non-techie. the rest is, at least in my experience, absolutely a "HN view".
> i have never heard someone outside of tech circles... mention "apk" or "fdroid" and their eyes start to glaze over
My no-tech middle-aged uncles and aunts know what apks are, and that you need to install apps from somewhere apart from the main Play store if you want them to have no ads.
My brother, who's relationship with tech barely extends to the latest samsung flagship, threw away his iphone because he couldn't get all the apps he wanted.
I think _your_ impression of people outside tech circles is as HN-centric as it gets :)
Openness for end-users was never a tenet. It is a very HN view to think that open-source equals freedom for users, and to state that it was a promise when it never was.
Freedom for users was the motivating factor that created open source in the first place. Rewriting history to serve your own ends doesn't help your credibility.
I don’t know what you’re going on about “rewriting history”. I never mentioned the history of open source.
From the Open Handset Alliance:
“The Android platform will be made available under one of the most progressive, developer-friendly open-source licenses, which gives mobile operators and device manufacturers significant freedom and flexibility to design products.”
Give mobile operators and device manufacturers freedom, not consumers.
If anything, the people claiming that Android was created for freedom for consumers are rewriting history.
> can I download an app off a random website and install it
This is a straw man. This change hurts third party app stores such as F-Droid the most. I vastly prefer it to Play Store for the same reasons I prefer GNU/Linux to macOS or Windows (discounting the fact that Linux no longer needs hacks to "just work").
> Nowhere is their goal to allow users complete control of their device. Android was built as an open-OS for the mobile device industry, not end-users.
The fact that having root access is not the default supports that. Without root we're just "consumers" and that's how they see us. There's a lot of discussion about the security model of Android and how root is bad. But we've come to the point to argue that having root access is not only less secure but that we don't need root at all. A lot of replies, even on HN, are like:
> Why would you even need root access? What is it you're trying to accomplish?
That's a much bigger security smokescreen than the one in TFA. Sure, having root may be dangerous, especially if you don't know what you're doing, but it's still a choice. Having no phone or doing banking IRL or not downloading apps from the Play Store you haven't heard of before would also be more secure. But these 3 options don't align to the financial gain the consumers would bring to the providers. The consumers having no root, on the other hand, benefits the providers.
When a platform ditches openness, you lose more than a seemingly insignificant market segment that makes no money. Using money as the only metric is stupid and myopic.
Sandboxing and permissions provide a different type of security than application signatures. Sandboxing can limit app capabilities, but it doesn't change the fact that you can accidentally grant a malicious application permissions.
Application signatures and developer identification bring a different kind of application security. It provides the security of societal legal systems and legal ramifications for malicious actors.
In the end, you still have the choice to trust the "system" or your own judgment.
This is not really a complex question as much as it is an analogy demonstrating that allowing third parties to dictate how you live leads to a huge loss of your freedom with bad consequences on your independence and control. But you are right: I could say this in my above comment.
It seems that the majority of the skepticism comes from the classical understanding of magnetism and magnetic fields.
It seems incredulous that you can detect the magnetic dipole of a heartbeat at distance because the magnetic field generated by a heart is essentially nonexistent. However, there /is/ a measurable effect from the magnetic vector potential even if the magnetic field is or is essentially 0. This seems counterintuitive, but has been experimentally verified [0, 1].
There are a myriad of quantum magnetometers with the main categories of superconducting (SQUID), atomic, and nitrogen-vacancy (NV) [2]. Superconducting magnetometers require cryogenics, so we can immediately discount its usage. Nitrogen-vacancy magnetometers can detect high frequency magnetic fields, which a heartbeat is not, and are less sensitive than atomic magnetometers. Therefore, NV magnetometers can be disregarded.
Now, for atomic magnetometers. Optically pumped atomic magnetometers (OPAM). These are highly portable and extremely sensitive (fT/√Hz), with some OPAMs approaching the quantum noise limit [3]. Moreover, the detection of a magnetic vector potential is possible [4].
Another type of atomic magnetometer is the Spin Exchange Relaxation Free (SERF) magnetometer. SERFs are even more sensitive than standard OPAMs (aT/√Hz). So, likely, some form of atomic magnetometer is being used.
Nonetheless, they most likely used a mixture of other methods to reduce the search area.
You can check your DomU kernels using this guide:
https://doc.qubes-os.org/en/latest/user/advanced-topics/mana...
If your Dom0 or DomU is running kernel < 6.18.22, or between 6.19.0 and 16.19.12 you are vulnerable.
https://github.com/QubesOS/qubes-linux-kernel/pull/1272 commit fafe0fa2995a of the kernel mirror
Currently stable version of QubeOS does not have the patched kernels. https://yum.qubes-os.org/r4.3/current/dom0/fc41/rpm/
reply