GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

NIP-05 Address

[email protected]

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43q0uc5de

Publishing to

relay.ditto.pub

Author Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Show more details

Last Notes

2026-02-07 04:46:32 UTC

- reply

@nprofile…v7yd Many mail servers use blocklists based on IPv4 /24 and AS. Some blocklists support allowlisting a /32 within a /24 but not all. Some don't allow doing it if the /24 has a particularly bad reputation. In some cases a whole AS such as Vultr, OVH, etc. will be blocked. Xenyth doesn't allow sending mail from their IP space but rather you need to bring your own either via your AS or via BYOIP using one of theirs. We've hosted mail for years without an AS and IP space but it's not fun.

2026-02-07 01:43:07 UTC

GrapheneOS version 2026020600 released:
https://grapheneos.org/releases#2026020600
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/31639-grapheneos-version-2026020600-released
#GrapheneOS #privacy #security

2026-02-06 14:55:47 UTC

- reply

@nprofile…sym3 Pixels are still the only devices combining reasonable updates and hardware-based security with full support for using another OS.
https://grapheneos.org/faq#future-devices has a list of our requirements.
We're working with a major Android OEM since June 2025 and will have additional devices supporting GrapheneOS in 2027. It's taking time to meet all of the requirements and getting it done before the end of 2026 didn't end up being realistic due to an SoC limitation and other features.

2026-02-06 14:54:14 UTC

- reply

@nprofile…ep0j We already addressed the Play Integrity API checks. We haven't yet added an additional feature for bypassing checks done by apps themselves via verifying the Play Store source stamp and then pretending they were installed from the Play Store when other apps query the installer.
You can install apps via sandboxed Play Store for use with Android Auto for the time being. We plan to add the additional feature for expanding installer compatibility for that soon but it works already.

2026-02-06 00:35:48 UTC

- reply

@nprofile…w7qn @nprofile…309j @nprofile…lqwx The blog post was about iPhones and our response was primarily about Pixels. The post you replied to wasn't only about Snapdragon. The claims made in the blog post are very broad and unsubstantiated. We know those claims are inaccurate for Pixels where GNSS is implement as a separate chip and the OS handles features like SUPL. Snapdragon having cellular, Wi-Fi, Bluetooth and GNSS as isolated components with one baseband doesn't mean that the claims are true for it.

2026-02-05 19:55:45 UTC

- reply

@nprofile…w7qn @nprofile…309j @nprofile…lqwx
> Now the interesting question is whether the firmware would forcibly enable GNSS at the network's request for "emergency reasons"… We don't have proof, but it's definitely not impossible either.
It's not a black box but rather largely unobfuscated firmware which can be reviewed and understood. It's wrong to post speculation as fact and lead people to believe something is the case which isn't. It's also wrong to conflate every platform as working the same way.

2026-02-05 19:55:12 UTC

- reply

@nprofile…w7qn @nprofile…309j @nprofile…lqwx
> Now the interesting question is whether the firmware would forcibly enable GNSS at the network's request for "emergency reasons"… We don't have proof, but it's definitely not impossible either.
It's not a black box but rather largely unobfuscated firmware which can be reviewed and understood. It's wrong to post speculation as fact and lead people to believe something is the case which isn't. It's unsurprising coming from groups who mislead people all the time.

2026-02-05 19:54:03 UTC

- 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 19:52:33 UTC

- 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 as part of the cellular radio doesn't mean that the OS should be designed with those implemented by the same components.
> OS has to specifically enable GNSS on the modem
This is the same incorrect assumption.

2026-02-05 19:50:15 UTC

- 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-05 19:46:14 UTC

- reply

@nprofile…s26n GrapheneOS is entirely funded by donations. There's a mix of many small donations, a lot of medium sized ones and very large ones which go a long way themselves. We aren't receiving any grants or government funding. We don't want to have funding with strings attached but rather to continue getting funding from our users/supporters so we can don't have our hands tied and aren't dependent on reapplying for funding where not getting it would be a disaster.

2026-02-05 19:42:59 UTC

Vanadium version 145.0.7632.45.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/145.0.7632.45.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/31596-vanadium-version-14507632450-released
#GrapheneOS #privacy #security #browser

2026-02-05 09:23:59 UTC

GrapheneOS version 2026020400 released:
https://grapheneos.org/releases#2026020400
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/31576-grapheneos-version-2026020400-released
#GrapheneOS #privacy #security

2026-02-05 04:26:43 UTC

- reply

