4 ms·

Every GrapheneOS proponent I've seen has claimed that other devices are inferior to Pixel security wise, and that's why they're not supported. That always sound

by tjpnz 8mo ago

Every GrapheneOS proponent I've seen has claimed that other devices are inferior to Pixel security wise, and that's why they're not supported. That always sounded a bit odd to me and certainly seems to have a bit more nuance based on your comment. Thank you for adding some clarity here.

izacus 8mo ago
There's really nothing odd that company that runs Project Zero also builds devices that are well secured.
- fsflover 8mo ago
  Qubes OS, operating system designed for security, doesn't prevent its installation on computers without VT-d. It will just warn you.
  - limagnolia 8mo ago
    Graphene doesn't really try to stop you. They just don't spend their own efforts on making it possible. It is OSS so, your free to spend your efforts where you want to.
    - fsflover 8mo ago
      This is however not their main argument. I doubt they would accept such pull request.
      - limagnolia 8mo ago
        No pull request necessary, forks don't require approval.
      - handedness 8mo ago
        It would require a significant commitment of limited resources to broadly support insecure devices with very little upside, and to do so would constitute gross mismanagement of the project. Meanwhile, others are completely free to fork numerous GrapheneOS improvements or benefit from their upstream improvements (as some have, including Google). Why can't you understand that?
        fsflover 8mo ago
        I never mentioned any commitment except accepting pull requests, did I? Qubes can do that and doesn't require a fork. Are you saying they have much more resources?
        super256 8mo ago
        Every accepted PR for supporting insecure phones eventually becomes a maintenance burden, and potentially a security vulnerability. If they don't want to spend time on it, it's okay to decline such PRs.
        handedness 8mo ago
        You're being disingenuous here. What is the value of accepting pull requests with no intent to approve? The rhetoric you're using here is on a I'm-just-asking-questions level. You're not being consistent in what you're advocating. You mentioned accepting pull requests in the context of wanting to see broader device support. You want broader device support. I do too, which is the value of the Motorola announcement. Your suggestion isn't the way to achieve that. It just isn't viable for reasons you should reasonably already understand. But since you don't... It shows yet again you just don't understand the project, how it's structured, and what its goals are. I'd say you should try running it, but you're still murky on the actual nature of the OS you use daily, so there would be no point in my suggesting that. Assuming all you want is broader device support while magically not increasing the GrapheneOS team's overhead, but for reasons you haven't stated won't accept forking it, you're out of luck, which is right where you should be. Still, why? If you want hardware which lacks security features to run an OS, the primary value of which is its close integration with said hardware security features, what is it you really want, then? A degoogled Android OS? That already exists. Are GrapheneOS's "software" security enhancements (as if we can say "software" in the context of security in total isolation) their quality-of-life improvements to the OS that you're after? Many of those would greatly degrade in value if you couldn't trust the hardware it's running on. You'd get storage scopes, but you'd get it without a file system you could trust. You'd get network permissions but you'd get it without baseband isolation you could trust. You'd get x, y and z, without memory tagging. If that's what you want, you can get that elsewhere, and should. But by the conditions you set up, you're also effectively asking for code contributions by outsiders, when the project very deliberately and by all indications very tightly manages who can contribute code, and for good reason. The history of open source is the history of malicious code injection and social engineering attacks. If you want the device to be secure you have to address security from all angles. Unless you're really, genuinely, nonsensically proposing the project commit resources to allowing people to suggest code changes they have no intention of ever implementing. Though I suspect at that point you'd argue in favor of some code base changes, while not having addressed the fundamental implications of doing so. You're doing a great job of arguing against yourself, here, and have highlighted a fundamental challenge with Qubes OS. As an active user on the forum I'm sure you've seen the reasoned discussions weighing the pros and cons of accepting code contributions. If your response to that is, again, 'there hasn't been a relevant Xen bug in two decades and my data has been safe this whole time,' that's a dead-end for understanding anything. Your rhetoric in all this is very similar to the kind of thing one easily finds on normie websites about commonly divisive issues. At some point I just can't keep insisting you're either informed or sincere about all this, HN guidelines notwithstanding.
  - handedness 8mo ago
    As one who has lived out of both operating systems for years, I struggle with the way you invariably make value judgments about GrapheneOS every time it comes up in a thread, based on your (justifiable) appreciation for Qubes OS. The same thing happens in reverse on the GrapheneOS forums, by the way. Both lines of thinking are faulty, and attempting to directly extrapolate from one project to the other (in either direction) mostly only conveys a lack of understanding of both projects, even (especially?) one's favored project. Joanna Rutkowska herself admitted that the difficult nature of trying to contain the PC hardware stack made it ultimately feel like she lost the war. Qubes OS is inherently vastly more vulnerable than GrapheneOS, in large part precisely because of their different approaches to hardware. Some of this has been mitigated by developments made since she stepped back from the project, but some of it will always remain. How to deal with this inherent conflict is not a simple matter and the two projects have taken two distinctly different approaches. In the cases of both projects, I think they made justifiable decisions in their approaches. I use and contribute to both projects. If you've been using Qubes OS long enough, you'll remember a time when trying to run it on anything that wasn't essentially identical to the ThinkPads used by Qubes OS devs often presented a major challenge. GrapheneOS is a fundamentally different project in scope, and each project has a subset of users which seem unable to do anything but evaluate the other project based on the criteria set by the one they like. "The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware." GrapheneOS achieves significantly more security on the hardware level than Qubes OS, in very large part specifically due to the nature of the project. It's also an infinitely simpler OS to get up and running with, on both current-gen flagship hardware and current-gen value-prop hardware available in just about any store which sells cell phones. In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS. Securing a single device type with excellent hardware security is simply much more viable a project than securing a broad range of devices with hardware security that is, at best, pretty terrible. Repeatedly criticizing one project without significant familiarity with both is not just pointless, it's counterproductive to aims of FOSS privacy and security.
    - 8mo ago
  - upboundspiral 8mo ago
    The problem with laptops is that UEFI is a shadow operating system that keeps running after boot, with a bunch of security vulnerabilities. Furthermore all Intel / AMD chips have a microprocessor state called SMF which if you trigger it basically gives you carte blanche to do whatever you want. "Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain. Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of. So I understand why the GrapheneOS folks do what they do. See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!) https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
    - fsflover 8mo ago
      I use Qubes with TPM and Heads and with a hardware key. All based on FLOSS, so its possible.
      - handedness 8mo ago
        You still need to address this part: "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of." That's the crux of it you blow past every single time it comes up, and then disparage others as having not stuck around long enough to educate you (as if that's their responsibility).
        fsflover 8mo ago
        > "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can" Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with. > but cannot overcome the limitations of the platforms it builds off of Yes, it can, if you use it correctly. Tell me your threat model, and I will explain how Qubes can protect you.
