6 ms·

Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure

Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave and multiyear commitments from the vendor to firmware security updates (I think 7 years of updates now for the newest Pixels). Those seem to be the big two things that no other Android vendor achieves together. The GrapheneOS devs are serious about security, probably more focused on it than 99% of end users. That they manage to release a project with the high level of usability that GrapheneOS achieves is impressive, even if it isn't as convenient to the end user as stock Android. Ultimately, nothing will ever be as convenient to the end user as stock Android or iOS, but that's not the point of the project.

JCattheATM 1y ago
> Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave That's my point, though. The projects security requirements don't need to be that stringent. By all means, take advantage of the hardware security on devices that offer it like pixel, but even on devices without that hardware security it would still be the most secure Android based OS available, and orders of magnitudes more people would benefit from having access to that.
- sfRattan 1y ago
  > The projects security requirements don't need to be that stringent. GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. Have something that is maximally secure within the most aggressive limits of what is possible today. It targets end users who either have an acute threat model (e.g. journalists, dissidents) or are willing to tolerate some level of inconvenience (compared to stock Android) to gain the security advantages. Not everyone is willing to make that trade-off, and that's okay. I don't want my daily use phone OS to adopt a more permissive security model to appeal to a broader audience. I suspect most GrapheneOS users share that stance. There are other AOSP custom distributions that benefit from the security improvements GrapheneOS is able to get accepted upstream (though Google is making this more difficult than it used to be). I think, for people who aren't willing to make the trade-off, a better path is to use another AOSP distribution on the hardware they prefer, or to establish a separate project to build a downstream version of GrapheneOS (under a clearly distinct name) for other, less secure hardware... Trying to shadow each release as closely as possible and make best use of Graphene's generally excellent software customizations (e.g. storage scopes, deny network permission, etc) without pursuing a hard fork. I'd certainly like something similar for NVIDIA Shield Devices, for example. But I know that's not what Graphene's mission is. The GrapheneOS devs absolutely will not listen to anyone asking them to loosen their security model. And thank goodness they don't! That's why I use GrapheneOS. It's why many do.
  - JCattheATM 1y ago
    > GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. They don't though, that's just a nonsense claim. Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available. > And thank goodness they don't! Your reasoning does not support your conclusion.
    - sfRattan 1y ago
      >Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available. Yes. And the correct course of action is a separate, downstream project with a different name doing exactly that and shadowing the GrapheneOS releases. Not a weakening of the GrapheneOS security model. If you don't want a maximally secure build of AOSP, you don't want GrapheneOS: you want something else. Maybe something substantially similar, but not GrapheneOS. >They don't though, that's just a nonsense claim. I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements. The statement is closer to tautological than it is to nonsensical.
      - JCattheATM 1y ago
        > And the correct course of action is a separate, downstream project Except that there is explicitly no need for that. > Not a weakening of the GrapheneOS security model. There is no weakening for those people like yourself that feel they need the extra security provided by using pixel devices. > I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements. The fact that you are claiming a weakening is happening at all is ridiculous. If it was made available for more devices, you, using it on a pixel, would be exactly 0% less secure. Do you have an understanding of the point you are arguing, or are you repeating things you've heard?
        sfRattan 1y ago

JCattheATM 1y ago

> Unfortunately, Google's Pixel devices have been the only ones with hardware that meets all of the project's stringent security requirements, including a secure hardware enclave That's my point, though. The projects security requirements don't need to be that stringent. By all means, take advantage of the hardware security on devices that offer it like pixel, but even on devices without that hardware security it would still be the most secure Android based OS available, and orders of magnitudes more people would benefit from having access to that.

sfRattan 1y ago
> The projects security requirements don't need to be that stringent. GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. Have something that is maximally secure within the most aggressive limits of what is possible today. It targets end users who either have an acute threat model (e.g. journalists, dissidents) or are willing to tolerate some level of inconvenience (compared to stock Android) to gain the security advantages. Not everyone is willing to make that trade-off, and that's okay. I don't want my daily use phone OS to adopt a more permissive security model to appeal to a broader audience. I suspect most GrapheneOS users share that stance. There are other AOSP custom distributions that benefit from the security improvements GrapheneOS is able to get accepted upstream (though Google is making this more difficult than it used to be). I think, for people who aren't willing to make the trade-off, a better path is to use another AOSP distribution on the hardware they prefer, or to establish a separate project to build a downstream version of GrapheneOS (under a clearly distinct name) for other, less secure hardware... Trying to shadow each release as closely as possible and make best use of Graphene's generally excellent software customizations (e.g. storage scopes, deny network permission, etc) without pursuing a hard fork. I'd certainly like something similar for NVIDIA Shield Devices, for example. But I know that's not what Graphene's mission is. The GrapheneOS devs absolutely will not listen to anyone asking them to loosen their security model. And thank goodness they don't! That's why I use GrapheneOS. It's why many do.
- JCattheATM 1y ago
  > GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. They don't though, that's just a nonsense claim. Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available. > And thank goodness they don't! Your reasoning does not support your conclusion.
  - sfRattan 1y ago
    >Remove the parts dependent on the Pixel security hardware, and you still have a MUCH stronger android OS than anything else available. Yes. And the correct course of action is a separate, downstream project with a different name doing exactly that and shadowing the GrapheneOS releases. Not a weakening of the GrapheneOS security model. If you don't want a maximally secure build of AOSP, you don't want GrapheneOS: you want something else. Maybe something substantially similar, but not GrapheneOS. >They don't though, that's just a nonsense claim. I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements. The statement is closer to tautological than it is to nonsensical.
    - JCattheATM 1y ago
      > And the correct course of action is a separate, downstream project Except that there is explicitly no need for that. > Not a weakening of the GrapheneOS security model. There is no weakening for those people like yourself that feel they need the extra security provided by using pixel devices. > I don't know what is nonsensical about claiming that a project whose principal goal is to be maximally secure shouldn't weaken its hardware security requirements. The fact that you are claiming a weakening is happening at all is ridiculous. If it was made available for more devices, you, using it on a pixel, would be exactly 0% less secure. Do you have an understanding of the point you are arguing, or are you repeating things you've heard?
      - sfRattan 1y ago