3 ms·

> Their microphone kill switch also doesn't prevent audio recording It doesn't prevent audio recording in the super paranoid "oh, the whole phone has been comp

> Their microphone kill switch also doesn't prevent audio recording It doesn't prevent audio recording in the super paranoid "oh, the whole phone has been compromised" scenario because it is bypassable via the sensors. In fact, it doesn't even protect the phone in normal operation, because apps with device=all can access the sensors without the whole phone being compromised. It doesn't prevent audio recording with any normal usage either because the OS is incapable of protecting private conversations thanks to the PulseAudio socket. "Exploiting" this is significantly easier than any of the stuff involving the sensors.

fsflover 5mo ago
> because it is bypassable via the sensors. Did you even look in my link, which we are discussing? My quote from there: > Sensors are also switched off on Librem 5 by the three kill switches: https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-hardware-kill-switches/ https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...
- TommyTran732 5mo ago
  And what good is the phone when 3 switches are off? You think that people buy a phone with a "mic killswitch" expects to have to turn off practically everything including internet to make sure that their mics aren't snooped on? Does that really sound like a functioning "killswitch"?
  - handedness 5mo ago
    The mind, it boggles. On a long enough timeline he'll probably cite this comment chain as proof you were unable to respond to his concerns, like everyone else who's ever tried.
    - TommyTran732 5mo ago
      Oh he's already done that when I explained to him how stuff like PureBoot has circular logic and doesn't actually work on Qubes forum already. Unfortunately he will just ignore every single counter argument ever made and blindly believe these companies because their marketing material has "freedom" and "FOSS" in it.
      - fsflover 5mo ago
        On Qubes forum, you had replies from far more knowledgeable people than me. You never could answer to them. You only talk about the lack of security of Pureboot and never showed the code breaking it. "Talk is cheap, show me the code".
        TommyTran732 5mo ago
        > You never could answer to them. I did reply to them plenty of times. Here you go doing the exact same thing again - ignoring 100% of what's being said, then claiming "no one can respond". > You only talk about the lack of security of Pureboot and never showed the code breaking it. If you think a piece of code is needed to understand why it's a joke, then I don't even understand what is wrong with you. LMAO. The whole thing is conceptually botched, and they pretty much admitted as much. 1. Boot block performs measurements of itself, its settings and everything down the chain for attestation. 2. There's nothing protecting the boot block. 3. A malicious boot block can lie about measurements. 4. If the goal is to defend against an attacker who tampers with the BIOS chip - then it fails at doing so miserably because an attacker can just use a boot block that lies about the measurements. Seriously, what good is showing you the code if you don't even conceptually understand how the thing works? You know, there is a famous saying: A farmer does not need to know how to lay eggs to know whether an egg is good or bad. In our case, the egg is already rotten from the get-go. This is not a "Ohhh something has such bad code I can attack it using XYZ method, wait and see!" situation. This is a situation where "Your logic doesn't even make any sense to begin with." Perhaps, just perhaps, you can benefit from just spending 5 minutes thinking a bit about how the whole thing actually works at a very high level and read what I said above.
        fsflover 5mo ago
        Thank you for your kind advice, but I prefer to trust a developer of Heads and many Qubes contributors instead of a loud Internet commenter criticizing everything and everyone.
        5mo ago
