GrapheneOS

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

Website: https://grapheneos.org/
Forum: https://discuss.grapheneos.org/
X: https://x.com/GrapheneOS
GitHub: https://github.com/GrapheneOS

Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

NIP-05 Address

[email protected]

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntl6az7v

Publishing to

relay.momostr.pink

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2026-02-09 20:21:00 UTC

- reply

Can you return it and buy a used unlocked Pixel instead? Pixel 8a still has over 5 out of 7 years of support remaining.

2026-02-08 16:55:36 UTC

- reply

A lot of mail servers don't support IPv6. For those that do, blocking tends to be done based on /64 but could be done based on a larger block. IPv6 space is abundant so assigning a whole /48 or an even shorter prefix to a mail server isn't an issue at all when using your own IP space.

2026-02-07 04:46:32 UTC

- reply

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-07 01:42:56 UTC

- reply

That's normal since you have it in the Private Space. We need to add that to the documentation. You could make a PR to the grapheneos.org repository if you want to help with that.

2026-02-06 14:55:47 UTC

- reply

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

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 14:51:39 UTC

- reply

That's unusual and doesn't normally happen with PayPal on GrapheneOS. You should try clearing the app data.

2026-02-05 19:48:27 UTC

- reply

eSpeak-NG uses a restrictive GPLv3 license which is incompatible for inclusion in GrapheneOS. We'll only include GPLv2 (with the necessary exceptions) and permissively licensed code in GrapheneOS to avoid having much stricter licensing than the Android Open Source Project (AOSP) and therefore having GrapheneOS not be a drop-in replacement for it usable by everyone using AOSP. GPLv3 is a choice to have software not be included in BSD OSes, AOSP, GrapheneOS, etc.

2026-02-05 19:46:14 UTC

- reply

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:44:00 UTC

- reply

No, that's not the right place. It's Settings > Apps > Sandboxed Google Play (not the Play services app) > Android Auto. Also, you don't need to grant Call logs, Camera, Contacts, Location, etc. to Play services in general.

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

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

> 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:13:55 UTC

- reply

Android Auto requires sandboxed Google Play to be installed in the same profile. Both Android Auto and Sandboxed Google Play should be installed from our App Store. Play Store and Play services should have the Network permission granted so the services function properly. In order for Android Auto to work, special access needs to be granted via Settings > apps > Sandboxed Google Play which has multiple toggles including the most minimal one needed for wired Android Auto.

2026-02-05 04:11:57 UTC

- reply

> 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:47:55 UTC

- reply

Apps enforcing the Play Integrity API device or strong integrity levels for their services is what actually matters. That prevents using anything other than the stock OS on a device licensing Google Mobile Services unless sketchy approaches are used to trick the checks with spoofing. Strong integrity level can only be tricked with leaked keys. Both those tiers of checks are improving and they detect / block spoofing happening at scale in multiple ways.

2026-02-04 22:46:31 UTC

- reply

Similarly, app developers can explicitly choose to set their Play Store apps as requiring the Play Integrity API basic, device or strong integrity level for installation. GrapheneOS passes basic integrity and the rest can be worked around by using another Play Store frontend. It's quite pointless for apps to do this unless they actually enforce the Play Integrity API for their services which most using it don't do. Neither of these things is a big deal.

2026-02-04 22:45:00 UTC

- reply

App developers can explicitly enable a Play Store feature for adding checks to their app to enforce installing it from the Play Store. It's not opt-out but rather opt-in. GrapheneOS removes these checks for apps with a valid Play Store source stamp so it's not an issue on GrapheneOS. We also plan to add a similar feature to work around apps checking if they're installed from the Play Store themselves with a Play Store source stamp check for security.

2026-02-04 22:25:57 UTC

- reply

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

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:02:06 UTC

- reply

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

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:43:43 UTC

- reply

> 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

> 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:29:31 UTC

- reply

> 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

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 19:25:36 UTC

- reply

We intend to make minor improvements to the Messaging app but will eventually replace it with a newly developed app.

2026-02-04 19:24:49 UTC

- reply

> your communication is a bit problematic
No, it's not problematic. We announce production releases when they're available.
We aren't going to make 3 announcements for each release based on it reaching each channel which is not a reasonable expectation. It's important for it to be announced when it becomes available, which is what we do.
Staged rollouts are standard for Android, Chrome and Play Store apps. The way we're doing it is the norm. Your expectation and reasoning is wrong.

2026-02-04 16:37:39 UTC

- reply

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 19:29:58 UTC

- reply

We've built our own text-to-speech implementation since none of the existing options met our requirements. It's not quite ready to be bundled into the OS but we're planning on publishing it in our App Store soon. We trained our own model with fully open source training data to provide the high quality people expect from text-to-speech today while also performing well enough to be very usable with TalkBack. We plan on having that bundled in the OS and enabled by default very soon.