@nprofile…s26n We didn't previously have enough money to hire people in Canada, western Europe or especially the US. We no longer have those budget constraints and expect to hire a large portion of Americans going forward because a large portion of experienced Android OS, Chromium and Linux kernel developers are Americans. It's a fully remote team so it makes sense to hire people with similar experience in lower cost regions but it's not a constraint anymore and was heavily limiting previously.

2026-02-05 04:14:32 UTC

- reply

@nprofile…s26n
> I got a notification saying nearby devices needs to be allowed, even though it is…
Did you permit it for both Google Play services and the Pixel Watch app? It's likely needed for both, not only the Pixel Watch app.

2026-02-05 04:11:57 UTC

- reply

@nprofile…s26n
> I should have double-check but I was positive Graphene lead dev was from the states, sorry for that, I’ll update my post to correct it.
The founder and original lead developer of GrapheneOS is Canadian. They're one of the 3 directors of the non-profit. The current lead developer is Ukrainian and is also one of the directors. The remaining director is Kazakhstani. We have one American developer who we hired last year. They're the first American we've hired but we'll be hiring more.

2026-02-04 22:25:57 UTC

- reply

@nprofile…s26n France previously went after multiple companies selling supposedly private/secure phones in Europe. That included taking control of server infrastructure on OVH and arresting people involved with the companies. They're going after private messaging apps too.
France's national law enforcement is inaccurately conflating GrapheneOS with sketchy products based on portions of our open source code. Many inaccurate claims were widely propagated by French corporate and state media based on this.

2026-02-04 22:25:52 UTC

- reply

@nprofile…s26n GrapheneOS was initially created in Toronto and it's where we have our infrastructure for builds and signing. GrapheneOS Foundation is incorporated as a federal non-profit in Canada and is officially based in Toronto.
It's Europe passing laws clamping down on end-to-end encryption and secure devices including Chat Control rather than the US or Canada. We recently moved servers out of France and off OVH after law enforcement and state/corporate media began a public campaign against us.

2026-02-04 22:24:34 UTC

- reply

2026-02-04 22:21:09 UTC

- reply

@nprofile…s26n GrapheneOS was initially created in Toronto and it's where we have our infrastructure for builds and signing. GrapheneOS Foundation is incorporated as a federal non-profit in Canada and is officially based in Toronto.
It's Europe passing laws clamping down on end-to-end encryption and secure devices including Chat Control rather than the US or Canada. We recently moved servers out of France and off OVH national law enforcement and state/corporate media began a public campaign against us.

2026-02-04 22:14:17 UTC

- reply

@nprofile…s26n French national law enforcement is conflating sketchy companies and individuals in Europe making products based on portions of our open source code with the GrapheneOS project. They've threatened to go after us in a similar way they did multiple companies selling supposedly secure phones in Europe, mainly Encrochat and SkyECC. Those products didn't actually provide the claimed privacy and security. French corporate and state media widely repeated inaccurate claims about us as facts.

2026-02-04 22:09:44 UTC

- reply

@nprofile…s26n GrapheneOS was initially created in Toronto and it's where we have our infrastructure for builds and signing. GrapheneOS Foundation is incorporated as a federal non-profit in Canada and is officially based in Toronto.
It's Europe which is passing laws clamping down on end-to-end encryption and secure devices including Chat Control rather than the US or Canada. We recently moved our servers out of France after national law enforcement and state/corporate media began a campaign against us.

2026-02-04 22:02:06 UTC

- reply

@nprofile…s26n There are multiple working tap-to-pay options for Europe including Curve Pay, PayPal and many banking apps. Only the subset of banking apps which moved to Google Pay won't allow using it. Google Pay works on a technical level but disallows a non-stock OS.
WearOS devices including Pixel Watches work well with GrapheneOS. If you want to use a Pixel Watch with full functionality then you need the Pixel Watch app which is fully compatible.
GrapheneOS isn't based in the US and never has been.

2026-02-04 21:47:15 UTC

- reply

@nprofile…309j @nprofile…lqwx We don't yet have an answer to how it works on Snapdragon where GNSS and cellular are both implemented by the SoC but we'll get that information as part of our OEM partnership and can set things up differently if there's any reason to do that. SUPL and other integration between GNSS and cellular is performed by the OS on Pixels. Apple decides how this works for iPhones as shown by these recent changes. We don't think assuming Apple doesn't know what they're doing makes sense...

2026-02-04 21:45:20 UTC

- reply