bwoah 8mo ago
See their list of device requirements: https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices

by tjpnz 8mo ago

izacus 8mo ago

There's really nothing odd that company that runs Project Zero also builds devices that are well secured.

fsflover 8mo ago
Qubes OS, operating system designed for security, doesn't prevent its installation on computers without VT-d. It will just warn you.
- limagnolia 8mo ago
  Graphene doesn't really try to stop you. They just don't spend their own efforts on making it possible. It is OSS so, your free to spend your efforts where you want to.
  - fsflover 8mo ago
    This is however not their main argument. I doubt they would accept such pull request.
    - limagnolia 8mo ago
      No pull request necessary, forks don't require approval.
    - handedness 8mo ago
      It would require a significant commitment of limited resources to broadly support insecure devices with very little upside, and to do so would constitute gross mismanagement of the project. Meanwhile, others are completely free to fork numerous GrapheneOS improvements or benefit from their upstream improvements (as some have, including Google). Why can't you understand that?
      - fsflover 8mo ago
        I never mentioned any commitment except accepting pull requests, did I? Qubes can do that and doesn't require a fork. Are you saying they have much more resources?
        super256 8mo ago
        Every accepted PR for supporting insecure phones eventually becomes a maintenance burden, and potentially a security vulnerability. If they don't want to spend time on it, it's okay to decline such PRs.
        handedness 8mo ago
        You're being disingenuous here. What is the value of accepting pull requests with no intent to approve? The rhetoric you're using here is on a I'm-just-asking-questions level. You're not being consistent in what you're advocating. You mentioned accepting pull requests in the context of wanting to see broader device support. You want broader device support. I do too, which is the value of the Motorola announcement. Your suggestion isn't the way to achieve that. It just isn't viable for reasons you should reasonably already understand. But since you don't... It shows yet again you just don't understand the project, how it's structured, and what its goals are. I'd say you should try running it, but you're still murky on the actual nature of the OS you use daily, so there would be no point in my suggesting that. Assuming all you want is broader device support while magically not increasing the GrapheneOS team's overhead, but for reasons you haven't stated won't accept forking it, you're out of luck, which is right where you should be. Still, why? If you want hardware which lacks security features to run an OS, the primary value of which is its close integration with said hardware security features, what is it you really want, then? A degoogled Android OS? That already exists. Are GrapheneOS's "software" security enhancements (as if we can say "software" in the context of security in total isolation) their quality-of-life improvements to the OS that you're after? Many of those would greatly degrade in value if you couldn't trust the hardware it's running on. You'd get storage scopes, but you'd get it without a file system you could trust. You'd get network permissions but you'd get it without baseband isolation you could trust. You'd get x, y and z, without memory tagging. If that's what you want, you can get that elsewhere, and should. But by the conditions you set up, you're also effectively asking for code contributions by outsiders, when the project very deliberately and by all indications very tightly manages who can contribute code, and for good reason. The history of open source is the history of malicious code injection and social engineering attacks. If you want the device to be secure you have to address security from all angles. Unless you're really, genuinely, nonsensically proposing the project commit resources to allowing people to suggest code changes they have no intention of ever implementing. Though I suspect at that point you'd argue in favor of some code base changes, while not having addressed the fundamental implications of doing so. You're doing a great job of arguing against yourself, here, and have highlighted a fundamental challenge with Qubes OS. As an active user on the forum I'm sure you've seen the reasoned discussions weighing the pros and cons of accepting code contributions. If your response to that is, again, 'there hasn't been a relevant Xen bug in two decades and my data has been safe this whole time,' that's a dead-end for understanding anything. Your rhetoric in all this is very similar to the kind of thing one easily finds on normie websites about commonly divisive issues. At some point I just can't keep insisting you're either informed or sincere about all this, HN guidelines notwithstanding.
