Element (web, desktop or mobile) with matrix.org is one option.
Very unfortunate we can't redirect users anymore.
IRC users may prefer weechat-matrix as a client. It works well for public rooms like our official chat rooms but lacks decent end-to-end encryption (E2EE) support for use with private rooms. Element has the best support for E2EE.
@ihackbanme@spoofyroot If the device is deeply compromised, how is this going to help you? Why would the attacker allow you to use an OS mechanism to analyze it?
Verified boot, attestation (via our Auditor app and attestation.app) and a sideloaded update are the only things countering them.
@ihackbanme@spoofyroot If you don't have meaningful verified boot, then they don't even need to exploit the OS every boot to maintain their deep level of persistent access.
If you have a way to grant persistent root access, you don't have meaningful verified boot for the OS accomplishing anything.
@ihackbanme@spoofyroot In the verified boot security model, persistent state is not trusted. If there's a way to grant root access to an application persistently or even to make it available to the user in the OS persistently then that compromise is permanent root access without exploitation each boot.
There are many out-of-date and/or inaccurate third party install guides. Many have dangerous advice.
If you do publish an unofficial guide, please address inaccuracies that are reported and keep it up to date. If you lack the time, please take it down and ask people to use either our web installer or official CLI guide instead.
Many people are being harmed by inaccurate guides.
Every day, multiple users come to our chat needing help after following one of the problematic unofficial guides.
They often have a soft bricked device and a mess on their computer to clean up. Some of these users end up hard bricking their devices.
If you receive legal threats from Copperhead based on their fraudulent claims of ownership over our work please get in touch with us.
There's no basis to these claims and we're looking into providing protection for contributors and other open source projects via indemnification.
CopperheadOS was started by Daniel Micay in 2014 and he owns all of the code he wrote for it. He's a co-founder of Copperhead and still owns half of the company. He never assigned any copyright to Copperhead and work on the project was not done as an employee or as contract work.
It was explicitly agreed upon that the open source project would remain owned and control by Daniel Micay. It was explicitly agreed upon that there would be no copyright assignment.
Copperhead is trying to intimidate contributors to GrapheneOS and other open source projects.
If an app has the ability to perform arbitrary DNS queries via the OS, it can exfiltrate data to any party.
It can query encrypted-data.domain.tld to send data to an authoritative DNS server. No direct connection is ever required. It's being used in practice. Keep that in mind.
In general, granting network access provides the ability to exfiltrate data anywhere via the network. Fine-grained filtering is useful for harm reduction but doesn't provide what users expect from it. That includes using it in a stricter way than enumerating + blocking badness.
GrapheneOS has a coarse Network toggle blocking all direct access to the network and also preventing indirect access via APIs requiring the INTERNET permission.
Fine-grained filtering only filters direct access and there are a lot of issues like that DNS one. Doesn't work well.
We're hopeful the recent attention will help us with finding hardware partners with aligned goals.
It's a requirement for the devices to be at least as secure as a Pixel. That includes a modern mobile SoC and a comparable secure element to the Titan M implementing the same APIs.
Initially, it doesn't need to be better. It's difficult enough to produce a device meeting the same standards without severe privacy or security regressions. We're not interested in having our brand associated with a device that's marketed as private and secure but is worse off.
The setup we want to have isn't far from what Google was doing with Nexus devices. GrapheneOS needs substantial input into the design and implementation of devices. They'll use our signing keys for boot chain, stock OS verified boot key, etc.
GrapheneOS has funding available for developing an open source WebUSB-based installer as an alternative to our installation guide. It's low-level programming work despite being in JavaScript.
Get in touch with us (contact@grapheneos.org) if you're interested in working on it.
This does not involve designing and implementing a fancy user interface. It only needs the bare minimum of a functional interface for driving the installation process.
There's the open source fastboot code and an existing proprietary WebUSB-based flasher to reverse engineer.
Need to be comfortable with straightforward, fairly modern C++ and with JavaScript.
UX design and CSS are not within the scope of the project. Don't need to be concerned with making usable instructions either.
Goal for the project is a working installer with a bare minimum UI.