Damus
Final
Recent notes
When it comes to choosing software I want, there are three "No"s that make the reviewed software an immediate fail: - No patches - No assurance - No trust If your software is not regularly updated or responds inappropriately to disclosures, then you can assume it is not safe and can become even more unsafe in the future. This should also be heavily scrutinised by fork projects or projects with upstream dependencies or third-party libraries. If you are not able to take upstream patches or updated libraries in a timely manner, then your software should not be promoted with a commitment to security. Assurance is continuous assessment and review by security professionals to measure confidence that security controls are working as designed. Threat modelling, penetration testing / reverse engineering, security scanning and audits are methods to do this. Assurance helps discover vulnerabilities and potential room for improvement, which is a good thing since it leads to change and commitment to developing more secure software. Assurance matters because implementation is not always equal to the intended design. You can code something, read the code line by line and test / debug the feature and it may still have a security vulnerability, it just isnt known yet. Therefore, you should only use software you know is committed or receives regular audits. The frequency is completely up to your tolerance. Security assurance is heavy work and often can't be done alone by developers. Proprietary or corporate-sponsored products often have the benefit of assurance because they provide financial incentive (bounties) to make people choose to commit into discovering vulnerabilities to help secure the product. In open source, especially for smaller projects, this can often only be done by good will of users, or worse, isn't done at all. The most popular example, xz, only had their backdoor discovered thanks to goodwill of an eyed Microsoft employee. This is where the controversial (for Nostr) take comes in, but this would also mean Windows and MacOS, Chrome and others are far more assured than esoteric software. Security professionals are far more likely to be targeting popular software for security assurance, NOT your small Linux distro you spent weeks 'ricing' through baskets of additional, far more esoteric software. This isn't all bad news though. Open software benefits from being derived from already highly assured software, such as GrapheneOS and the upstream Android Open Source Project. Sometimes, especially with cryptography, it can be better not to DIY. No trust is a given. You shouldn't use software if you don't trust it, their upstream / third party components or it's developers. I wouldn't decide to concede because that would be hypocritcal. There are a lot of ways I decide what makes software trustworthy beyond these three No's, but they'd probably be better in something more long form. nevent1qqs9mauz7vznmzrjgxsgxxy6t6x3pdsh5w9vd7wstpcwmyszkfgp3dspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqsvctalz
Our initial port to Android 16 has been completed and can be built for the emulator from our 16 branch. All of the device-independent code has been ported. There are some parts of the port which will be redone better and a lot of testing and fixing regressions to do. Normally, we would have announced the availability experimental releases based on Android 16 already. Unfortunately, Android 16 dropped device/hardware support from the Android Open Source Project and we're going to need to put it together ourselves without being prepared for it. We'll be starting from the Android 15 QPR2 device support code and stripping it down to a bare minimum. Pixel 9a is a special case and will be more work. Our hardware-based USB-C port control feature will no longer work with this approach and we need to replace half of the code. We received early notice of Android 16 removing the device support code from AOSP but were unable to confirm it or determine the details. We have existing automated tooling for this we can significantly extend to generate what we need. It will be difficult and a major regression. Paying an ODM to make a Snapdragon device for us is increasingly appealing. We would have all the device support code we need, could build it with compiler-based hardening and would be able to harden a lot of the device's firmware. We could also make secure element applets. We want to be building privacy and security features. We don't want to be wasting our efforts on adding device support and other basic functionality to AOSP. It appears the only way we're going to be able to do that is paying millions of dollars to an ODM to have a proper base. As an example of what we would be able to do even with an entirely standard reference device, we could add hardware support for our duress PIN/password feature to the secure element so that successfully exploiting the OS could not bypass it. We could do a whole lot with firmware. Pixels meeting our requirements is why many of them were and are being purchased. We've reported MANY vulnerabilities over the years which have been fixed for Android and Pixels. We've proposed hardware, firmware and many software level security enhancements they've adopted. We would prefer not having to pay millions of dollars to have a phone produced for us. It's entirely doable but we would need to repeat it every few years. We'd rather work with an OEM with aligned goals and willing to provide first class GrapheneOS support to sell more devices. Pixels have substantially benefited from meeting our requirements and having GrapheneOS available for them. We know there's a significant market for an OEM working with us to make a more secure device with hardware-based security features not available on Pixels or iPhones.
In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable. Android 16 launched today and porting is going to be significantly more difficult than we were expecting. We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports. Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making devices sooner than we expected. We don't understand why these changes were made and it's a major turn in the wrong direction. Google is in the process of losing multiple antitrust cases in the US. Android and Chrome being split into separate companies has been requested by the DOJ. They may be preparing for it. We're hard at work on getting the port to Android 16 done but there's a large amount of additional work we weren't expecting. It can be expected to take longer than our usual ports due to the conscription issue combined with this. It's not good, but we have to deal with it. Having our own devices meeting our hardware requirements ( https://grapheneos.org/faq#future-devices ) would reduce the time pressure to migrate to new releases and could be used to obtain early access ourselves. Based on talks with OEMs, paying for what we need will cost millions of dollars.