@nprofile…309j @nprofile…lqwx We don't yet have an answer to how it works on Snapdragon where GNSS and cellular are both implemented by the SoC but we'll get that information as part of our OEM partnership and can set things up differently if there's any reason to do that. SUPL and other integration between GNSS and cellular is performed by the OS on Pixels and iPhones almost certainly work the same way since they also have a cellular radio that's not vertically integrated. Either way, Apple controls that.

2026-02-04 21:43:43 UTC

- reply

@nprofile…309j @nprofile…lqwx
> I'm fine with the article cited being inaccurate, but it's unclear on what you're basing your answer that GOS Pixels "are not vulnerable".
The cellular radio has no direct connection to GNSS on Pixels and doesn't control it. It's the operating system implementing support for providing supplementary location data to the cellular radio for E911 support. Many regions including Europe don't use E911 in the first place but rather a different standard not implemented by AOSP.

2026-02-04 21:42:12 UTC

- reply

@nprofile…309j @nprofile…lqwx
> To be clear, you have answered "No" to the question "Are Pixel devices running GOS vulnerable to this GNSS baseband processor tracking?"
Correct.
> How does the operating system mitigate Control Plane LCS for all modems running on Pixel devices? Is this even publicly documented anywhere?
Location detection based on the cellular connection itself can only be avoided with airplane mode. Apple hasn't changed that for iPhones, they're only trying to reduce the precision.

2026-02-04 19:31:49 UTC

- reply

@nprofile…309j @nprofile…lqwx It's not worth investing significant effort debunking something not particularly relevant in the first place. Devices connected to cellular have their location known to it through the fact that they're connected to multiple cell towers and can have the position estimated decently well based on that alone. This is a technique used to perform position estimation themselves based on Wi-Fi and cell towers by mobile devices but can also be done by the network and is done in practice.

2026-02-04 19:29:31 UTC

- reply

@nprofile…309j @nprofile…lqwx
> A major caveat is that I don’t know if RRLP and LPP are the exact techniques, and the only techniques, used by DEA, Shin Bet, and possibly others to collect GNSS data; there could be other protocols or backdoors we’re not privy to.
You should not be basing your understanding on an article written by someone making assumptions about how things work without knowing how things are actually implemented. They're claiming the changes made by Apple aren't useful without evidence.

2026-02-04 19:28:37 UTC

- reply

@nprofile…309j @nprofile…lqwx We're not talking about GrapheneOS specifically. The article is inaccurate about how this works in general including for iOS. This is an example of someone being aware of certain things existing and then making a whole bunch of assumptions about it which they're communicating as fact. It's the responsibility of the person making these claims to provide evidence. The article is open about the fact that they're not familiar with how it actually works in practice and are assuming.

2026-02-04 16:37:39 UTC

- reply

@nprofile…68ls No, that's not how the release channels work. Every app and OS release is pushed out via Alpha prior to Beta and Beta prior to Stable. If a major issues are found during testing then it doesn't proceed to the next channel. Any release that's just announced is either already in Alpha or about to be pushed into Alpha. It's never the case that it would already be in Beta and we never skip over the Beta channel. It's always the same system and there aren't exceptions to it.

2026-02-04 16:30:12 UTC

GrapheneOS App Store version 35 released:
https://github.com/GrapheneOS/AppStore/releases/tag/35
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/31550-grapheneos-app-store-version-35-released
#GrapheneOS #privacy #security #android

2026-02-03 17:30:20 UTC

GrapheneOS App Store version 34 released:
https://github.com/GrapheneOS/AppStore/releases/tag/34
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/31526-grapheneos-app-store-version-34-released
#GrapheneOS #privacy #security #android

2026-02-03 16:16:58 UTC

- reply

@nprofile…0vpy It's eSIM management support rather than simply eSIM support. We plan to rename the toggle for clarity. eSIMs will work with it disabled but you won't be able to manage them for the most part. We recommend leaving it enabled if you use eSIMs although you can disable it and continue using them.

2026-02-03 16:14:37 UTC

- reply

@nprofile…ul6n There's already a toggle for opening external links in Incognito and you can make a shortcut opening an Incognito tab on your home screen. We don't plan to add a way to disable the regular mode.

2026-02-02 16:47:58 UTC

- reply

@nprofile…d7cc It's not experimental anymore since 2026011000. We added it to the top of the release notes afterwards to clarify it:
https://grapheneos.org/releases#2026011000

2026-02-02 16:06:30 UTC