2026-02-03 18:02:10 UTC

- reply

You can confirm for yourself downloading an APK via Vanadium is very straightforward. It opens a prompt for confirming the download since we change confirmation to be enabled by default in Vanadium. Only the Downloads directory can be used by default which is completely normal and is perfectly usable for installing an APK. The confusion seems to be the fact that it's not possible to select another directory there by default which is the same as Chrome. It's a standard Chromium UI.

2026-02-03 17:50:16 UTC

- reply

You can confirm yourself that downloading an APK will just go to the Download directory. We don't recommend F-Droid as a source of apps in general though.

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

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

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 23:41:19 UTC

- reply

Having English text-to-speech is the main thing we need for accessibility since that's enough for blind people with even only a basic understanding of English to install another text-to-speech app. Currently, that's likely nearly anyone using GrapheneOS. In the future we do want to have various other languages but it's something which can be handled via installing another app for TTS, STT, keyboard, etc. already and our focus is improving out-of-the-box accessibility.

2026-02-02 23:39:37 UTC

- reply

We're also going to make our own speech-to-text implementation too. The priority is finishing polishing up text-to-speech so we can ship it in GrapheneOS as a default enabled implementation. Once that's finished, we can start work on other things including speech-to-text. We're going to make a high quality implementation for English text-to-speech and speech-to-text before getting to other languages. For other languages, we'll do it based on estimated GrapheneOS usage.

2026-02-02 23:37:23 UTC

- reply

That's the main reason why we built it. The purpose of it is providing a high quality modern implementation of text-to-speech using a model trained with entirely open source data while providing much better performance than existing options. The poor performance of the existing options results in very poor usability with TalkBack due to high latency. It also means they're wasting a lot of power. We're working on a final round of improvements prior to bundling it.

2026-02-02 21:19:55 UTC

- reply

Android 16 QPR2 was released to the Android Open Source Project on launch date. That's not why /e/ lags far behind on updates to AOSP. They lag even further behind on updates to the Linux kernel and other components including drivers and firmware. It's just not properly maintained and privacy/security are not prioritized despite the marketing. /e/ is a fork of LineageOS which lags behind Android releases itself but /e/ takes much longer to move to ship updates.

2026-02-02 21:17:48 UTC

- reply

GrapheneOS comes with our own fork of the open source TalkBack which we'll be updating soon. We recently built our own high quality text-to-speech implementation with a model we made ourselves with open source training data because we couldn't find any high quality open source options. Our text-to-speech is going to launch on our App Store soon and then will be included in GrapheneOS to have it working out-of-the-box followed by setup wizard integration.

2026-02-02 21:15:56 UTC

- reply

Murena Fairphones aren't a safe option due to lack of basic privacy and security patches. They include their own invasive services including sending data to third party services from OpenAI and others without user consent. Despite the marketing, they have highly privileged integration for Google apps and services along with always connecting to Google servers anyway. Strongly recommend reading the info at https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private and the linked 3rd party articles.

2026-02-02 16:47:58 UTC

- reply

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-01 23:30:04 UTC

- reply

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

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

/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

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:02:15 UTC

- reply

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

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 19:47:54 UTC

- reply

Location detection can be made a bit quicker and much better indoors by enabling "Network location" and "Wi-Fi scanning" in Settings > Location > Location services. It uses our own local position estimation based on data retrieved from Apple's location service for Wi-Fi APs and cell towers. It has the privacy trade-off of sending nearby networks to either our proxy or directly to Apple's service.
You could try Transportr for public transit navigation if you haven't already.

2026-02-01 19:10:37 UTC

- reply

GrapheneOS doesn't change how app notifications or app quick tiles on the lockscreen work. Apps decide which notifications are sensitive. We just make hiding sensitive info while locked into the default. We make more of the standard quick tiles require unlocking but it's up to apps to determine this for their own quick tiles.
There are native lockscreen widgets since Android 16 QPR2 in December 2025 which you should use instead of an app based on an accessibility service.

2026-02-01 19:05:50 UTC

- reply

> It does have an official store, but it only contains the bundled apps.
It also provides the Accrescent app store, Google Play Store, Google Play services, Android Auto and the Pixel Markup screenshot editor app.
We recommend using Accrescent for apps available through it. Not much is published there yet since it's in Alpha and still requires an invite for app developers to use it. In the future it will have more apps but for now other options are needed for most apps.

2026-02-01 18:56:13 UTC

- reply

> silo most proprietary apps into their own profiles
You can make 2 nested profiles inside the main Owner profile via Private Space and a work profile. You can avoid most of the inconvenience that way. GrapheneOS also adds support for using additional Private Spaces inside secondary users.
GrapheneOS also adds a notification forwarding feature for having the OS forward notifications from background profiles, although it censors the info the same way as on the lockscreen.

