Comment by strcat
7 months ago
Those devices have atrocious security at a hardware, firmware and software level. Their microphone kill switch also doesn't prevent audio recording. They aren't open hardware despite many attempts to mislead people with the marketing.
> The latter even has most of the modem software freed.
Pinephones have entirely closed source baseband firmware. They use a highly unusual cellular radio which includes both an incredibly outdated Qualcomm baseband processor with atrocious updates and security combined with an extremely outdated proprietary fork of Android running on an extra CPU core which isn't present in any mainstream smartphone. It's only replacing the unusual extra OS which has been done. That whole component doesn't exist on other smartphones and the only reason it's possible to replace it is because the whole radio has absolutely atrocious security. The radio is connected via a far higher attack surface USB connection providing far less isolation for the OS and the USB connection can be used to flash the proprietary Android OS via the fastboot protocol. The baseband firmware itself doesn't have any replacement available.
> Pinephones have entirely closed source baseband firmware.
> The baseband firmware itself doesn't have any replacement available.
Same with the Google Pixels and their Samsung Exynos modem. Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers. What will it be for the upcoming Motorola phone?
> Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers
Pixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of it?
Neither. It's great that the Pixels' baseband ACPU doesn't have free reign in system memory, but if we're gonna underline the deficient state of the cellular modem in the Pine Phone we should also remind ourselves that the firmware situation with the Pixels is an almost equally sore thumb.
3 replies →
Hi daneel, what would you like GrapheneOS to do while you develop your own formally verified, open hardware, open source firmware/OS baseband processor they can use? Sit on their hands doing nothing or making the best of the least worst options currently available?
The Pixels already are the best of the least worst options currently available. Anything new must categorically bring improvements, and the closed source firmware of the Pixels is a pressing point.
1 reply →
> Their microphone kill switch also doesn't prevent audio recording.
Unless you provide some evidence, I will consider this false accusation.
> They aren't open hardware despite many attempts to mislead people with the marketing.
Who and where said they were open hardware?
> extremely outdated proprietary fork of Android
Which was freed and can run new Linux kernels now: https://github.com/the-modem-distro/pinephone_modem_sdk and https://xnux.eu/devices/feature/modem-pp.html
Your walls of text are disingenuous.
> Unless you provide some evidence, I will consider this false accusation.
The line of thinking is, if you're so concerned about your device being compromised that you need to enable the mic kill switch (because of aforementioned lack of trust in the device), then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own.
On a device that's that compromised one would have to physically power off every sensor on the device, and even then there would still be some things to consider. Air gaps are a thing for a reason, and yet some incredibly clever exploits have been demonstrated to jump that gap. Many components that aren't microphones, cameras or radios can be turned into cameras, microphones or radios pretty effectively.
Still, I see the appeal of hardware switches as another practical layer against basic human factors, like a webcam lens cover adding another step beyond firing up the camera's permissions/appVM. But if we're being practical, a phone I can get wet is much more practical than a phone with physical hardware switches when I already have a high degree of trust the OS's ability to control sensors, and a low degree of rust in the OS's ability to control liquids and debris.
> Which was freed and can run new Linux kernels now:
Unfortunately that has kernel dependencies that haven't been updated in years. If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.
> Your walls of text are disingenuous.
You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?
"Unless you provide some evidence, I will consider this false accusation." is bizarre, especially given your audience. You're capable of learning all this stuff on your own without asking everyone to do that for you.
Regardless, nine sentences across two paragraphs isn't a wall of text. The guy took time out of his day to respond to banality and that's what he gets.
It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?
> then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own.
You (and strcat) have no idea what you are talking about. And you are constantly shifting goals. Sensors are much harder to use as microphones. Was it ever caught in the wild, not in a lab? Sensors are also switched off on Librem 5 by the three kill switches: https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...
> If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.
This is misleading. There are different degrees of security. Qubes provides the highest achievable degree (for certain threat models). It doesn't mean that Debian and Fedora have no security at all. Moreover, if you only run trusted application, they are reasonably secure, unlike OSes with (partially) closed source.
> You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?
I don't care about personalities. Famous and smart people are wrong more often than you seem to think.* I care about arguments. This is why I'm on HN.
> Regardless, nine sentences across two paragraphs isn't a wall of text.
I am talking about all comments together, not one comment.
> It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?
I do not have any hope that you try to understand me, since you immediately started fighting with me, without even considering my point of view. Many of your replies (see example in this very answer of mine) did not address my concerns. Some of your replies ignored my links (LoC).
* (Me included; I argue here, because I want to find out where I'm wrong.)
2 replies →