GrapheneOS

Vanadium version 145.0.7632.120.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/145.0.7632.120.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/32310-vanadium-version-145076321200-released
#GrapheneOS #privacy #security #browser

2026-02-23 23:46:40 CET

- reply

@nprofile…5004 @nprofile…n06l Not quite sure what you mean but nothing has changed about this UI in any recent releases. Opening the power menu doesn't cause power off or restart unless you tap the buttons.

2026-02-23 19:29:56 CET

- reply

@nprofile…zev9 If it was a competitive market, then Google would want as many people as possible using their apps and services so they would make them work elsewhere themselves. Our Sandboxed Google Play compatibility layer is only coercing Google's apps to do what they should be doing anyway which is falling back to working as regular apps with no special access. They could choose to do everything we're doing themselves to make their apps work on any Android OS as regular sandboxed apps.

2026-02-23 19:28:54 CET

- reply

@nprofile…zev9 The sad part is that Google Pay can work on GrapheneOS on a technical level. There have been times when they turned off the Play Integrity API verification due to an outage or a mistaken where it worked fine for GrapheneOS users for a while. They could be verifying GrapheneOS via the hardware attestation API but they're being explicitly anti-competitive by forbidding anything other than an OS officially licensing Google Mobile Services to push their other services via their monopolies.

2026-02-23 08:00:31 CET

- reply

@nprofile…vehq It will be part of the next GrapheneOS OS update.

2026-02-23 01:18:39 CET

- reply

@nprofile…l29u Yes, in March 2026.

2026-02-22 23:55:17 CET

hardened_malloc version 14 released:
https://github.com/GrapheneOS/hardened_malloc/releases/tag/14
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/32249-hardened-malloc-version-14-released
This is a standalone release for use outside of GrapheneOS. GrapheneOS ships these changes shortly after they're implemented as part of our OS releases rather than waiting for these releases.
#GrapheneOS #privacy #security

2026-02-22 19:29:51 CET

- reply

@nprofile…0sev There's announcement next month for the devices will be in 2027.

2026-02-22 19:04:49 CET

- reply

@nprofile…65q8 Our expectation is that it will remain possible to install the apps with developer options by using ADB and that they'll also likely provide a way to install them without ADB with a more complex warning flow. It's worth noting Play Protect already existed and was possible to bypass via ADB and the new API they added to AOSP for the more modern take on the planned feature can also be bypassed via ADB. They can likely implement it retroactively going back many years via a Google Play update.

2026-02-22 19:01:26 CET

- reply

@nprofile…s4ce Buying used devices is already an option. Pixel 8 and later have 7 years of support from launch so it's a better time than ever to get the devices used rather than new.
7 years means something different for a Pixel 8 than many other devices advertising similar support. A Fairphone 5 already has an end-of-life 5.4 kernel and gets both OS updates and partial security backports to older releases very late. Shipping updates years late is portrayed as years of extra support vs. other devices.

2026-02-22 18:57:18 CET

- reply

@nprofile…65q8 It's hardly a crisis and won't result in any warnings being displayed for the vast majority of app distribution outside of the Play Store.
Not all open source app developers will want to perform the verification. Their apps can be signed and distributed by others willing to do it to avoid it being more complex to install the apps on Google Mobile Services devices.
It has no direct impact on GrapheneOS since we don't include GMS and don't give GMS apps privileged access when installed.

2026-02-22 18:54:17 CET

- reply

@nprofile…65q8 Distributing either developer builds of apps or builds done by packagers for an app repository will still work fine for both Google Mobile Services operating systems and alternatives including GrapheneOS.
On the Google Mobile Services operating systems, there's going to a more complex warning flow for apps signed with keys not belonging to Google Play verified developers.
Here's a better post about it with more accurate info on what's changing and the impact:
https://blog.accrescent.app/posts/android-developer-verification/

2026-02-22 18:46:51 CET

- reply

@nprofile…65q8 @nprofile…8vnj @nprofile…pljj The partnership is being announced in March 2026. The devices are planned for 2027. You'll need to replace your Pixel 6 prior to the devices launching. We don't recommend using end-of-life devices and don't expect Pixel 6 support to be extended. We may keep releasing basic updates for the Pixel 6 for a while but we won't pretend that applying AOSP backports and Linux kernel LTS revisions is enough. No more driver/firmware support will be the end of it being safe to use.

