Twitter for you feed is so awful. Even after following accounts the recommendations stink.

Since he is attacking us again, did you know that Rob Braxman's 'private' and 'encrypted' chat service is backdoored with fake end to end encryption? It's been like this for years. Make two accounts, and create an 'encrypted' chat with a room password to your other account. Make it anything you want. Then, on the browser of the user who did not create the room, go to your chat page then open the browser dev tools, go to the Network tab. Open the encrypted chat, then find "chatkey.php" in the resources section of the browser. You can then go to "Payload". The password of the room is sent to you by the server in plain text.

What I can say for now: - #GrapheneOS has partnered with a major Android OEM. One of the top ten. - We aim to have a device by H2 2026, but potentially 2027. - We have early source access for patches and, soon, major releases through our partner. - We are aiming to get their next generation flagship devices able to support installing GrapheneOS. - The device will have the flagship Snapdragon 8 Elite 2 (SM8850) SoC. - We will continue to support Pixels if they continue to release with support. We will also aim to have Pixel 10 support once Android 16 QPR1 sources are available. View quoted note →

Cool View quoted note →

Just saying... #GrapheneOS 2025100300: - add support for force enabling VoLTE, VoNR and 5G for carriers where those aren't supported with the standard configurations

Releases | GrapheneOS

View quoted note →

#GrapheneOS version 2025100900 released: RCS compatibility fixes, kernel updates and opt-in dialog for security preview updates in this new version. The first January 2026 ASB security patches are also now available in the 2025100901 security preview. One of the changes in this release should result in Google Messages RCS working for users receiving a verification error caused by Play Store checking for an emulator with an easy to bypass check. It was already working for many users without this but this should get it working for everyone else. • raise security patch level to 2025-10-05 since it's already provided without applying any additional patches • System Updater, Setup Wizard: integrate support for recommending opting into security preview releases during the initial Owner user setup and for existing users via a persistent notification which is disabled after making an explicit choice on whether to use security preview releases (this is necessary to inform all users about the option with an explicit choice) • Settings: add support for forcing VoWiFi availability • Settings: improve the carrier configuration override by improving the summaries, adding detailed descriptions and using clarifying the options force features to be available since there are also toggles for directly enabling/disabling the features in the main SIM settings screen • Sandboxed Google Play compatibility layer: fix a Google Messages RCS compatibility issue by removing the error string for the missing privileged permission from SurfaceFlinger::doDump() to make a DroidGuard check pass • Sandboxed Google Play compatibility layer: make Play Store ignore app auto-install config • Sandboxed Google Play compatibility layer: fix Build.getSerial() shim to fix an Android Auto issue • Sandboxed Google Play compatibility layer: add stub for TelephonyManager.getImei() • Sandboxed Google Play compatibility layer: add stub for Window.setHideOverlayWindows() to replace reliance on a feature flag override via GmsCompatConfig • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.155 • update test suite to handle our carrier overrides support • Vanadium: update to version 141.0.7390.70.0 • Camera: update to version 90 All of the Android 16 security patches from the current November 2025, December 2025 and January 2026 Android Security Bulletins are included in the 2025100901 security preview release. List of additional fixed CVEs: • Critical: CVE-2025-48593 • High: CVE-2022-25836, CVE-2022-25837, CVE-2023-40130, CVE-2024-43766, CVE-2025-22420, CVE-2025-22432, CVE-2025-32319, CVE-2025-32348, CVE-2025-48525, CVE-2025-48536, CVE-2025-48544, CVE-2025-48555, CVE-2025-48567, CVE-2025-48572, CVE-2025-48573, CVE-2025-48574, CVE-2025-48575, CVE-2025-48576, CVE-2025-48577, CVE-2025-48578, CVE-2025-48579, CVE-2025-48580, CVE-2025-48581, CVE-2025-48582, CVE-2025-48583, CVE-2025-48584, CVE-2025-48585, CVE-2025-48586, CVE-2025-48587, CVE-2025-48589, CVE-2025-48590, CVE-2025-48592, CVE-2025-48594, CVE-2025-48596, CVE-2025-48597, CVE-2025-48598, CVE-2025-48600, CVE-2025-48601, CVE-2025-48602, CVE-2025-48603, CVE-2025-48604, CVE-2025-48605, CVE-2025-48607, CVE-2025-48609, CVE-2025-48612, CVE-2025-48614, CVE-2025-48615, CVE-2025-48616, CVE-2025-48617, CVE-2025-48618, CVE-2025-48619, CVE-2025-48620, CVE-2025-48621, CVE-2025-48622, CVE-2025-48626, CVE-2025-48628, CVE-2025-48629 CVE-2025-48595 was fixed in the regular GrapheneOS 2025100300 release and is no longer listed.CVE-2025-48611 patch was retracted.2025100901 provides at least the full 2025-11-01 patch level and the Android 2025-11-05 patch level (Pixel Update Bulletin could have fixes we don't get early) but will remain marked as providing 2025-10-05.

Releases | GrapheneOS

See more about information on how OEMs like Samsung provide patches and our early patching through security preview releases. View quoted note →

Next #GrapheneOS security preview will contain the security patch scheduled for the January 2026 Android Security Bulletin. This adds patches to 5 High severity vulnerabilities. This increases the amount of early patched Critical/High vulnerabilities to 58. One vulnerability was fixed in the previous regular GrapheneOS release. One other was retracted. These are not in the count.

Redox OS was ported to a Pixel. Currently, only the screen works.

This Month in Redox - September 2025 - Redox - Your Next(Gen) OS

The Redox official website

I am never calling EnCase 'OpenText Forensic', don't be silly

Our security preview releases provide early access to Android Security Bulletin patches prior to the official disclosure. Our current security preview releases provide the current revision of the November 2025 and December 2025 patches for the Android Open Source Project. We recommend enabling this. The only difference between our regular releases and security preview releases are the future Android Security Bulletin patches being applied with any conflicts resolved. The downside of security preview releases is we cannot provide the sources for the patches until the official disclosure date. The delay for being able to publish the sources is why we're now going through the significant effort of building 2 variants of each release. Our most recent 3 releases have both a regular and security preview variant: 2025092500 and 2025092501 2025092700 and 2025092701 2025100300 and 2025100301 You can enable security preview releases via Settings > System > System update > Receive security preview releases. Our plan is to keep it off-by-default with a new page added to the Setup Wizard which will have it toggled on as a recommendation. We'll prompt users on existing installs to choose. We're maintaining the upcoming Android security patches in a private repository where we've resolved the conflicts. Each of our security preview releases is tagged in this private repository. Our plan is to publish what we used once the embargo ends, so it will still be open source, but delayed. The new security update Android is using provides around 3 months of early access to OEMs with permission to make binary-only releases from the beginning. As far as we know, #GrapheneOS is the first to take advantage of this and ship the patches early. Even the stock Pixel OS isn't doing this yet. During the initial month, many patches are added or changed. By around the end of the month, the patches are finalized with nothing else being added or changed. Our 2025092500 release was made on the day the December 2025 patches were finalized, but we plan to ship the March 2026 patches earlier. Previously, Android had monthly security patches with a 1 month embargo not permitting early releases. For GrapheneOS users enabling security preview releases, you'll get patches significantly earlier than before. We'd greatly prefer 3 day embargoes over 3 month embargoes but it's not our decision. Security preview releases currently increment the build date and build number of the regular release by 1. You can upgrade from 2025100300 to 2025100301 but not vice versa. For now, you can switch back to regular releases without reinstalling such as 2025092701 to 2025100300, but this may change.

The remaining core developer working on CalyxOS (Tommy Webb) left the organization. That leaves almost no one working on the project. One of their core developers left prior to this being public, their lead developer left following that and then the leader of the organization left too. You can see from https://review.calyxos.org/q/status:open that they were the remaining active core developer. Their initial 4-6 month estimate for resuming updates on August 1st is looking overly optimistic. CalyxOS users still don't have the 2025-06-05 patch level or above including being missing the Critical severity remote cellular radio vulnerability from June 2025, other driver/firmware patches from June 2025, driver/firmware patches from August 2025 or the massive set of September 2025 patches for both AOSP and Pixels. It's increasingly unsafe for remaining CalyxOS users to continue using it especially since 2 of the September 2025 vulnerabilities are marked in the bulletin as being known to be exploited in the wild. It's worth noting they don't go back and update past bulletins with news about in the wild exploitation being discovered, that information is only provided when the issues are first patched and then it's assumed everyone is updated to them. The in the wild exploitation info is only provided for what Android considers 0 days in terms of the Android Security Bulletins, not N days after patches are officially disclosed. That's also based on very limited insight into exploitation, as far more issues are exploited in the wild prior to being patched in reality. View quoted note →

#GrapheneOS version 2025100300 released: • add support for force enabling VoLTE, VoNR and 5G for carriers where those aren't supported with the standard configurations • revert backport of Pixel Wi-Fi extension APEX from Android 16 QPR1 due to it causing a system_server crash since system_server needs changes there too (this does not reduce the patch level) • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.154 • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.108 • kernel (6.12): update to latest GKI LTS branch revision including update to 6.12.49 • update SQLite to 3.44.5 LTS release • Network Location, System Updater: add new Let's Encrypt roots to TLS key pinning configuration • GmsCompatConfig: update to version 162 • Camera: update to version 89 Additional security patches from the November 2025 and December 2025 Android Security Bulletins are included in the 2025100301 security preview release.

Releases | GrapheneOS

This is the same project who claimed to make their app only for Apple platforms for anonymity and numerous inaccurate privacy claims for Android on why they wouldn't support it... I don't know why they didn't assume Apple would do such a thing, they did it with a similar Hong Kong protest map app years ago. Apple store which accounts, devices install which apps. They also force apps to use their push notification service. View quoted note →