2026-02-01 18:53:12 UTC

- reply

We also add a PIN scrambling feature to randomize the PIN entry layout. That applies to the SIM PIN, a primary unlock PIN and a fingerprint unlock 2nd factor PIN too. It reduces convenience a little bit but not that much.
2-factor fingerprint unlock combined with PIN scrambling provides a lot of resistance against being recorded entering the PIN since it's harder to figure out what you entered and the fingerprint is needed too.

2026-02-01 18:48:19 UTC

- reply

> I do worry about my PIN being captured on a surveillance camera
One of the features added by GrapheneOS is 2-factor fingerprint unlock. It allows you to add a PIN as a 2nd factor required to complete fingerprint unlock.
GrapheneOS reduces the number of fingerprint unlock attempts from 20 to 5. Incorrect 2nd factor PIN counts as a failure. That means 4 random digits is fine.
This enables using a strong diceware passphrase for primary unlock without losing much convenience.

2026-01-31 21:38:31 UTC

- reply

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

No, but this article isn't accurate in general.

2026-01-31 10:12:29 UTC

- reply

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

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

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

Is GrapheneOS showing a Play Integrity API notice when trying to use it?

2026-01-30 20:14:59 UTC

- reply

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 19:57:16 UTC

- reply

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

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

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

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

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

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

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

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

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

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 15:00:34 UTC

- reply

Unlike SailfishOS, AOSP is open source and therefore it's possible to build GrapheneOS on top of it. AOSP has far better privacy and security than SailfishOS which brings the lower security of desktop operating systems to mobile.
Jolla has spent years attacking AOSP-based projects as a whole which includes us. You only think they should not be criticized in response to that because you're against AOSP-based projects.

2026-01-30 14:48:00 UTC

- reply

What's the issue with us pointing out an extreme form of hypocrisy where using open source code from the US is somehow awful but partnering with Putin's regime post-2014 is great?
Jolla and their supporters have been relentlessly attacking GrapheneOS recently, largely by making inaccurate claims about it and SailfishOS along with personal attacks on our team based on fabrications from harassment content.

2026-01-30 14:44:22 UTC

- reply

The context of our responses was someone attacking the GrapheneOS project for being based on an open source project largely developed by Americans. We pointed out the reality of that also applying to the Linux kernel and most other infrastructure projects used across these operating systems. We pointed out Jolla closely worked with Putin's government since 2015 since it's very relevant to their attack on us.

2026-01-30 14:20:01 UTC

- reply

> The only one I see insulting ALL the others on mastodon is you. For months.
No, that's a blatant lie. We haven't insulted anyone. Jolla condones harassment of our team in their community including with Kiwi Farms harassment material and worked with an authoritarian government for years. Their products do not provide what they claim and are falsely marketed. You falsely accuse us of behaving as you folks do.

2026-01-30 11:59:05 UTC

- reply

Jolla openly and extensively collaborated with an authoritarian government while they were invading a country and engaging in ethnic cleansing. You're not going to make that go away by baselessly calling people racist for having an issue with a company closely working with Putin's regime which started AFTER he invaded Ukraine and the government was sanctioned. Being against that and the people behind it is not racism.

2026-01-30 11:53:24 UTC

- reply

People begin against a company closely working with an authoritarian government and having substantial ownership and investment from that government is not somehow racism. In fact, it's you pushing the idea that products built by Europeans are somehow better than those made by people elsewhere in the world. Perhaps your issue with countries like Canada is that they're not white enough for you. Nice projection though.

2026-01-30 11:52:06 UTC

- reply

> None of the above articles are saying that sailfish is shit
The articles aren't covering the major issues with the OS. If you do basic research yourself then you can confirm yourself they worked closely with Russia and Jolla became largely owned by a Russian state-owned corporation. Jolla began partnering with Russia in 2015 after the initial invasion of Ukraine and sanctions.

2026-01-30 09:46:37 UTC

- reply

Using a device only support carrier-based calls/texts accessible to multiple carriers and only supporting connectivity via cellular often without a proper airplane mode to fully disable it is not more private than using an iPhone or a Pixel with GrapheneeOS but rather the direct opposite to an extreme. You're pushing using a highly insecure and non-private device where you share your conversations with carriers.

2026-01-30 09:44:59 UTC

- reply

GNSS (GPS, etc.) is a receive-only radio able to provide location detection without sharing your location. Being connected to cellular gives your location to the cellular network. Using GNSS doesn't give your location to anyone else. Wi-Fi supports providing a high level of privacy when implemented well and we have hardware requirements for Wi-Fi privacy such as probe randomization and other protections beyond that.

2026-01-30 09:43:25 UTC