2026-02-22 18:45:13 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 Many people want a genuinely highly private and secure device with many years of proper updates. They can get that with an iPhone and they can get it with GrapheneOS as an open source alternative. GrapheneOS is succeeding and becoming increasingly mainstream. It's far more usable and suited for production use than any of the alternatives. The fact that we won't take the shortcut of using insecure devices is why a major OEM is actively working on making what we need.

2026-02-22 18:38:07 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 GrapheneOS has a large and rapidly growing userbase. Many people care about privacy and security who aren't misled into believing operating systems and hardware far worse at both than an iPhone are the answer.
Instead of supporting devices not meeting bare minimum privacy and security standards, we're working on proper devices meeting our full requirements with an OEM partner. They're one of the largest smartphone companies and are announcing our partnership next month.

2026-02-22 18:35:02 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 GrapheneOS is a privacy and security hardened OS and has hardware requirements based on it. The only laptops/desktops meeting similar requirements are from Apple but it's unclear how much of the security features could be used elsewhere.
GrapheneOS and the Android Open Source Project are Linux distros. It's not glibc, systemd and GNOME which make it Linux. Most of the software you're calling Linux isn't even Linux specific but rather also works on FreeBSD, Hurd, etc.

2026-02-22 18:30:11 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 Fairphones are missing important hardware-based security features. They use largely the same components as other phones but it's quite outdated hardware for overly high prices. Buying newly produced outdated hardware with poor updates is hardly sustainable. The reality is more resources are likely used to produce each than an iPhone due to the efficiency of scale. iPhones have far better updates, also provide long term parts/repairs and much better privacy + security.

2026-02-22 18:29:48 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 Fairphones are missing important hardware-based security features. They use largely the same components as other phones but it's quite outdated hardware for overly high prices. Buying newly produced outdated hardware with poor updates is hardly sustainable. The reality is more resources are likely used to produce each than an iPhone due to the efficiency of scale., iPhones have far better updates, also provide long term parts/repairs and much better privacy + security.

2026-02-22 18:24:45 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 The vast majority of smartphones either don't allow installing another OS or have extremely poor support for it including crippling the security of the device if people do it. In general, people who want to use another OS on a smartphone need to buy a device with it in mind. Supporting more models wouldn't change much especially a device like the Fairphone with far less distribution than Pixels. What would be the purpose of supporting an insecure device with bad updates?

2026-02-22 18:23:02 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 Pixels are the only smartphones with competitive hardware, firmware and software security with iPhones. They're the only non-iOS devices providing reasonably good long term updates and support. Fairphone markets their devices as providing it but they don't actually do it. They're lagging a year or more behind on OS updates, skipping non-yearly updates entirely and a month or two behind on the bare minimum Android schedule for patches which are available to ship earlier.

2026-02-22 18:20:33 CET

- reply

@nprofile…8vnj @nprofile…pljj @nprofile…65q8 Fairphones have very poor updates, privacy and security regardless of OS choice.
Fairphone doesn't provide proper updates from day 1. Fairphone 5 launched September 2023 and already has an end-of-life 5.4 kernel branch with no plan to upgrade. They weren't providing the kernel updates when they were available themselves but another OS could have done it and now it's impractical. Fairphone similarly doesn't keep the drivers, firmware and other components properly updated.

2026-02-22 05:36:28 CET

Our email server (mail.grapheneos.org) has been migrated to our bare metal server sponsored by Xenyth in Toronto. We're now using clean IP space announced via BGP with our AS to improve email deliverability by not having IP/AS neighbours sending spam.
https://bgp.tools/dns/mail.grapheneos.org

2026-02-20 22:34:35 CET

- reply

@nprofile…eud6 @nprofile…65q8 @nprofile…8vnj Android doesn't require any downstream kernel patches and works fine with mainline Linux kernels. All of the kernel drivers for Android are typically open source. The issue of SoC vendors and other hardware vendors providing software support in the form of proprietary libraries and services such as the ARM Mali GPU library isn't specific to Android or caused by Android. Android having a standard hardware abstraction layer with sandboxing isn't a vendor concession.