#GrapheneOS version 2025092700 released. This release adds official support for using RCS in the Google Messages app if you use Sandboxed Google Play and choose to install it. Using this requires granting the Phone permission to Play services to provide carrier information to it, granting the required permissions to Google Messages and then setting Google Messages as the current carrier messaging app. Setting an app as the carrier messaging app provides it with device identifier access which is documented in our FAQ. However, Google Messages is a special case where part of the implementation is in Play services. We've dealt with this by special casing the device identifier permission check to detect when the user has granted this access to the official Google Messages app which then also provides the official Play services app with the same access. This doesn't provide any extra access in practice since Google Messages shares the information with Play services. Re-enabling RCS after disabling it isn't expected to work yet and you'll need to clear the app data to enable it. • add SystemUI and Settings integration for detecting and notifying Pixel 6a users with batteries impacted by the fire hazard issue resulting in capacity and charging being throttled along with directing users to the support options for getting a free battery replacement, $150 credit or $100 cash as compensation for the faulty battery (a subset of this will be replaced by AOSP code when Android 16 QPR1 is finally pushed to AOSP) • Sandboxed Google Play compatibility layer: add request for the unprivileged READ_PHONE_NUMBERS permission to Play services since it's needed for RCS activation but is not requested since they request the privileged permission instead • Sandboxed Google Play compatibility layer: when users have granted device identifier access to the official Google Messages app by setting it as the default SMS/MMS/RCS app • Vanadium: update to version 141.0.7390.43.0 • Vanadium: update to version 141.0.7390.43.1

Releases | GrapheneOS

Please do not daily driver Kali Linux for home computing. That's not what you use it for Somehow seeing this happen. Don't do it

Latest Vanadium release adds support for WebAssembly even when JavaScript JIT is disabled. - Enable support for the DrumBrake WebAssembly interpreter previously exclusive to Microsoft Edge to support WebAssembly when JIT compilation is disabled. JIT compilation is disabled by default in Vanadium with a per-site toggle to opt into it for improved performance that's rarely needed. Vanadium also blocks dynamic code generation via seccomp-bpf in processes other than the per-site renderer sandboxes for sites where the user has enabled JIT compilation. WebAssembly normally depends on JIT compilation and users previously had to enable the per-site JIT toggle for sites requiring it even if the improved performance of JIT compilation wasn't needed. It should no longer be necessary to enable the per-site JIT toggle for compatibility reasons, only if users want to improve the performance of a demanding web application. Certain optional WebAssembly features aren't yet supported by the DrumBrake interpreter but this shouldn't reduce compatibility in practice since dynamic detection with fallback code is already required for broad compatibility. #GrapheneOS View quoted note →

#GrapheneOS version 2025092500 and Security Preview 2025092501 released: This update adds more Android 16 QPR1 backports and the ability to opt-in to Security Preview updates. The Security Preview update channel have very early full patches that are held under an embargo. The first Security Preview will contain extremely early security patches scheduled to be released in Android by December. The security preview provides patches for 55 (1 critical, 54 high) vulnerabilities. Changes added to 2025092500: - System Updater: add support for opting into security preview releases - backport more cellular related code from Android 16 QPR1 - backport Pixel Wi-Fi extension APEX from Android 16 QPR1 - Vanadium: update to version 140.0.7339.207.0 Additional security patches from the November 2025 and December 2025 Android Security Bulletins are included in the 2025092501 security preview release. List of additional fixed CVEs: Critical: CVE-2025-48593 High: CVE-2022-25836, CVE-2022-25837, CVE-2023-40130, CVE-2024-43766, CVE-2025-22420, CVE-2025-22432, CVE-2025-32348, CVE-2025-48525, CVE-2025-48536, CVE-2025-48544, CVE-2025-48555, CVE-2025-48567, CVE-2025-48572, CVE-2025-48573, CVE-2025-48574, CVE-2025-48575, CVE-2025-48576, CVE-2025-48577, CVE-2025-48578, CVE-2025-48579, CVE-2025-48580, CVE-2025-48581, CVE-2025-48582, CVE-2025-48583, CVE-2025-48584, CVE-2025-48585, CVE-2025-48586, CVE-2025-48587, CVE-2025-48589, CVE-2025-48590, CVE-2025-48592, CVE-2025-48594, CVE-2025-48595, CVE-2025-48596, CVE-2025-48597, CVE-2025-48598, CVE-2025-48600, CVE-2025-48601, CVE-2025-48602, CVE-2025-48603, CVE-2025-48604, CVE-2025-48605, CVE-2025-48607, CVE-2025-48609, CVE-2025-48611, CVE-2025-48612, CVE-2025-48614, CVE-2025-48615, CVE-2025-48616, CVE-2025-48617, CVE-2025-48618, CVE-2025-48619, CVE-2025-48620, CVE-2025-48621 We're allowed to provide an early release with these patches and to list the CVEs but must wait until the embargo ends to publish sources or details on the patches. We strongly disagree with broadly distributing patches to OEMs 3-4 months before the official publication date. It further delays getting patches to users and sophisticated attackers will have no issue getting the patches from one of many people at Android OEMs with early access. It should be limited to at most 7 days. The lack of actual secrecy has been acknowledged through Android limiting the embargo to source code and details which allows us to fix these early. We're doing it with separate opt-in releases to keep the regular releases properly open source instead of delayed open source. We plan to integrate this choice into the initial setup wizard. The positive side is that we can now provide patches to people who truly need them without even the previous 1 month embargo delay.