Final

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 nostr:nevent1qqs84lmwyuq0svpjdm9ur0yeqw6pu0804e36ufymerlwl3cakwvamzgpr9mhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt9upzpva683gyt7a0nxlfedx648ca0whwm2aql3dezkt9z830k7nsm4leqvzqqqqqqyx7fagg

The first Security Preview release of #GrapheneOS is now live and available to opt in. Android has scheduled monthly security patch releases. For security patches, Google assigns patches to be released in different months in the future, and are then distributes them early to Android OEMs with a source code release embargo that lasts a month. This means that they fix certain vulnerabilities 3-4 months before an official publication date. This is problematic, as this is just a manual delay getting patches to users that can be taken advantage of by highly sophisticated threats. It is September 25th. There are security patches scheduled for December that aren't going to be released until then. By being able to opt-in to a Security Preview you get such patches before everyone. We will still work to make early patching in the main release branch of GrapheneOS as we have done already. These are all brand new changes we have access too thanks to our new OEM partnership. To keep GrapheneOS open source and not delayed open source, this will strictly be opt-in and on a separate release channel. Do not opt in if you do not want that. The Security Preview is for people: - Who want patches immediately, without the traditional 1 month delay. - Who want to perform security research / reverse engineering on the latest Android security patches. nostr:nevent1qqs29n0wjkuqsq9p4n64sm57ff4r777c8ez4y9vg0umydgp2p35chdcpzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqs3ejh6d

#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.

Next release of #GrapheneOS will add support to opt-in for Security Preview releases. These will be separate release channels for users to receive security patches that have source code and vulnerability information under an embargo. The next security preview contains early patches for 1 Critical vulnerability, and 54 High vulnerabilities.

For users of the 'Helium' browser going all over Twitter, it is ungoogled-chromium based, so the following flags are available. They advertised it on their site, but there's no full docs releases by them. Putting here so most can see it. Not an endorsement of a browser, especially one that is so new. People conscious about their security should stick to established apps that they trust. nostr:nevent1qqs8nspmpd7a3wa4j34sr4h62f6tjm5m3leq52hqkvz32lwy5yt7agqpzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqstt4nrk

This ergonomics shit is serious Put the top of your monitor at level to your eyes Avoid bending your neck Keep monitor an arms reach away Ensure shoulders do not shrug when you type Do not bend your wrists Do not lean forwards Keep arms, shoulders, legs straight Ensure feet are touching a surface Use an adjustable padded seat Make sure the height is high enough to sit with your knees further down than your thighs Have the back straight or very slightly leaned backwards Stand up and walk around every 30 minutes nostr:nevent1qqspsjqrq4ymurhev7a2fg5vcusp048th38e234swv8ref468q68mxq0glknf

Had to bring this burned npub post back. nostr:nevent1qqsvl6jxl5d3nhgttsp4hx7eyruypt5axqs0pjewryc58m360xc9a3sppamhxue69uh5qmn0wvhxcmmv9upzps26tfjesmn6ksf5mm36hpf9fkjut49sfeutfutvs2phrykn25v9qvzqqqqqqy56ghsr

Researchers at Trinity College Dublin, lead by Professor Doug Leith did a report to determine if Airplane Mode in #GrapheneOS and other devices actually disabled cellular. It doesnt have any cellular transmissions. https://www.scss.tcd.ie/Doug.Leith/pubs/airplane_mode_report.pdf There is a radio activity spike at the 2.4GHz band, this suggests Wi-Fi activity and is different from cellular network activity. All credit to Doug here: https://www.scss.tcd.ie/Doug.Leith/

The Linux kernel is a gigantic, complex project written pretty much entirely in a memory unsafe language. It is a monolithic kernel with no internal sandboxing/isolation and all the normal code running as part of them is fully privileged. A little typo causing memory corruption can be used to perform dangerous attacks. The Linux kernel alone is focused on performance and compatibility, not security. Even with the countless hardening work and security tools we make for Linux (hardened malloc), Linux is the core security liability in GrapheneOS. If people want the security of the operating system to go beyond, then the Linux kernel must be replaced with something new from the bottom up. Our roadmap page was updated to reflect our approach better. The initial phase for the long-term roadmap of GrapheneOS is to deploy and integrate pKVM and CrosVM. We would securely deploy Android apps in virtualized environments using this virtualization setup. Virtualization will allow us to contain Linux. In the longer term, Linux inside the sandboxes can be replaced with a compatibility layer like gVisor, which would need to be given a new backend alongside the existing KVM backend. Over the longer term, i.e. many years from now, Linux can go away. https://grapheneos.org/faq#roadmap nostr:nevent1qqsdppwg3kxyrvjrg72zktwuet34mt0mun59jd87f9jpaasx48nhjcqpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqp4l8nxy

Essential reading for hard-line GrapheneOS users in the quote note. Almost all of the major state-sponsored or mercenary exploits you hear about are possible through memory corruption vulnerabilities in their exploit chain. They make up most of the Critical / High vulnerabilities in Android even when the amount of them have reduced due to an increase in code written in memory safe languages. nostr:nevent1qqsf2clydtds9atzew6qgkzvvur3kz4prxskfmmszetx9cj06jdw0vgppemhxue69uhkummn9ekx7mp0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqpz8cus2