GrapheneOS-Knowledge

This is a short description of some of the knowledge I've collected on GrapheneOS and some common questions I've been asked and my answers to them. (by Peter-Easton)

GrapheneOS-Knowledge Alternatives

Similar projects and alternatives to GrapheneOS-Knowledge

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better GrapheneOS-Knowledge alternative or higher similarity.

GrapheneOS-Knowledge reviews and mentions

Posts with mentions or reviews of GrapheneOS-Knowledge. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-09-02.
  • NitroPhone – “Most Secure Android on the Planet”
    7 projects | news.ycombinator.com | 2 Sep 2021
    This is just one example (linked below) but I've seen a fair bit of this type of behaviour just specifixally from the project founder/leader. There does seem to be a lot of other more level-headed folk involved with the project too however so not sure how insurmountable the problem is.

    https://github.com/Peter-Easton/GrapheneOS-Knowledge/issues/...

  • Making Librem 5 Apps
    3 projects | news.ycombinator.com | 11 Apr 2021
    The Librem 5 is not as open or libre as its marketing has tried to insinuate, simply having its binary blob signed and validated firmware saved in write-protected read-only memory and loaded by a secondary coprocessor to exploit a loophole in the definiton of "libre" hardware to allow it to qualify for the FSF's definiton of "Free" hardware. This renders the firmware unupdateable without shorting a connection. In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone. Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects. Although the modems and radios are not attached to the host via DMA, they rely on USB for isolation, which simply shifts the trust from the kernel driver to the kernel USB stack, and USB was never designed with distrusting the device plugged into it in mind unlike SMMU/IOMMU, which is specifically designed to mitigate unconstrained DMA.

    Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle.

    The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption.

    The rebranded version of Debian that the Librem 5 uses as an operating system uses the same security model as the desktop stack, which is a perimeter or "all or nothing" security model. In the future, applications may be installed utilizing FlatPak. The threat model and measures FlatPak takes to meet it are as of yet unclear and uncertain.

    From https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/ma...

Stats

Basic GrapheneOS-Knowledge repo stats
3
72
0.0
about 2 years ago

Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com