2026-02-20 22:32:41 CET

- reply

@nprofile…eud6 @nprofile…65q8 @nprofile…8vnj Android follows upstream LTS more closely than Ubuntu. The person leading the work on the upstream LTS kernels (Greg KH) works for Google and maintains the GKI LTS branch for Google too. The upstream LTS kernels have Android as their main target. Pixel 6 moving to 5 years of support is why the kernel.org LTS kernels had support extended to 5 years. Pixels began moving to new LTS branches and moved to 7 years so upstream LTS dropped to 2 years. Is Ubuntu not Linux?

2026-02-20 19:26:19 CET

- reply

@nprofile…cfpe @nprofile…0vpy A major Android OEM contacted us in June 2025 and we're working with them as partners. They're improving a subset of their future devices to meet our requirements and provide official GrapheneOS support. An announcement about it is being made in March 2026 and the devices will be launched at some point in 2027.
In the meantime, there aren't non-Pixel devices we could use where we can provide strong privacy and security. We won't pretend otherwise to get more users with it.

2026-02-20 19:23:40 CET

- reply

@nprofile…cfpe @nprofile…0vpy
> Unfortunately i dont have the advanced knowledge to know who is right
Listen to privacy and security experts instead of the company marketing their products. Murena are selling phony privacy products and services with poor privacy and security.
> Grapheneos is for me also no option because, i dont want to give google my money by buying a google phone.
Pixels are currently the only devices meeting the update and security requirements. They can be bought as used devices.

2026-02-20 19:11:32 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8 You've repeatedly made inaccurate posts about GrapheneOS and our team including outright lying about us. You post aggressive responses to our replies which disparage us and try to portray us badly by framing what we've said in a negative light regardless of the fact that we've only posted an accurate technical comparison. You can't tolerate us defending ourselves and providing accurate information. You respond to that with aggression and toxicity. It's you who is toxic.

2026-02-20 18:45:28 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8
> Why did you chose the word "atrocious"?
It's an accurate and important description of the state of desktop operating systems. No one should be under the impression that a traditional desktop OS is providing strong privacy or security.
> You don't find that aggressive?
No, it's an accurate technical statement about Windows, desktop Linux distributions and to a lesser extent macOS compared to iOS and AOSP.
Meanwhile, you're disparaging us with dishonest claims...

2026-02-20 18:43:26 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8 A plain Android system without modification in a fork is the Android Open Source Project. It provides a much higher level of privacy and security. LineageOS reduces privacy and security compared to that baseline but is still far more private and secure than traditional desktop Linux distributions.
Stock Pixel OS and every other OEM variant of Android are forks of AOSP just like GrapheneOS. AOSP is the reference implementation of Android and is the upstream project for it.

2026-02-20 18:42:51 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8 A plain Android system without modification in a fork is the Android Open Source Project. It provides a much higher level of privacy and security. LineageOS reduces privacy and security compared to that baseline but is still far more private and secure than traditional desktop Linux distributions.
Stock Pixel OS and every other OEM variant of Android are forks of AOSP just like GrapheneOS. They're not the standard or stock state of Android but rather OEM forks of it.

2026-02-20 18:33:55 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8 Neither open source or distribution packaging inherently provide privacy or security. It's not the case that people only use software from official repositories regardless.
Contrary to the common misconception, only using software from distribution repositories doesn't avoid trusting the upstream developers and doesn't address supply chain attacks. As an example, Debian shipped a backdoor in sshd after it was included in the xz project as part of the published sources.

2026-02-20 18:30:16 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8
> This is exactly what people mean when they say that GrapheneOS people (and in particular this [official?] account in this case) are quite aggressive disparaging all the other ecosystems.
We posted a reply addressing misconceptions with accurate information. There was nothing in any way aggressive about what we posted. You're making dishonest claims about GrapheneOS and our team as you've done previously. It's you who being aggressive and causing us to defend ourselves.

2026-02-20 18:29:23 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8
> This is exactly what people mean when they say that GrapheneOS people (and in particular this [official?] account in this case) are quite aggressive disparaging all the other ecosystems.
We posted a reply addressing misconceptions with accurate information. There was nothing in any way aggressive about what we posted. It's you who is disparaging GrapheneOS and our team. Ytou're lying about the GrapheneOS project and our team. It's you being aggressive and dishonest.