- reply

@nprofile…36mx @nprofile…8z29 @nprofile…fpac They sell official kits for replacing parts which are expensive and to an extent they prevent using unauthorized parts.

2026-02-02 09:47:11 UTC

- reply

@nprofile…fpac @nprofile…8z29 What do you mean by modular? Having official replacement parts available for many years? iPhones and Pixels provide those. That's not really a modular device. It's not as if you can replace the SoC or other components to upgrade it over time and avoid end-of-life. An iPhone or Pixel gets proper update support over the long term while Fairphone fails to provide that even for the first year after launch and it's downhill from there. Samsung flagships get better updates.

2026-02-02 09:36:44 UTC

- reply

@nprofile…f8s3 No, we aren't going to attend a conference where a bunch of people involved in extreme harassment towards our team give talks.

2026-02-02 09:34:06 UTC

- reply

@nprofile…fpac @nprofile…8z29 Fairphone 4 and Fairphone 5 already have an end-of-life kernel branch. Even the Fairphone 6 is not receiving proper updates. It's still on the initial yearly release of Android 15 rather than Android 16 QPR2 and still has the November 2025 patch level. Meanwhile, the patches for February 2026 through May 2026 are already nearly fully available for OEMs to ship early and June 2026 is beginning to get filled out now that the March 2026 patches are finalized.

2026-02-01 23:30:04 UTC

- reply

@nprofile…8z29 Strong recommend reading https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private and the third party sources linked in there including the posts from Divested Computing, Mike Kuketz and the comparison from Eylenburg.
If you care at all about privacy and security, avoid /e/ and avoid Fairphones. Use an iPhone if you want a device with solid privacy and security without thinking about it. Don't fall for the false marketing of these phony privacy and security products. No device Murena sells is at all safe to use.

2026-02-01 23:27:42 UTC

- reply

@nprofile…8z29 GrapheneOS is a privacy and security hardened OS greatly improving those compared to the Android Open Source Project. /e/ is the opposite of that and is a far worse option than an iPhone for privacy and security. /e/ is not at all a safe option and it's not a legitimate a privacy project despite being marketed as one. No privacy project it telling users to use their supposedly private speech-to-text service which actually sends their sensitive speech data to OpenAI and much more.

2026-02-01 23:25:16 UTC

- reply

@nprofile…8z29 /e/ lags far further behind LineageOS on providing major OS updates and partial backports of patches to older releases. Those are far behind the standard pace which is itself far behind GrapheneOS.
LineageOS rolls back privacy and security a fair bit compared to the standard Android Open Source Projects, especially on most devices where many patches are missing. /e/ drastically reduces privacy and security compared to that. /e/ is not simply LineageOS with bundled apps/services.

2026-02-01 23:23:53 UTC

- reply

@nprofile…8z29 A Fairphone 4 with /e/ has very poor privacy and absolutely atrocious security. It's years behind on a bunch of important privacy and security patches including having an end-of-life 4.19 kernel without updates available. They lag months behind on partial backports of patches.
/e/ has invasive services of their own including sending user data to OpenAI without consent. Despite their marketing, It always uses Google services and gives Google apps/services privileged access.

2026-02-01 23:07:50 UTC

- reply

@nprofile…7p0z @nprofile…gxvp @nprofile…qtun It's an example of a service we could provide in the future where we would be acting as a LIR rather than something we have any concrete plans to do in the next couple years. Neither a data eSIM or a VPN service was part of the 2 year plan proposal we gave to ARIN for our /22 application. They're things we see ourselves doing further out as a bigger org.

2026-02-01 23:02:15 UTC

- reply

@nprofile…gxvp If we started hosted a VPN service using a portion of our own IP space then we would clearly be a LIR ourselves. We already host a bunch of connectivity-related services and are headed more in that direction. We plan to offer recursive DNS ourselves in the near future. In the long term we could provide services like a VPN or a roaming data eSIM service. We'd keep services where user connections go through those IPs in separate blocks and a separate ASN from everything else though.

2026-02-01 22:56:26 UTC

- reply

@nprofile…gxvp ARIN, RIPE, etc. are Regional Internet Registries (RIRs) and then there are many organizations holding IP space with those which assign that space either directly to customers or to provide services to those customers.
> A Local Internet Registry (LIR) is an IR that primarily assigns IP addresses to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs) whose customers are primarily end users and possibly other ISPs.

2026-02-01 22:50:02 UTC

- reply