- handedness 5mo ago
  Everything Micay said in that linked thread was and remains correct. You again fail to address what was incorrect in his comment. Going on to later ask people "what is correct about it?" is rhetorically disingenuous at best. But as you consistently slide any adjacent topic you can into a discussion about the Librem 5 (no matter how tortured a segue), let's go with that and revisit it. I looked at your puri.sm link, and it mostly served to lower my estimation of the Librem 5's kill switch system. You can't disable the sensors in a trustworthy way without disengaging every kill switch at the same time, entering it into their Lockdown Mode. At that point it's just a still insufficiently air-gapped, highly underpowered Linux device which remains poorly secured against other side-channel attacks. The speaker which, by everything I could find, is still functional, the OS remains poorly secured against software attacks, it lacks proper hardware security, and so on. It fails in terms of human factors, too. Joe Consumer thinks flipping off the mic switch prevents audio recording, but it doesn't in multiple regards. Even putting it into Lockdown Mode doesn't disable the speaker, which can be used to record audio despite your insistence that the device is fully secured when all switches off. Speakers can also be used to exfil data over short distances, demonstrated to work through walls. Poor misinformed Joe Consumer is also still left with the same issues the other commenter has already identified in terms of the difficulty of securing any Linux computer. But that's okay, because you only run trusted software. Until one of those trusted pieces of software include a compromised library, which happens often. You are, at that point, relying on the OS and its relationship to its hardware, which, flawed switch system aside, is highly insufficient. The device offers very little protection at that point. You know all this because you run Qubes OS, but hand-wave that away by appealing to trusted software as soon as the Librem 5 becomes the subject. If I was modeling threats around protecting sensitive files on the device, not falling victim to attacks that could record audio and/or exfil data or otherwise leak, I'd still go with GrapheneOS on a Pixel 8 or later. The Librem 5 wins for anyone who just wants a phone which runs Linux (which is a great thing and I wish we had more options which did that), but the security theater of that device is just goofy from top to bottom, as are its more vocal and less reasoned supporters. If one's threat model is, one sometimes wants to be able to turn off all radios and sensors, leaving the speaker functioning, with an otherwise poorly secured device, then, great. It's the device for you. But it's a threat model which will be practically beneficial to very few people, if any. If your holy grail is having the radios off without other hardware or software considerations, great, you've found the phone for you. It's a brilliantly marketed device for well meaning but poorly informed people with underdeveloped threat models, and, I guess, for someone in your situation who's happy to make all of the above compromises to be able to physically disconnect radios. Do you always enter Lockdown Mode before typing anything sensitive, due to the attack vector they highlighted about deriving typed data via sensor data? ('No, because I only run trusted software.' See above.) You literally can't disable the sensors without disabling all radios. They acknowledge that sensors are an attack vector worth addressing, yet don't put sensors on a discrete circuit. Like I said, great marketing. Otherwise pretty goofy. Would I complain if the upcoming Motorola GrapheneOS phone had physical hardware switches? Sure, I'd take an additional layer of containment if all of the fundamentals are addressed properly. But your argument is like bolting the world's best seat belts onto a motorcycle, and never missing an opportunity to tell the world about your belts, wonderful though they truly are.

fsflover 5mo ago

> because it is bypassable via the sensors. Did you even look in my link, which we are discussing? My quote from there: > Sensors are also switched off on Librem 5 by the three kill switches: https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-hardware-kill-switches/ https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...

TommyTran732 5mo ago
And what good is the phone when 3 switches are off? You think that people buy a phone with a "mic killswitch" expects to have to turn off practically everything including internet to make sure that their mics aren't snooped on? Does that really sound like a functioning "killswitch"?
- handedness 5mo ago
  The mind, it boggles. On a long enough timeline he'll probably cite this comment chain as proof you were unable to respond to his concerns, like everyone else who's ever tried.
  - TommyTran732 5mo ago
    Oh he's already done that when I explained to him how stuff like PureBoot has circular logic and doesn't actually work on Qubes forum already. Unfortunately he will just ignore every single counter argument ever made and blindly believe these companies because their marketing material has "freedom" and "FOSS" in it.
    - fsflover 5mo ago
      On Qubes forum, you had replies from far more knowledgeable people than me. You never could answer to them. You only talk about the lack of security of Pureboot and never showed the code breaking it. "Talk is cheap, show me the code".
      - TommyTran732 5mo ago
        > You never could answer to them. I did reply to them plenty of times. Here you go doing the exact same thing again - ignoring 100% of what's being said, then claiming "no one can respond". > You only talk about the lack of security of Pureboot and never showed the code breaking it. If you think a piece of code is needed to understand why it's a joke, then I don't even understand what is wrong with you. LMAO. The whole thing is conceptually botched, and they pretty much admitted as much. 1. Boot block performs measurements of itself, its settings and everything down the chain for attestation. 2. There's nothing protecting the boot block. 3. A malicious boot block can lie about measurements. 4. If the goal is to defend against an attacker who tampers with the BIOS chip - then it fails at doing so miserably because an attacker can just use a boot block that lies about the measurements. Seriously, what good is showing you the code if you don't even conceptually understand how the thing works? You know, there is a famous saying: A farmer does not need to know how to lay eggs to know whether an egg is good or bad. In our case, the egg is already rotten from the get-go. This is not a "Ohhh something has such bad code I can attack it using XYZ method, wait and see!" situation. This is a situation where "Your logic doesn't even make any sense to begin with." Perhaps, just perhaps, you can benefit from just spending 5 minutes thinking a bit about how the whole thing actually works at a very high level and read what I said above.
        fsflover 5mo ago
        Thank you for your kind advice, but I prefer to trust a developer of Heads and many Qubes contributors instead of a loud Internet commenter criticizing everything and everyone.
        5mo ago