2026-02-20 18:19:47 CET

- reply

@nprofile…4krt @nprofile…8vnj @nprofile…65q8
> a Linux distro has a different threat model than an Android "distro".
Android distributions are Linux distributions. Desktop Linux distributions don't truly have a different threat model but provide much weaker privacy and security than the Android Open Source Project. They lack modern exploit protections, broad use of memory safe languages and a mandatory app sandbox. They only have very incomplete app sandboxing without a modern permission model available for it.

2026-02-20 18:18:36 CET

- reply

@nprofile…zg6q Android follows upstream LTS releases far more closely than Ubuntu. In fact, the person leading the work on the upstream LTS kernels (Greg KH) works for Google and maintains the GKI LTS branch for Google too. The upstream LTS kernels have Android as their main target. Pixel 6 moving to 5 years of support is why the kernel.org LTS kernels had support extended to 5 years. Pixels began moving to new LTS branches and moved to 7 years so upstream LTS dropped to 2 years. Is Ubuntu not Linux?

2026-02-20 18:15:39 CET

- reply

@nprofile…zg6q The way the term mainline is used by the upstream Linux project is to refer to the tags made by Linus for the release candidate and point zero releases. The upstream stable and longterm branches are separate things. Most distributions use the upstream longterm branches as the basis for their own kernels with additional backports, etc. Upstream provides 2 years of support and many distributions maintain their own LTS branches much longer. Ubuntu often uses a non-upstream-LTS for theirs.

2026-02-20 18:10:49 CET

- reply

@nprofile…zg6q The way the term mainline is used by the upstream Linux project is to refer to the tags made by Linus for the release candidate and point zero releases. The stable and LTS branches are separate from mainline. Android works fine with the mainline, stable and LTS kernels.
Android uses the LTS

2026-02-20 18:08:51 CET

- reply

@nprofile…pljj People mainly use the term that way because they're misinformed about Android. Many people wrongly believe Android requires a special variant of the Linux kernel with downstream patches when that hasn't been the case for years. It works with the kernel.org mainline and LTS kernels. Most distributions maintain their own LTS branches as Android does with the GKI branches. Unlike certain distributions such as Ubuntu, Android always bases downstream LTS branch on upstream LTS branches.

2026-02-20 18:05:26 CET

- reply

@nprofile…zg6q The reason we replied is to avoid misconceptions. Your reply demonstrations you're misinformed about this yourself.
Android doesn't require any downstream kernel patches and works fine with mainline Linux kernels. All of the kernel drivers for Android are typically open source. The issue of SoC vendors and other hardware vendors providing software support in the form of proprietary libraries and services such as the ARM Mali GPU library isn't specific to Android or caused by Android.

2026-02-20 17:10:26 CET

- reply

@nprofile…pljj Android is mobile Linux. Linux doesn't mean glibc, systemd and GNOME. The desktop Linux software stack has atrocious privacy and security compared to the Android Open Source Project. There's a large and far better open source mobile app ecosystem for AOSP alongside the rest of the Android app ecosystem. Google's announced changes don't have any direct impact on an AOSP-based OS that's not licensing Google Mobile Services. The changes only amount to added UI friction for a GMS OS.

2026-02-20 16:48:17 CET

- reply

@nprofile…cfpe @nprofile…0vpy /e/ and iodéOS are LineageOS forks. All 3 of these reduce privacy and security compared to the Android Open Source Project but /e/ completely destroys it and is heavily misleading users about what's provided. People are far better off simply using LineageOS than /e/. LineageOS lags far less behind on updates than /e/ and doesn't reduce privacy and security nearly as much. It has fewer stability problems too. If people are going to use a variant of LineageOS just use LineageOS.

2026-02-20 16:47:23 CET

- reply

@nprofile…cfpe @nprofile…0vpy A lot of further information from Divested Computing and Mike Kuketz are included in the article posted above.
/e/ sending sensitive user data to OpenAI without user consent for a supposedly private service which should be locally implemented on the device is a representative example of their very negligent approach to privacy:
https://community.e.foundation/t/voice-to-text-feature-using-open-ai/70509
Devices being being marketed as private doesn't mean that's actually true. People are genuinely being scammed by Murena.