@nprofile…gxvp ARIN, RIPE, etc. are Regional Internet Registries (RIRs) and then there are many organizations holding IP space with those which assign that space to customers and are known as Local Internet Registries (LIRs).
GrapheneOS can be considered to be a form of internet service provider due to the large assortment of connectivity services we provide to end users with plans for a lot more including recursive DNS but we're going to be hosting services for GrapheneOS, not for other projects.

2026-02-01 15:54:47 UTC

- 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-31 21:38:31 UTC

- reply

@nprofile…5caf Our community needs to be far more active engaging with people about GrapheneOS across platforms. Provide factual information and counter inaccurate attacks on the project and team while remaining calm and polite even in the fact of people engaging in personal insults and linking harassment content. We have a lot of users and a large community but aren't receiving enough help from them with this. We cannot be everywhere and cannot spend more time countering misinformation.

2026-01-31 21:12:21 UTC

- reply

@nprofile…lqwx No, but this article isn't accurate in general.

2026-01-31 10:12:29 UTC

- reply

@nprofile…mug9 It's too slow which results in poor usability especially for blind users depending on TalkBack where it adds a lot of latency to every request. We already have an all around better implementation.

2026-01-31 01:01:07 UTC

- reply

@nprofile…2c6z There will likely be an announcement from the OEM within the next couple months. The devices themselves are planned for 2027.

2026-01-31 00:26:04 UTC

Vanadium version 145.0.7632.26.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/145.0.7632.26.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/31313-vanadium-version-14507632260-released
#GrapheneOS #privacy #security #browser

2026-01-31 00:19:49 UTC

- reply

@nprofile…vuk6 It implements the Android text-to-speech API for use as an Android text-to-speech backend.

2026-01-30 22:20:40 UTC

- reply

@nprofile…y6su Is GrapheneOS showing a Play Integrity API notice when trying to use it?

2026-01-30 20:14:59 UTC

- reply

@nprofile…v7yd It's an extremely bad time to build new workstations or servers due to the extreme RAM prices which are 500% what they were in mid-2025 which is an actual value and not an exaggeration.

2026-01-30 20:14:36 UTC

- reply

@nprofile…v7yd It's an extremely bad time to build new workstations or servers due to the extreme RAM prices which are 5x what they were in mid-2025.

2026-01-30 19:57:16 UTC

- reply

@nprofile…v7yd It's theoretically an issue but not one we expect to be a problem for us in practice especially on a provider like Xenyth. The same theoretical issue would exist buying used server hardware too. None of that hardware has good security in practice even if it's brand new. The CPUs might have reasonable security but the motherboards from ASRock, Supermicro, etc. definitely lack it. We plan to do colocation in the future but we're not ready to deal with that yet.

2026-01-30 19:54:39 UTC

- reply

@nprofile…cr4h LiberaPay isn't used much based on https://en.liberapay.com/explore/recipients. GrapheneOS likely receives more monthly donations than the total amount going through LiberaPay based on past numbers they've given on the total going through it. We were setting up Open Collective at one point prior to having our non-profit but ended up just using our own non-profit instead of needing a fiscal host to handle it. We're on Benevity already because some people can only donate through that but we prefer Wise.

2026-01-30 19:48:34 UTC

- reply

@nprofile…v7yd ARIN has an IPv4 /10 dedicated to IPv6 enablement with NRPM 4.10 being the policy for how that works. Both of our IPv4 /24 blocks are from NRPM 4.10. None of the other RIRs have a similar program. RIPE still theoretically gives a /24 to new organizations but it's only a single /24 compared to ARIN where you can get a /22 and then apply for more. ARIN's waitlist also moves faster since most of the legacy IP space which can be reclaimed was given t o North American organizations.

2026-01-30 19:46:47 UTC

- reply

@nprofile…v7yd We only own 2x IPv4 /24 right now which are both for anycast DNS so we have an IPv4 /24 that's loaned to us by a Romanian LIR until we get more space from ARIN which has been approved but takes a long time due to IPv4 exhaustion. ARIN gradually reclaims space from organjizations not paying their fees or not using the space where leasing it out to others would count as using it. The 2x IPv4 /24 they gave us are pristine space never used before from ARIN's final /8 from IANA.

2026-01-30 19:42:31 UTC

- reply

@nprofile…v7yd We're going to be using the IP space we're announcing from Xenyth for multiple purposes including email. Our current plan for email is moving to an on-premises server connected to a Xenyth server via something like WireGuard to use our own IP space and AS for it. This will allow us to use our own clean IP space and clean ASN which aren't sending any spam to have very good IP reputation for email where we can avoid the issues we've had with service provider IP space / ASNs.