handedness 5mo ago
Everything Micay said in that linked thread was and remains correct. You again fail to address what was incorrect in his comment. Going on to later ask people "what is correct about it?" is rhetorically disingenuous at best. But as you consistently slide any adjacent topic you can into a discussion about the Librem 5 (no matter how tortured a segue), let's go with that and revisit it. I looked at your puri.sm link, and it mostly served to lower my estimation of the Librem 5's kill switch system. You can't disable the sensors in a trustworthy way without disengaging every kill switch at the same time, entering it into their Lockdown Mode. At that point it's just a still insufficiently air-gapped, highly underpowered Linux device which remains poorly secured against other side-channel attacks. The speaker which, by everything I could find, is still functional, the OS remains poorly secured against software attacks, it lacks proper hardware security, and so on. It fails in terms of human factors, too. Joe Consumer thinks flipping off the mic switch prevents audio recording, but it doesn't in multiple regards. Even putting it into Lockdown Mode doesn't disable the speaker, which can be used to record audio despite your insistence that the device is fully secured when all switches off. Speakers can also be used to exfil data over short distances, demonstrated to work through walls. Poor misinformed Joe Consumer is also still left with the same issues the other commenter has already identified in terms of the difficulty of securing any Linux computer. But that's okay, because you only run trusted software. Until one of those trusted pieces of software include a compromised library, which happens often. You are, at that point, relying on the OS and its relationship to its hardware, which, flawed switch system aside, is highly insufficient. The device offers very little protection at that point. You know all this because you run Qubes OS, but hand-wave that away by appealing to trusted software as soon as the Librem 5 becomes the subject. If I was modeling threats around protecting sensitive files on the device, not falling victim to attacks that could record audio and/or exfil data or otherwise leak, I'd still go with GrapheneOS on a Pixel 8 or later. The Librem 5 wins for anyone who just wants a phone which runs Linux (which is a great thing and I wish we had more options which did that), but the security theater of that device is just goofy from top to bottom, as are its more vocal and less reasoned supporters. If one's threat model is, one sometimes wants to be able to turn off all radios and sensors, leaving the speaker functioning, with an otherwise poorly secured device, then, great. It's the device for you. But it's a threat model which will be practically beneficial to very few people, if any. If your holy grail is having the radios off without other hardware or software considerations, great, you've found the phone for you. It's a brilliantly marketed device for well meaning but poorly informed people with underdeveloped threat models, and, I guess, for someone in your situation who's happy to make all of the above compromises to be able to physically disconnect radios. Do you always enter Lockdown Mode before typing anything sensitive, due to the attack vector they highlighted about deriving typed data via sensor data? ('No, because I only run trusted software.' See above.) You literally can't disable the sensors without disabling all radios. They acknowledge that sensors are an attack vector worth addressing, yet don't put sensors on a discrete circuit. Like I said, great marketing. Otherwise pretty goofy. Would I complain if the upcoming Motorola GrapheneOS phone had physical hardware switches? Sure, I'd take an additional layer of containment if all of the fundamentals are addressed properly. But your argument is like bolting the world's best seat belts onto a motorcycle, and never missing an opportunity to tell the world about your belts, wonderful though they truly are.