2026-02-20 16:47:08 CET

- reply

@nprofile…cfpe @nprofile…0vpy Murena devices and /e/ have poor privacy and atrocious security. They fail to keep up with OS updates and crucial privacy/security patches along with not providing standard privacy/security protections. Being weeks, months and even years behind on updates to the kernel, drivers, firmware, the rest of the OS and browser engine is a huge problem. Despite the marketing, /e/ has privacy invasive services and gives privileged access to Google apps/services.
https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

2026-02-20 16:46:06 CET

- reply

@nprofile…8vnj @nprofile…65q8 Android is mobile Linux. Linux doesn't mean glibc, systemd and GNOME. The desktop Linux software stack has atrocious privacy and security compared to the Android Open Source Project. There's a large and far better open source mobile app ecosystem for AOSP alongside the rest of the Android app ecosystem. Google's announced changes don't have any direct impact on an AOSP-based OS that's not licensing Google Mobile Services. The changes only amount to added UI friction for a GMS OS.

2026-02-20 16:35:24 CET

- reply

@nprofile…pljj Android is mobile Linux. Linux doesn't mean glibc, systemd and GNOME. The desktop Linux software stack has atrocious privacy and security compared to the Android Open Source Project. There's a large and far better open source mobile app ecosystem for AOSP than those alongside the rest of the app ecosystem. Neither of those are in any danger of going away. The information on the site linked above is inaccurate and spreading it around is not actually helping things at all.

2026-02-20 16:35:05 CET

- reply

@nprofile…8vnj @nprofile…65q8 Android is mobile Linux. Linux doesn't mean glibc, systemd and GNOME. The desktop Linux software stack has atrocious privacy and security compared to the Android Open Source Project. There's a large and far better open source mobile app ecosystem for AOSP than those alongside the rest of the app ecosystem. Neither of those are in any danger of going away. The information on the site linked above is inaccurate and spreading it around is not actually helping things at all.

2026-02-19 20:25:21 CET

- reply

@nprofile…0vpy We have a new sponsored server from Zare in London and 2 new sponsored servers from Cherry Servers in Amsterdam. The one in London along with one of the two in Amsterdam are used for updates and also our main website/network services. That means we have 2 update server locations in Europe and 3 website/network server locations since we still have the netcup VPS in Nuremberg. We're going to get more sponsored servers including one in Frankfurt with DTAG/vodafone ports available.

2026-02-05 20:54:03 CET

- reply

@nprofile…w7qn @nprofile…309j @nprofile…lqwx
> Support for talking to it has been implemented in FOSS projects like ModemManager.
That's not how it's implemented in the Android Open Source Project where GNSS has separate hardware abstraction layers and services.
Qualcomm choosing to implement GNSS and on non-low-end platforms also Wi-Fi and Bluetooth with the same baseband processor doesn't mean that's how it's done everywhere. There's no inherent reason it has to be done together and it's not on Pixels.

2026-02-05 20:50:15 CET

- reply

@nprofile…w7qn @nprofile…309j @nprofile…lqwx
> maybe how specifically responding to those requests works is not widely known
No, the information in the post is wrong.
> but at least it's very much known that GNSS is part of the modem
No, that's incorrect. Every Pixel model from 6th through 10th generation has a separate GNSS chip. Qualcomm includes GNSS with their cellular radios but that does not mean it does what the post claims. You're making an incorrect assumption without the full information.

2026-02-01 16:54:47 CET

- reply

@nprofile…0djn @nprofile…afew @nprofile…46hd @nprofile…4m5j Security keys can be used without sandboxed Google Play if you install a passkey provider with hardware security key support. See https://codeberg.org/s1m/hw-fido2-provider for one. It's no longer the case that apps only support Google Play for this.

2026-01-12 23:48:27 CET

- reply

@nprofile…g2g5 @nprofile…n8na @nprofile…ndew GrapheneOS does not receive any government funding and is not receiving funding from business partners. Our partnership with a major Android OEM does not involve them sending us money but rather having their engineering teams work on GrapheneOS support. They'll likely end up helping to improve GrapheneOS by publicly submitting improvements to it upstream.