- reply

You responded to a post recommending GrapheneOS to attack it and conflate it with options lacking basic privacy/security. It's your community which makes these unsubstantiated and inccurate attacks and then cannot tolerate it being debunked with factual information. The information we've provided is verifiable and people are perfectly capable of doing so with basic research. You've linked 0 sources so why expect us to?

2026-01-30 09:39:34 UTC

- reply

A dumb phone lacks private/secure communications and is entirely dependent on using cellular. In general, the functionality that's missing includes basic security patches and features. An iPhone/Pixel is much more secure hardware than any laptop/desktop and iOS/AOSP are much more private/secure than desktop operating systems. Using carrier-based calls/texts accessible to multiple carriers and others isn't private.

2026-01-30 03:14:16 UTC

- reply

> Without a credible source, you're just expressing your opinion. Your're the one telling a story (that may be true, I don't know), expecting others to trust you.
It's widely documented public knowledge. Jolla themselves acknowledges it but tries to spin it to be less bad than it is. The fact is that they partnered with the Russian government after their invasion of Crimea and the Donbass in 2014, then worked closely with them for years. They got cold feet in 2022. Look it up.

2026-01-30 02:34:31 UTC

- reply

If you want to make a clean break from US tech then your interest should probably be in small community OS and hardware projects not based on Linux rather than ones primarily based around code from US companies. An OEM can choose between the US, Taiwan and China for manufacturing to some extent but it's not really a direct choice available to customers. You generally get components from all 3 of those and many others.

2026-01-30 02:31:23 UTC

- reply

Linux is largely developed by large American tech companies. Most of the core maintainers work for large American tech companies. Countries other than the US have a disproportionately small involvement in it. You're hardly avoiding US tech by using open source software made as a collaboration between big tech companies in the US. Linux, all 3 mainstream browser engines and far more comes from the US.

2026-01-30 02:29:12 UTC

- reply

There's no full US stack for smartphones. Smartphones and computers in general have components made in a bunch of different countries. The most complex components which are the most important are mainly designed in the US and Taiwan. A lot of the manufacturing is in China but sophisticated chips are often made in Taiwan. Jolla just does final assembly in Europe, their devices are hardly actually manufactured there.

2026-01-30 02:26:57 UTC

- reply

You can quickly find many sources on Jolla's ties to the Russian government which they say they've broken away from recently, but it doesn't change that it's the history of the company since 2015 until they started changing course in 2025. They only began working with Russia after they invaded Ukraine and got into the situation where they had near a majority steak or potentially even a majority stake in the company.

2026-01-30 02:25:17 UTC

- reply

We have no interest in devices with atrocious security just because the company is based in Europe and puts the incredibly complex hardware components from China, Taiwan, US, etc. into a case in Europe. Assembling the components into a device in Europe does not make it any more trustworthy. The vast majority of the hardware complexity including the SoC come from the same few non-European countries as other devices.

2026-01-30 02:20:07 UTC

- reply

Jolla was near majority owned by a Russian state owned company in 2022. They've supposedly split away from the Russian government now but it's highly questionable. They had very close ties to Russia and were directly working with them. Russia still has an OS based on SailfishOS and is still actively working on it. They may just start openly working with the Russian government again post-war even if it's a temporary peace.

2026-01-30 02:14:36 UTC

- reply

They were fine with working closely with an highly authoritarian government heavily investing in their company to the point that a Russian state agency owned most of their company. It's only when it became very bad for business and their career prospects that they decided something had to be done. It's still the same group of people who thought that made sense, they've just rebranded themselves. It's easy to confirm all this.

2026-01-30 02:12:28 UTC

- reply

Jolla closely partnered with the Russian government in 2015 after their initial invasion of Ukraine occupying Crimea and the Donbass. Russia heavily invested in Jolla and played a major role in developed. It was developed in partnership with Putin's government after he invaded Ukraine. They only started trying to reduce ties to the Russian government after the expanded invasion in 2022 when it became a PR disaster for them.

2026-01-30 02:08:00 UTC

- reply

They're building on top of software from big tech companies and that's the open source part. What they're building on top of that is largely closed source. SailfishOS cannot be the basis for a project like GrapheneOS due to not being open source. It's not clear why you think we'd support a company earning money off falsely marketing insecure devices with a closed source OS they made in partnership with Putin's government.

2026-01-30 02:01:08 UTC

- reply

SailfishOS is largely closed source and has atrocious privacy and security compared to AOSP.
Jolla was closely tied to the Russian government and directly working with them long after they invaded Crimea in 2014. They've supported attacks on the GrapheneOS project and team along with spreading lots of misinformation about it. Why would we support a highly unethical company making awful slop pushed with false marketing?

2026-01-30 00:06:40 UTC

- reply

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

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

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.