2026-01-30 19:40:47 UTC

- reply

@nprofile…v7yd We also host our own email and need to move to using our own AS and IP space to avoid being negatively impacted by spam sent by other customers in the same IPv4 /24 or even the same AS. Providers offering VPS instances generally have terrible IP reputation especially for IP space they use for floating IPs but the instance IPs have bad reputation too. A floating IP is needed to avoid losing positive IP reputation and work done to undo inclusion in blocklists for an email IP though.

2026-01-30 19:38:43 UTC

- reply

@nprofile…v7yd Using our own AS and IP space is what enables us to have own anycast networks for DNS instead paying for a managed anycast DNS service. We were previously using the extremely limited BuyVM managed anycast feature for ns2 and then more recently moved to Rage4 managed anycast for ns1 which uses zerotier + BGP to provide anycast routing via their own 21 locations without being able to directly control the routing. Hosting our own authoritative DNS is the main reason we got IP space.

2026-01-30 19:14:32 UTC

- reply

@nprofile…v7yd BGP is how internet routing works. It's the only way for us to announce our own IP space with our own Autonomous System (AS). In order to do it, we need providers with BGP support by paying for transit directly for colocated servers in a DC or using providers supporting it for customers on their servers which is the case with Xenyth, Misaka.io and Vultr. BuyVM also supports it but we moved ns2 from BuyVM to Misaka.io for better reliability, better transit and more locations.

2026-01-30 19:08:14 UTC

- reply

@nprofile…cr4h GitHub Sponsors provides credit card donations with 0% fees for donations from individuals which isn't something we can get elsewhere. The fees elsewhere are often over 5% when currency conversion is taken into account. We don't want to move more of the donations to high fee platforms. We have PayPal as a donation method but our donate page tries to make sure people understand the high fees and that it's better to donate another way such as GitHub Sponsors, Wise or bank transfers.

2026-01-30 19:05:55 UTC

- reply

@nprofile…cr4h We have a bunch of donations options including local bank transfers with very low fees via Wise or sending money via Wise itself which has no fee if it's a matching currency. We already have a lot of options and adding more results in higher costs for managing it and handling accounting. We have to spend a huge amount of money on accounting and also auditing. The more complex the finances, the more money we'll need to spend on that. Why not use bank transfers or Wise?

2026-01-30 00:27:52 UTC

- reply

@nprofile…cvp3 @nprofile…jlxe ARIN launched ASPA support on January 20th which is what we're using now:
https://www.arin.net/announcements/20260120/
It was previously possible to deploy it when using delegated RPKI rather than hosted RPKI but the tooling for this isn't very good yet and we care a lot about availability so we didn't want to deploy something without good high availability support yet. There are also no security advantages to using delegated RPKI rather than hosted RPKI since ARIN is trusted either way.

2026-01-30 00:21:10 UTC

- reply

@nprofile…cvp3 @nprofile…jlxe Open up https://bgp.tools/as/40806 and look at the tabs for Prefixes and Connectivity.
In Prefixes, you can see green locks representing RPKI signing authorizing our AS to announce the prefixes. It would be missing if they weren't RPKI signed or would show a red error icon if the network (AS) wasn't authorized to announce them.
In Connectivity, you can see green locks representing ASPA authorizing each upstream. It would show a red error icon if one wasn't authorized.

2026-01-30 00:18:28 UTC

- reply

@nprofile…cvp3 @nprofile…jlxe GrapheneOS deploys RPKI to cryptographically sign which networks are allowed to announce our IP space (only our own) and ASPA to sign which networks are valid upstreams from us. We currently permit Vultr (our ns1 network), Misaka.io (our ns2 network), BuyVM (staging servers for testing only) and Xenyth to act as our upstreams. We're going to move our staging servers from BuyVM to Xenyth though.
Our upstreams need to deploy ASPA themselves to sign their upstreams.

2026-01-30 00:10:28 UTC

- reply

@nprofile…kswc Pixel Camera supports using the rear cameras on the folding Pixels as front cameras which turns the weakness of the weaker front cameras into a major strength. That feature isn't supported by our own Camera app yet but we plan to support it in the future. You can use the full standard camera functionality via Pixel Camera though. Our Camera app will keep getting better but we've been focused on other things recently.

2026-01-30 00:09:17 UTC

- reply

@nprofile…kswc Yes, it's fully functional on the Pixel 10 Pro Fold and it's one of the recommended devices. It supports all of the folding features and you can use apps such as Pixel Camera with special support for it which will work fine on GrapheneOS.
https://grapheneos.org/faq#recommended-devices
The other Pixel 10 Pro models have larger image sensors so the only downside aside from cost is not somewhat weaker cameras, but it still has very good cameras anyway.

2026-01-30 00:06:40 UTC

- reply

@nprofile…0vpy For HTTPS network time, we make the certificate validation ignore notBefore (accepting certificates which appear to be issued in the future) and we only compare notAfter against the OS build date rather than the current time. Since we have frequent OS updates, that's quite fine grained certificate expiry anyway. We use 6 day expiry Let's Encrypt certificates now and our OS updates tend to be at least every 2 weeks. Nearly everyone still uses 90 day or 1 year expiry certificates anyway.

2026-01-30 00:04:13 UTC

- reply

@nprofile…0vpy Android's standard NTP implementation has a special exception in the base OS to bypass the Owner user VPN to work around UDP often not being supported along with the potential for time-based certificate errors blocking connecting to a VPN. We just accept the usability tradeoff of having the clock being set very wrong often breaking connecting to a VPN until the user fixes it. We avoid the clock being set incorrectly breaking HTTPS network time via custom certificate time validation.

2026-01-30 00:00:09 UTC

- reply

@nprofile…0vpy Using HTTPS is much simpler and essentially doesn't add any attack surface since it's already being used for so much other functionality. HTTPS also nearly always works while NTP does not including via Tor which doesn't have UDP.
Bear in mind non-military GPS isn't authenticated and GPS is being widely spoofed especially in warzones. We use 6 different upstream sources with NTS for our servers where a minimum of 3 sources need to agree on the time in order for it to update the clock.

2026-01-29 23:57:44 UTC

- reply

@nprofile…0vpy We plan to eventually make it more configurable. Setting it up on the server side is quite simple since it simply involves setting the time in milliseconds in a header. It falls back the second precision standard date header if that's unavailable but it should be provided.
We use HTTPS rather than NTP with NTS because HTTPS is precise enough for end user devices. In fact, we made network time much more precise by lowering the permitted clock drift from 2 seconds to 50 milliseconds.

2026-01-29 23:57:22 UTC

- reply

@nprofile…0vpy We plan to eventually make it more configurable. Setting it up on the server side is quite simple since it simply involves setting the time in milliseconds in a header. It falls back the second precision standard date header if that's unavailable but it should be provided.
We use HTTPS rather than NTP with NTS because HTTPS is precise enough for end user devices. In fact, we made network time much more precise than standard Android which permits up to 2 second drift before fixing it.

2026-01-29 23:41:27 UTC

- reply

The interesting parts of our BGP setup can be seen in https://github.com/GrapheneOS/ns1.grapheneos.org where we have our BGP community configuration for each ns1/ns2 location along with our setup for region steering via GeoDNS + anycast server location and failover via health checks from our DNS servers.

2026-01-29 23:36:19 UTC

- reply

Our plan for our IPv4 /22 from the ARIN waitlist is deploying a single /24 in each of Toronto, Miami, Los Angeles and Seattle. Once we have a /22 deployed for North America, we'll qualify for getting out-of-region space on ARIN via the waitlist or transfers for Europe, Asia, etc.

2026-01-29 23:34:18 UTC

- reply

Xenyth has support for routing to multiple servers announcing the same publicly routable IP space by announcing smaller blocks from specific servers so we can also pay for additional Xenyth bare metal servers or VPS instances. We'll likely be using it a fair bit in the future.

2026-01-29 23:32:56 UTC

- reply

Our current bare metal server at Xenyth is sponsored by them and used as an update mirror which is using our IP space. However, our main use case for the IP space in Toronto is for our mail server which we're planning to host on-premises and tunnel the traffic through Xenyth.

2026-01-29 23:29:34 UTC

- reply

ARIN has approved our request for an IPv4 /22 via their waitlist but it will take around 18 to 36 months for the waitlist to progress to our request. For now, we're using an IPv4 /24 loaned to us for free by a Romanian LIR supporting GrapheneOS for our unicast Toronto IP space.

2026-01-29 23:23:40 UTC

- reply

Our anycast networks are deployed with 2x IPv4 /24 obtained we quickly obtained for free from ARIN via NRPM 4.10 + NRPM 4.5.
We could use our own IPv6 space everywhere we have BGP if we wanted to do that since we have a /36 which can be expanded into more space reserved for us.

2026-01-29 23:13:41 UTC

- reply

Vultr and Misaka.io both have very good transit and peering for anycast due to having matching transit providers within regions and globally.
Both anycast networks needed a lot of configuration with BGP communities for traffic engineering and are working very well.

2026-01-29 23:01:38 UTC

- reply

Our ns1 network has 11 locations on Vultr (Piscataway, Miami, Los Angeles, Seattle, São Paulo, London, Frankfurt, Singapore, Mumbai and Tokyo).
Our ns2 network has 8 locations on Misaka.io (Ashburn, Miami, San Jose, Seattle, London, Berlin, Singapore and Tokyo).

2026-01-29 22:59:19 UTC

We're now using our own autonomous system and IP space for 3 of our networks. We run 2 entirely separate anycast DNS networks for our authoritative DNS and have a simpler unicast setup on a bare metal server at Xenyth which we'll be using for more soon.
https://bgp.tools/as/40806

2026-01-29 22:37:39 UTC

- reply

@nprofile…dysu It's not really platform specific. It currently runs on the CPU but we plan to add TPU support for Tensor and NPU support for Snapdragon in the future. It's made for GrapheneOS and we're not interested in doing any significant work on use outside of GrapheneOS. It will be possible to install it from our App Store on other Android 16+ operating systems but it's not our focus. We're focused on making GrapheneOS better and haven't gotten much out of making stuff available elsewhere.

2026-01-29 22:28:44 UTC

- reply

@nprofile…xxzl It wasn't quite good enough and has very high latency which makes it unsuitable for use with TalkBack. We're making this because existing options including Sherpa don't meet our requirements. Otherwise, we could have forked those. It made more sense to make our own instead which we'll be able to continue improving long term. It's similar to our network location and geocoding implementations where we want things done a particular way focused on high quality in all areas we care about.

2026-01-29 22:28:24 UTC

- reply

2026-01-29 22:22:14 UTC

- reply

@nprofile…rkpm We started working on this because Sherpa didn't meet our requirements including overly high latency making it unsuitable for blind users to use with TalkBack.

2026-01-29 22:18:39 UTC

- reply

Whisper is closed source software. Open weights is another way of saying permissively licensed closed source. Our implementation of both text-to-speech and speech-to-text will be actual open source which means people can actually fork it and add/change/remove training data, etc.

2026-01-29 22:11:00 UTC

- reply

Our full time developer working on already built their own Transcribro app for on-device speech-to-text available in the Accrescent app store called Transcribro. For GrapheneOS itself, we want actual open source implementations of these features unlike OpenAI's phony open source.

2026-01-29 22:06:37 UTC

- reply

Existing implementations of text-to-speech and speech-to-text didn't meet our functionality or usability requirements. We want at least very high quality, low latency and robust implementations of both for English included in the OS. It will help make GrapheneOS more accessible.

2026-01-29 22:04:57 UTC

- reply

We're going to build our own speech-to-text implementation to go along with this too. We're starting with an English model for both but we can add other languages which have high quality training data available. English and Mandarin have by far the most training data available.

2026-01-29 21:54:34 UTC

We've built our own text-to-speech system with an initial English language model we trained ourselves with fully open source data. It will be added to our App Store soon and then included in GrapheneOS as a default enabled TTS backend once some more improvements are made to it.

2026-01-29 21:47:19 UTC

- reply

@nprofile…nanz It's currently only in the Alpha channel but will reach Beta very soon, see here:
https://grapheneos.org/releases#devices

2026-01-29 20:16:44 UTC

GrapheneOS version 2026012800 released:
https://grapheneos.org/releases#2026012800
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/31269-grapheneos-version-2026012800-released
#GrapheneOS #privacy #security

2026-01-28 02:31:57 UTC

Vanadium version 144.0.7559.109.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/144.0.7559.109.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/31220-vanadium-version-144075591090-released
#GrapheneOS #privacy #security #browser

2026-01-27 18:11:26 UTC

- reply

@nprofile…wh88 SailfishOS is a largely closed source OS with poor privacy and atrocious security compared to the Android Open Source Project. They already have their approach to compatibility with a subset of Android apps which reduces privacy and security for those apps along with having poor compatibility. Organizations banning devices/OSes not certified by Google aren't going to permit genuinely insecure devices when they ban more secure devices with that reasoning...