- handedness 8mo ago
  As one who has lived out of both operating systems for years, I struggle with the way you invariably make value judgments about GrapheneOS every time it comes up in a thread, based on your (justifiable) appreciation for Qubes OS. The same thing happens in reverse on the GrapheneOS forums, by the way. Both lines of thinking are faulty, and attempting to directly extrapolate from one project to the other (in either direction) mostly only conveys a lack of understanding of both projects, even (especially?) one's favored project. Joanna Rutkowska herself admitted that the difficult nature of trying to contain the PC hardware stack made it ultimately feel like she lost the war. Qubes OS is inherently vastly more vulnerable than GrapheneOS, in large part precisely because of their different approaches to hardware. Some of this has been mitigated by developments made since she stepped back from the project, but some of it will always remain. How to deal with this inherent conflict is not a simple matter and the two projects have taken two distinctly different approaches. In the cases of both projects, I think they made justifiable decisions in their approaches. I use and contribute to both projects. If you've been using Qubes OS long enough, you'll remember a time when trying to run it on anything that wasn't essentially identical to the ThinkPads used by Qubes OS devs often presented a major challenge. GrapheneOS is a fundamentally different project in scope, and each project has a subset of users which seem unable to do anything but evaluate the other project based on the criteria set by the one they like. "The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware." GrapheneOS achieves significantly more security on the hardware level than Qubes OS, in very large part specifically due to the nature of the project. It's also an infinitely simpler OS to get up and running with, on both current-gen flagship hardware and current-gen value-prop hardware available in just about any store which sells cell phones. In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS. Securing a single device type with excellent hardware security is simply much more viable a project than securing a broad range of devices with hardware security that is, at best, pretty terrible. Repeatedly criticizing one project without significant familiarity with both is not just pointless, it's counterproductive to aims of FOSS privacy and security.
  - 8mo ago
- upboundspiral 8mo ago
  The problem with laptops is that UEFI is a shadow operating system that keeps running after boot, with a bunch of security vulnerabilities. Furthermore all Intel / AMD chips have a microprocessor state called SMF which if you trigger it basically gives you carte blanche to do whatever you want. "Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain. Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of. So I understand why the GrapheneOS folks do what they do. See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!) https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
  - fsflover 8mo ago
    I use Qubes with TPM and Heads and with a hardware key. All based on FLOSS, so its possible.
    - handedness 8mo ago
      You still need to address this part: "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of." That's the crux of it you blow past every single time it comes up, and then disparage others as having not stuck around long enough to educate you (as if that's their responsibility).
      - fsflover 8mo ago
        > "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can" Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with. > but cannot overcome the limitations of the platforms it builds off of Yes, it can, if you use it correctly. Tell me your threat model, and I will explain how Qubes can protect you.

bwoah 8mo ago

See their list of device requirements: https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices