Final's avatar
Final
final@stacker.news
npub1hxx7...g75y
Digital forensics and security specialist part of the GrapheneOS project. Posts my own and not endorsed by my employer. AI slop and Nostr DMs ignored. Matrix: f1nal:grapheneos.org
Final's avatar
Final 9 months ago
A cold, hard truth a lot of social media influencer privacy / security enthusiasts won't like to admit about themselves is that you are likely to know much less than you think you actually do. Including myself. A cyber security professional who uses all the normie-tier, status quo products will be far more safe than someone who isn't a professional and is using software focused on privacy or security. If you want to know more you need to study with the mentality like you want to be a professional. The former groups of people know and understand the products they use and their security properties. Depending on the role they also know how to reverse engineer, discover vulnerabilities and have a consistent threat model when building defences. The latter are often using a product because some place online told them to without much critical care or observation. It shows a lack adaptive technical skills, approach or mindset. Talented hackers and security professionals using Windows, Apple products and more aren't hiding some secret incompetence. They just know what their requirements and demands are and their choices fill them. They know they can move and use something tougher at any time should their needs change. Changing a software or a device choice is only a small part. It's a shame that a lot of online spaces have this mentality that many things are completely compromised in secret, when in reality this only works in a nonsensical dystopia where all the intelligent people ONLY work with their perceived threat (whether it is secretive agencies, governments, some advanced actor or whatever else) and the common man is stupid. This is the same mentality that some, like flat earthers, believe how the world is run. Being a hacker is all about learning how things work, how do you think people get to understand malware without source code? How do the bad guys break into systems they never touched? Reading can only do so little in a specialty that changes frequently and information is outdated all the time. A book or and not every forum post can't get updated. If you want to start getting serious, log off the forums and go on a security lab platform and check out their guided training, or take a course, or get a entry level job.
Final's avatar
Final 9 months ago
#GrapheneOS Important Statement One of our two senior developers has been forcibly detained and conscripted to participate in a war. When they first went missing, we revoked their repository access as a precaution. We soon learned their disappearance was completely unrelated to GrapheneOS. Our priority has been keeping them safe. We've used our available connections to try to keep them safe. There's no way to get them out of the conscription. However, they're an incredibly talented security researcher and engineer and it would be extraordinarily misguided to send them to front line combat. This seems to be understood now. GrapheneOS development and updates have continued and will keep going. We have substantial funds available to hire multiple experienced developers. We'll need to hire multiple experienced developers to fill their big shoes. They'll hopefully be safe and when they return we'll have a bigger team. If you're an experienced AOSP developer interested in working full time on GrapheneOS in a fully remote position, see the hiring page at: We can pay people anywhere in the world via BTC, XMR, ETH or Wise (local bank transfers). We need people who can hit the ground running due to the current situation. Our near term focus is going to heavily shift to Android 16 porting, maintenance and continuing to do better patching than standard Android 15 QPR2. An OEM providing us early access to Android 16 sources would help a lot and we wouldn't need to slow down new feature development nearly as much.
Final's avatar
Final 10 months ago
Our initial highly experimental release for the Pixel 9a is now available for both CLI and web install via We've tested both install methods and did basic testing of functionality including Wi-Fi, camera, audio, etc. Feedback is needed from users now. We've tested the over-the-air upgrade path for the Pixel 9a internally via a sample update with no changes. We usually only use these sample updates internally for testing the upgrade path of each release. However, for broader testing, we're releasing it through each channel now. First update from the initial 2025041200 release to the new 2025041201 release has no changes beyond build date and build number. The incremental (delta) update package is only 158KiB despite it shipping the full new firmware and OS images. We tested a full update package too. Basic functionality has been tested for a while along with the upgrade path via both our System Updater app and recovery. It no longer needs to be considered highly experimental. Therefore, experimental Pixel 9a releases are now available on our regular production website too. All of the standard Android and #GrapheneOS functionality should already be working on the Pixel 9a including our hardware-based USB-C port control feature, hardware memory tagging, etc. Main work was dealing with the temporary QPR1-based device branch.
Final's avatar
Final 10 months ago
OpenSSL 3.5.0 was recently released with support for Post Quantum Cryptography (PQC). The package update is now deployed across our servers. Our web services now use hybrid PQC key exchange with clients supporting it. Easy to confirm X25519MLKEM768 gets used in Chromium browsers.
Final's avatar
Final 10 months ago
Our 2025040700 release was an early April 2025 security update release based on the Android Security Bulletin backports. April 2025 monthly release of Android 15 QPR2 is in the process of being published today and we'll make a new release after the tags are all pushed to AOSP. Today is also the launch day for the Pixel 9a. The tags for the Pixel 9a should get pushed to AOSP after the monthly update is fully pushed. Once that's pushed and we've released the April update of Android 15 QPR2, we can start working on adding Pixel 9a support to #GrapheneOS. We have a Pixel 9a ordered for our main device farm which has been marked as ready for pickup by the delivery company. It will hopefully be delivered tomorrow. We've generated signing keys and added preliminary support to Auditor and AttestationServer which will need testing. April 2025 update for the Pixel 9a stock OS is still based on Android 15 QPR1 rather than Android 15 QPR2. They updated the device branch to the April 2025 security patch level via backports from Android 15 QPR2. Our initial port will be from our final Android 15 QPR1 release. Our final Android 15 QPR1 release was 2025030300 which was the first Monday of March, which was the day the Android Security Bulletin was published so we made a similar early security update release based on it. Android 15 QPR2 was released the next day (March 4th). Pixel 8a launched in a similar way based on Android 14 QPR1 instead of Android 14 QPR2. It was the first time it happened that way, and now they've repeated it with the Pixel 9a. It's strange to launch a new device on the previous major OS release with security backports instead. Android 14 QPR3 was released less than a month after the Pixel 8a and it was merged into the mainline releases. It's not clear if the Pixel 9a will get an update to Android 15 QPR2 or move straight to Android 16 in June. Either way, it will have a device branch until Android 16.
Final's avatar
Final 10 months ago
Android Security Bulletin for April 2025 has 2 more vulnerabilities marked as being exploited in the wild. We've fully blocked exploiting both vulnerabilities for locked devices for years, before 2024. Our defenses against these attack vectors have been greatly improved since 2024. #GrapheneOS fully prevented exploiting both vulnerabilities for locked devices, made both far harder to exploit while unlocked and already had both patched for a while too. CVE-2024-53150: heap overflow (read) in a Linux kernel USB sound card driver CVE-2024-53197: heap overflow (write) in a Linux kernel USB sound card driver These vulnerabilities were being exploited by Cellebrite for data extraction from locked Android devices without GrapheneOS. We have a post from late February about CVE-2024-53197 and 2 other bugs exploited by Cellebrite which they were blocked from exploiting by GrapheneOS: CVE-2024-53150 is almost certainly part of the same batch of vulnerabilities they've been exploiting. covers how we've greatly improved the GrapheneOS defenses against these attacks since early 2024. We're continuing to work on improving it. We helped get firmware security improvements to Pixels and are advocating for further hardware/firmware changes.
Final's avatar
Final 10 months ago
Macarne (https://macarne.com/) has provided a sponsored server to replace our current EU update servers so we can handle current traffic and near future growth. Ryzen 9950X, 128GB RAM, 2x 2TB NVMe and most importantly 25Gbps bandwidth. It's greatly appreciated! We use GeoDNS and round-robin DNS to distribute load across our servers with automatic failover. Ideally, we can find a good 2nd provider willing to provide sponsored/discounted 2x 10Gbps servers to cover each coast of North America. 2x 25Gbps would be great but not needed yet. Our existing setup was 8x 2Gbps OVH VPS instances with 4 in Quebec, 2 in France and 2 in Germany. This was getting increasingly overloaded for the 4 major releases per year, and the largest one (Android 16) is coming up soon. European bandwidth usage is also around 50-60% higher. #GrapheneOS
Final's avatar
Final 10 months ago
Android has always taken the approach of it being developed in private and then having the full sources and commit history published for each stable release. This approach used to be the norm for open source software many years ago, but now most projects do a lot of their development in the open. Commit history being available also didn't used to be the norm many years ago but rather only tarballs for releases. It's very important for them to provide it, but it would be open source without it. They're still going to be providing it. Certain sub-projects were developed in the open as part of the public Android Open Source Project repositories in the main branch but the bulk of the work was done in private. They maintained both a public main branch and an internal development branch and had to merge back and forth between them. Recently, Google announced they'll be shifting most of the small subset of the OS developed in the AOSP main branch to being developed internally instead. The full commit history will still be available when stable releases are published as it for the majority of AOSP developed that way already. AOSP main was not where most of the OS was developed and would get most of those changes merged into it shortly after each stable release. AOSP main also doesn't correspond to Developer Preview and Beta releases, which are separate branches and what we need for porting before a Stable release. The small subset of the OS developed via AOSP main moving away from it won't have a major impact on GrapheneOS. It did not provide us with early access to the code we need for porting #GrapheneOS to an upcoming release before the day it gets released. That already required having partner access. Android is remaining open source and simply being slightly less open about the development of certain components. We won't be able to see the commits as they're made for that small subset of components anymore but rather need to wait until they publish the full commit history for stable releases. In contrast with Android, Chromium is developed almost entirely in the open and we can port and test all of our changes to the upcoming releases before there's a Stable release. This is very helpful and makes maintenance much easier for us. Doing this for Android already required partner access. We've already been in the process of figuring out how to get partner access in a way that will be reliable and long term. There was only one year where we had early access to a new major release. We haven't had it for several years and we still manage to get the yearly releases out in a couple days.
Final's avatar
Final 10 months ago
Our latest 2025032500 release greatly improved our built-in network-based location. It's usually better than Google's network-based location in urban areas where Apple has competitive data. Unlike Google's service, position estimation is done locally by fetching location data for nearby networks. You can enable this feature via the toggle we added at Settings > Location > Location services > Network location. You can optionally enable the standard Wi-Fi scanning toggle in the Location services menu to allow Wi-Fi scans when Wi-Fi is otherwise disabled to keep network-based location working. Our implementation is currently based entirely on Wi-Fi Access Points (APs). Location data for nearby APs is fetched in batches from either Apple's service or a GrapheneOS proxy server. We also ask the service for up to 100 nearby APs which it provides with a reasonable density over a large area. Our implementation caches location data for up to 10000 APs in an in-memory Least-Recently-Used cache with 15 minute expiry after last usage of an AP. This avoids persisting a local location history while enabling semi-offline usage. We can make these parameters user configurable in the future. Most navigation apps use the fused location service providing the best result from GNSS (GPS, Galileo, etc.) or network-based location (when it's enabled). Other apps often prefer network-based location for lower power usage and quicker results not requiring GNSS reception. Some apps can't use GNSS. Most apps on the Play Store use the Google Play services location service instead of the OS provided location service. By default, our sandboxed Google Play compatibility layer reroutes location requests from these apps to the OS location service so there's no need to give Location to Play services. Nearly all users on Google Mobile Services devices have their network-based location enabled. This means some apps assume it's always available. For improved compatibility, our default enabled rerouting emulates the presence of network location with GNSS when the OS network location service is off. In the near future, we'll be making several major improvements to our network location service including Wi-Fi RTT (Round-Trip-Time) for improved distance estimation and cell tower fallback to make it work better outside cities. There will also be a lot more efficiency and other improvements to it. Longer term, we'll be providing our own location service rather than only a proxy along with full offline support via database downloads. It already works offline for a while based on the cache. We'll be using data from Apple's service to bootstrap our service, but we'll also be using other sources. Source code is available here: It's new code and still being built out so it hasn't had much refactoring, optimization or tuning yet. It's a mix of Kotlin and Rust since we wrote position estimation in Rust for significantly better performance. #GrapheneOS