GrapheneOS

We already have a notification for apps using the Play Integrity API and can start detecting these libraries consistently causing compatibility issues to warn users about it. These notifications can have a shortcut for leaving a Play Store review for users with the sandboxed Play Store installed.

2026-07-16 19:12:12 UTC

V-Key's libraries depend on private APIs and implementation details. This causes compatibility issues with new Android releases, OEM changes and GrapheneOS security protections. We're now aware of it and worked around the known compatibility issues. However, they need to start fixing it themselves.

2026-07-16 16:29:00 UTC

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

2026-07-15 19:55:18 UTC

- reply

@nprofile…d9jm No, since that's using the Play Integrity API.

2026-07-15 18:54:05 UTC

- reply

We've resolved the new compatibility issues with anti-tampering code in banking apps. We're in the process of making a new release with the workarounds. We posted a new thread about it:
https://grapheneos.social/@GrapheneOS/116925427491681935

2026-07-15 18:51:13 UTC

- reply

You can see the relevant changes here:
https://github.com/GrapheneOS/platform_frameworks_base/pull/410
https://github.com/GrapheneOS/platform_system_core/pull/43

2026-07-15 18:50:18 UTC

- reply

Our new secure spawning improved overall app compatibility despite these 2 anti-tampering SDKs causing new issues with it. We've solved the regressiond and are currently building a new release with the improvements. It will be available in around 12 hours. App compatibility will be better than ever.

2026-07-15 18:46:12 UTC

- reply

Our new secure spawning implementation has better app compatibility. This made it possible for the V-KEY V-OS Mobile App Protection anti-tampering SDK to run instead of crashing and it began blocking GrapheneOS. We've solved this problem by simply blocking their code from running for the time being.

2026-07-15 18:43:10 UTC

- reply

Our new secure spawning also added a per-app toggle. Alongside this, we made is possible to disable secure spawning and hardened_malloc at the same time. This requires an extra zygote with hardened_malloc disabled which we spawned on-demand. It has to be spawned at boot instead for low mount IDs.

2026-07-15 18:39:42 UTC

- reply

Our new secure spawning implementations runs the same code run by the Zygote after exec to improve compatibility. Many apps which didn't work before are now compatible. However, that tripped this mount ID check by recreating a mount namespace. It doesn't need that part so we've simply removed it.

2026-07-15 18:33:54 UTC

We solved the recent regression in compatibility with a small subset of banking apps. It was caused by a Zimperium anti-tampering SDK checking the Linux kernel mount ID for /system/framework/framework.jar and banning it being above 900. Our new secure spawning was tripping it.

2026-07-15 18:28:44 UTC

- reply

We've resolved the issue. See our new thread about it:
https://grapheneos.social/@GrapheneOS/116925334629738010

2026-07-15 18:28:11 UTC

- reply

This SDK checks the mount ID for /system/framework/framework.jar and disallows the ID being above 900. They use this to detect mounts created by Magisk and similar software. We've changed our new secure spawning related code to always create this mount namespace in early boot.

2026-07-15 18:21:06 UTC

- reply

This SDK checks the mount ID for /system/framework/framework.jar and blocks using the apps if it's above 900. They use this to detect mounts created by Magisk and similar software. We don't need mount namespaces for sandboxing due to SELinux so it can be easily worked around.

2026-07-15 18:20:37 UTC

- reply

2026-07-15 18:14:12 UTC

- reply

We solved the recent regression in compatibility with a small subset of banking apps. It was caused by the V-KEY V-OS Mobile App Protection SDK. It checks Linux mount IDs and breaks if mount namespaces are created after early boot. We've started builds for a new release already.

2026-07-15 18:10:17 UTC

2026-07-15 14:55:50 UTC

- reply

@nprofile…y26f Motorola flagships with GrapheneOS support will likely be available in 2027, hopefully within 12 months. It will take longer for lower end devices to be supported. The initial devices will be more expensive than most Pixels but it will end up supporting devices in a similar price range as Pixels including the 'a' series devices over time.

2026-07-15 13:36:36 UTC

- reply

@nprofile…znt3 @nprofile…quyq That may require an OS change if it's based on it being the system gallery app.

2026-07-15 13:35:07 UTC

- reply

@nprofile…kj8p Revolut should currently work fine on GrapheneOS but they may ban it in the future with the Play Integrity API. We'll have to do a pressure campaign to get them to unban it if that happens. We suspect it will happen because we had to work around an SDK in the Revolut app which was explicitly banning using GrapheneOS. It was even detecting the string "grapheneos" as the build user for the OS which we had set for reproducible builds. We had to change that and other things it checked.

2026-07-15 00:42:41 UTC

- reply

@nprofile…quyq We're going to be completely replacing the legacy AOSP Gallery with a much more modern app in the near future. Our Camera app will also get a major overhaul with many new features and a new user interface. The current Gallery isn't our own app but rather a legacy AOSP sample app and is awful but it's going to be gone soon.

2026-07-14 22:16:13 UTC

- reply

@nprofile…06ud The system would be fine if it was open sourced after a week instead of typically taking 2-4 months and sometimes longer.
It's worth noting security preview patches include patches to external projects. These patches aren't only for things Android uses. Some are publicly disclosed elsewhere already while others are not. There have been patches from Android security previews for projects used outside Android shipped in GrapheneOS according to the rules prior to disclosure elsewhere.

2026-07-14 22:13:47 UTC

- reply

@nprofile…06ud It's done because OEMs are so terrible at shipping patches. They started off giving them 30 days of early embargoed access but it wasn't enough and OEMs found it too difficult to ship patches each month. It also put users at risk from having it broadly disclosed for 30 days.
The new system allows every OEM to ship the patches without an embargo as GrapheneOS does while papering over OEMs taking many months to ship it. It's more secure when used well and covers up the failures.

2026-07-14 22:09:44 UTC

Vanadium version 150.0.7871.124.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/150.0.7871.124.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/40347-vanadium-version-150078711240-released
#GrapheneOS #privacy #security #browser

2026-07-14 20:14:38 UTC

- reply

@nprofile…a4ar NFC payments work in apps not using the Play Integrity API to ban alternatives to Google Mobile Services Android.
Tap-to-pay works in Curve Pay, PayPal and many European banking apps. We aren't currently aware of an option available outside of Europe.

2026-07-14 19:01:24 UTC

- reply

We found one anti-tampering SDK was crashing due to being incompatible with secure (exec-based) spawning and therefore permitting having any OS. By fixing compatibility with it, we enabled it to detect and ban GrapheneOS. We'll fix that too. Banking app code is ultra low quality.

2026-07-14 18:59:05 UTC

- reply

In some cases, we've found the issue is that the anti-tampering code was previously crashing due to being incompatible with the previous secure spawning implementation so it wasn't banning GrapheneOS. By improving compatibility with it, we enabled it to ban GrapheneOS. We'll fix that problem too.

2026-07-14 18:57:04 UTC

- reply

@nprofile…3jn2 Their anti-tampering code is very broken. It started banning GrapheneOS due to some kind of change tied to the new secure spawning implementation but it can be stopped by breaking it using a VPN.
It's possible the anti-tampering code was completely broken by using secure spawning with the previous implementation but the new implementation improved compatibility with it which enabled it to ban GrapheneOS.

2026-07-14 18:45:19 UTC

- reply

Our per-app compatibility mode and the finer-grained toggles it uses can be used to work around most broken anti-tampering code. Our new per-app secure spawning toggle made it better. We need to fix the new compatibility issue with another flawed anti-tampering SDK though.

2026-07-14 18:38:10 UTC

- reply

These apps have poor security and instead deploy half-baked anti-tampering mechanisms with memory corruption bugs and many dependencies on implementation details changing between Android releases. It's why these apps usually break on new major Android versions until they upgrade.

2026-07-14 18:36:55 UTC

- reply

The new secure spawning implementation uncovered some more of these strange cases of apps banning GrapheneOS for obscure reasons. Since multiple users are reporting using a VPN set to another country works around it for Chase, that's worth trying as a workaround for others too.

2026-07-14 18:35:48 UTC

- reply

Our new secure spawning implementation improved overall app compatibility but there are still apps detecting differences from the stock OS and banning GrapheneOS. One cause we've discovered are apps counting the number of memory pages considered shared and banning having too few.

2026-07-14 18:34:39 UTC

Our users are reporting the Chase banking app is banning using GrapheneOS but permits it when a VPN is enabled and set to another country:
https://discuss.grapheneos.org/d/40289-chase-app-error-on-latest-graphene-version
We're aware of this compatibility issue with several apps and are actively working on improvements to resolve it.

2026-07-14 13:08:40 UTC

- reply

@nprofile…ud5y No, those EU standards don't require providing reasonable security patches. We've been pointing out how flawed those standards are for years. Android was already only backporting High and Critical severity patches to older releases which was in full compliance with the regulations. Further reducing how much gets backported is still in compliance. The regulations only require OEMs to do what Google defines as the bare minimum and Google has heavily watered down the standard patches.

2026-07-14 13:07:41 UTC

- reply

@nprofile…06ud We aren't happy about it because we want to be able to quickly provide the full set of patches in our regular releases. It's ridiculous having the patches not disclosed as open source for months. It should be a week at most, ideally significantly less than that. Our plan is to start having people reverse engineer patches from binary which can then be merged into the regular releases if it's done correctly. We aren't quite ready to get started on shipping them that way but we plan to.

2026-07-14 13:06:35 UTC

- reply

@nprofile…06ud GrapheneOS is already the only way to get all of the Android security preview patches early. Samsung flagships and Pixels ship a subset early but much more slowly than we do and they don't ship all of them. We get all of the security preview patches integrated and tested quite quickly. It's already a unique feature of GrapheneOS giving it yet another major privacy and security advantage over every other Android variant. We strongly recommend everyone uses the security preview releases.

2026-07-14 13:05:16 UTC

- reply

@nprofile…06ud We have full access to the security preview patches providing the Android Security Bulletin patches 2-6 months ahead. We ship the full set of relevant patches in our security preview releases. Each of our regular releases has a corresponding security preview releases. Our release notes provide a list of the included security preview patches. You can see how many patches are added in our security preview releases in our release notes listing those at the bottom:
https://grapheneos.org/releases#2026071100

2026-07-14 13:02:05 UTC

- reply

@nprofile…n6nv We have an unused @nprofile…8d0p account on Instagram to reserve the name. Every other account on Instagram using the GrapheneOS name is impersonating the project. There are many of those accounts impersonating us to sell sketchy devices supposedly running GrapheneOS. It's why we made the placeholder account to reserve the main name.

2026-07-14 13:00:19 UTC

- reply

@nprofile…ud5y No, those EU standards don't require providing reasonable security patches. We've been pointing out how useless the standards are for years. Android was already only backporting High and Critical severity patches to older releases which was in full compliance with the regulations. Further reducing how much gets backported is still in compliance. It requires that OEMs ship the extremely incomplete backports deemed to be the standard ones and slowly update the OS version too.

2026-07-14 03:02:58 UTC

- reply

Google needs to start open sourcing QPR1 and QPR3 releases again along with open sourcing security preview patches shortly after disclosure to OEMs. Otherwise, we'll just hire people to start doing reverse engineering work in an official capacity to start publishing the changes as open source early.

2026-07-14 02:56:37 UTC

- reply

Google switched to a performative Android Security Bulletin system with vulnerabilities listed 2-4 months after they're shipped. They're pretending as if not open sourcing patches protects people from OEMs not patching them. Our community has people successfully reverse engineering binary patches.

2026-07-14 02:55:01 UTC

- reply

Google is completely overwhelmed by the massive torrent of vulnerabilities discovered by AI models. They've done repeated cycles of layoffs and buyouts crippling their ability to handle it. The change to the schedule for Android Security Bulletins is also extremely at odds with this new reality.

2026-07-14 02:50:52 UTC

- reply

We're going to need to do a lot of work with Motorola and Qualcomm to provide serious patches for GrapheneOS devices. We're going to need more developers. After the launch of the new devices with GrapheneOS support, we want to repeatedly port to the latest Linux LTS branch among other major changes.

2026-07-14 02:47:07 UTC

- reply

Vast majority of Linux kernel vulnerabilities aren't covered by Android Security Bulletins, externally disclosed patches are backported very slowly and Android Security Bulletins come 2-4 months later than when Android patches can be shipped. If you want bare minimum patches, use iOS or GrapheneOS.

2026-07-14 02:44:43 UTC

- reply

Android 17 is the only Android release with the current set of disclosed Moderate and Low severity patches. Android 16, 16 QPR2 and 17 will soon be the only releases with the current set of disclosed Critical and High severity patches too. Once Android 18 is released, it will be the only one.

2026-07-14 02:43:34 UTC

- reply

Bare minimum Android security patches now require being on Android 16, 16 QPR2 or 17 and quickly moving to Android 18 when it's released. Once Android 18 is released, it will be the only release with current High and Critical severity patches. Serious support for older Android releases has ended.

2026-07-14 02:41:43 UTC

- reply

The vast majority of vulnerabilities are now being discovered internally by Google for Android and Chrome. These are largely being discovered with AI. The subset deemed Critical severity and an imminent risk will be backported to 16 and 17. Bare minimum security support for older releases is over.

2026-07-14 02:37:55 UTC

- reply

Android Security Bulletins already omit Moderate and Low severity patches. They're already dated 2-4 months after the vulnerabilities were disclosed to OEMs and allowed to be shipped. Only Samsung flagships and Pixels ship any of it 'early' on practice. Only GrapheneOS ships the full set 'early'.

2026-07-14 02:34:05 UTC

- reply

Externally reported vulnerabilities will currently still follow the same policy for backports as before. High and Critical severity vulnerabilities reported to Google by external parties will be backported to releases going back around 3 years (currently 14, 15, 16 and the current latest stable 17).

2026-07-14 02:31:10 UTC

- reply

Google recently informed OEMs of greatly reduced security support for older releases of Android. For the vast majority of discovered vulnerabilities, only Critical severity issues deemed to be an imminent risk will be backported at all and only to the most recent 2 major yearly releases (16 and 17).

2026-07-14 02:26:39 UTC

Android's security policy for the past several years has been to backport patches for Critical and High severity Android vulnerabilities to the past 3 major yearly releases. Moderate and Low severity patches including most fixes for privacy weaknesses have required upgrading to the latest releases.

2026-07-12 15:08:08 UTC

- reply

@nprofile…v2us By default, GrapheneOS runs exec after fork from the zygote processes in order to create a fresh address space with a per-process randomized address space layout, randomized heap layout, random canaries, random memory tags and other per-process state. It substantially improves security especially when combined with the extensive usage of hardware memory tagging on GrapheneOS. Exec-based spawning was one of the earliest GrapheneOS features added in 2014.

2026-07-12 01:41:22 UTC

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

2026-07-11 22:19:03 UTC

- reply

@nprofile…2d2w You can see the account which replied to you is a single purpose account created for the sole purpose of attacking the GrapheneOS project: It was created on July 9th and now has 4 posts downplaying the ongoing attacks across platforms and engaging in trolling. The account goes out of the way to act as a juvenile troll while downplaying extremely malicious misinformation, libel and harassment as being people joking around. It's a very serious situation including real world attacks.

2026-07-11 22:15:45 UTC

- reply

@nprofile…2d2w You can see the account which replied to you is a single purpose account created for the sole purpose of attacking the GrapheneOS project: It was created on July 9th and now has 4 posts downplaying the ongoing attacks across platforms and engaging in trolling. That account is a clear example of a troll, but that's not most of what we're experiencing. Most of the attacks on GrapheneOS are malicious misinformation and harassment aimed at others and they don't want us responding.

2026-07-11 20:35:28 UTC

- reply

@nprofile…lezl @nprofile…v43s It even has optional GPU acceleration support via gfxstream and will eventually have support for hardware GPU acceleration support.
Desktop mode and virtualization of other operating systems are both going to get much better. Android is moving towards replacing ChromeOS and that functionality is going to be available in GrapheneOS too. We also plan to improve it.

2026-07-11 20:30:08 UTC

- reply

@nprofile…lezl @nprofile…v43s GrapheneOS has DisplayPort alternate mode and the standard Android 17 desktop mode. It has always been able to use a mouse, keyboard, game controller, etc.
There's also the standard hardware-based virtualization support including the experimental Terminal app for managing virtual machines running other operating systems. That has GUI and audio input/output support.

2026-07-11 13:22:54 UTC

- reply

@nprofile…5swn There are many ways for apps to detect the other apps in the same profile and communicate with other apps in the same profile with mutual consent. The best way to handle it is using profiles which are designed for it. It would be very difficult to fully block app communication or even detection within cooperation within a profile. We did a lot of work towards is and it wasn't feasible for us to close all the ways of doing it. More nested profile features are far more realistic.

2026-07-11 13:20:52 UTC

- reply

@nprofile…hpz0
> Allowing app that support it to use it, and possibily allowing yourself later (if you have time and the will) to try to "intercept" FCM connection and force route them to this NTFY ?
Those apps have services sending their push messages to Google's services. It isn't possible to change their server code to use an arbitrary UnifiedPush provider. It's possible to run an FCM bridge on a server or a bridge for another kind of push messaging system but not to replace it client side.

2026-07-10 19:10:08 UTC

- reply

@nprofile…yu9g It could also potentially remember that the hotspot was previously enabled when switching back to a user which had it enabled before switching away, at least until reboot since we wouldn't want to make it more persistent than it usually is in that regard. That would be harder than making the quick tile work and it's not clear if it's something we actually want to do.

2026-07-10 19:09:13 UTC

- reply

@nprofile…yu9g Wi-Fi settings were moved from device encrypted storage to per-user credential encrypted storage with networks belonging to users with the option to disable sharing those with other users or editing by other users. It has per-user Wi-Fi settings now so it has to turn off Wi-Fi when switching users and then turn it back on with the settings for that user. That's what causes the hotspot to get turned off. We can add the hotspot quick tile to secondary users as they should have though.

2026-07-10 14:23:30 UTC

- reply

@nprofile…yu9g No, it works in every user and can be enabled by secondary users now instead of only the main user. Android 17 moved to per-user Wi-Fi settings. Wi-Fi hotspot quick tile isn't supported in secondary users yet but it can be enabled in the Settings app. We plan to make the Wi-Fi quick tile usable in secondary users as a GrapheneOS enhancement prior to it being done upstream.

2026-07-08 19:27:43 UTC

- reply

@nprofile…n6nv AOSP Gallery is in the process of being entirely replaced rather than overhauled. AOSP Keyboard will also be replaced. We haven't decided if we want to replace or overhaul the AOSP Clock app.

2026-07-08 18:03:25 UTC

Secure PDF Viewer app version 32 released:
https://github.com/GrapheneOS/PdfViewer/releases/tag/32
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/37983-secure-pdf-viewer-app-version-32-released
#GrapheneOS #privacy #security #pdf #android

2026-07-06 15:33:40 UTC

- reply

@nprofile…u4ah We aren't aware of any current issues with wireless Android Auto beyond the usual connectivity issues caused by USB, Wi-Fi and Bluetooth connectivity issues. Try disabling and then enabling the sandboxed Google Play toggle for it again.

2026-07-06 15:16:11 UTC

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

2026-07-02 00:21:27 UTC

- reply

@nprofile…7gf2 GrapheneOS only supports devices with a secure element enforcing the rate limiting via Weaver. Pixel 6 and later were updated to use the new stricter rate limiting.
No attempts are permitted after 20 failures. Since it's enforced by the secure element, it can't be bypassed with an OS update removing the limit.
Secure element only accepts updates after the Owner authenticates so a firmware update removing it couldn't be installed in Owner user Before First Unlock state

2026-07-01 23:51:09 UTC

- reply

@nprofile…7gf2 Make sure the length of what you attempt is at least 4 characters/digits or it discards it without attempting to use it.
It triggers a 1 minute lockout here when testing with a random 6 digit PIN and entering unique incorrect PINs at least 4 long.

2026-07-01 22:48:38 UTC

- reply

@nprofile…7gf2 GrapheneOS has been based on Android 16 QPR2 for around half a year and is now based on Android 17. It already has the current rate limiting which has become stricter over time.

2026-06-30 23:24:42 UTC

Vanadium version 150.0.7871.63.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/150.0.7871.63.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/37454-vanadium-version-15007871630-released
#GrapheneOS #privacy #security #browser

2026-06-30 22:20:10 UTC

- reply

@nprofile…ss2c @nprofile…54gt They're paying the ongoing costs for the servers. Our userbase is growing so the bandwidth usage is going to substantially increase unless it's split with additional sponsored servers. With these 2 servers, we have a lot of room for userbase growth. Without these 2 servers, we would end up needing to substantially slow down how quickly we roll out major updates. There would be a lot of pressure to get more server sponsors soon. With these we have a lot of breathing room.

2026-06-30 22:09:56 UTC

- reply

@nprofile…ss2c @nprofile…54gt There are 5 companies giving us update servers. 4 of those are server hosts so they don't pay ongoing costs for the hardware but do pay the electricity and transit costs. Mullvad isn't a server host so they're the exception. They have a large number of DataPacket servers so they get a bulk discount of around 30% for renting the servers and paying for bandwidth. Mullvad got DataPacket to make us a sub-account of their account which bills Mullvad and gets the discount.

2026-06-30 21:38:12 UTC

- reply

@nprofile…ss2c @nprofile…54gt Most people want us to self-host services instead of using a centralized CDN from one of the largest internet companies. We host our own global anycast DNS networks and distributed servers for our updates and many other services. If we don't have the sponsorships then we're not necessarily going to do it the same way where it's decentralized and doesn't depend on a big tech company hosting a large portion of the internet.
Would you prefer if we were paying Cloudflare?

2026-06-30 21:37:13 UTC

- reply

2026-06-30 21:34:14 UTC

- reply

@nprofile…ss2c @nprofile…54gt Recently, 2 dedicated server companies giving us sponsored update servers essentially went bankrupt and we were in a bad situation without nearly enough update bandwidth available to handle major updates. We no longer had any update servers in Europe.
We asked for EU update server sponsorships and ended up getting 3 offers which turned into servers for us which are the 3 we have now.
If we're going to get rid of 62.5% of the bandwidth we have then we need to replace it.

2026-06-30 21:27:04 UTC

- reply

@nprofile…ss2c @nprofile…54gt The 5 companies sponsoring our overall servers give us servers, not money. It would cost more money if we paid for it ourselves than it costs them to provide it.
We haven't removed the servers from our DNS configuration, wiped our data from them or asked for Mullvad to take them away from us at this time. If we did decide to get rid of them then we'd need replacement update mirrors. It's 100Gbps out of the total 160Gbps bandwidth we have for update downloads.

2026-06-30 21:18:05 UTC

- reply

@nprofile…ss2c @nprofile…54gt Mullvad gave us 2 update mirrors which have an ongoing financial cost. It's cheaper for them to pay for servers since they have a huge bulk discount.
Mullvad didn't request us making any posts to promote them or listing them on a sponsors page. They were still extremely well regarded by nearly everyone several days ago. We chose to make the server sponsorship prominent rather than that being a condition of them doing it so we don't have to continue doing that at all.

2026-06-30 17:51:30 UTC

- reply

@nprofile…54gt The context for this is that Mullvad's co-founder donated to an ethnonationalist group who split away from the mainstream anti-racist socialist party. A few months ago, Mullvad sponsored 2 update mirrors for GrapheneOS similarly to how they sponsor many other open source projects. They're partnered with Tor and Mozilla. They give $250k/year to QubesOS. They were were well regarded before several days ago and we chose to make several posts about it (they didn't request anything).

2026-06-30 17:30:09 UTC

- reply

@nprofile…54gt We've clearly stated we're anti-fascist and are opposed to authoritarianism and ethnonationalism. The same can't be said for people attacking us who openly deny many forms of those exist in the first place.

2026-06-30 17:29:28 UTC

- reply

@nprofile…54gt We've clearly stated we're anti-fascist and are opposed to authoritarianism and ethnonationalism. The same can't be said for people attacking us who are unwilling to acknowledge many forms of those exist, let alone disavowing support for them.

2026-06-30 17:26:21 UTC

- reply

@nprofile…54gt We've clearly stated we're anti-fascist and against other forms of authoritarianism too. The alignment of people attacking us for opposing authoritarians from the left and center are what's highly suspicious.
Do you oppose the authoritarian governments in Cuba and China? Most of the people attacking us won't answer yes to that question which is why they're upset with what we said.

2026-06-30 16:36:38 UTC

- reply

@nprofile…v9yp
> Inasked for left authoriatian
We provided examples of those (USSR, Warsaw Pact countries, North Korea, PRC, current era Cuba, [...]).
> And bow you say all those are neither left or right.
No, we said dictatorships and authoritarianism are not inherently left or right wing in response to you asking if we believed that.
> Oh well. I guess your OS has the same level of no concept than you political arguing skills.
You're poorly twisting what we said with no attempt to hide it.

2026-06-30 16:36:25 UTC

- reply

@nprofile…v9yp
> Inasked for left authoriatian
We provided examples of those ( USSR, Warsaw Pact countries, North Korea, PRC, current era Cuba, [...]).
> And bow you say all those are neither left or right.
No, we said dictatorships and authoritarianism are not inherently left or right wing in response to you asking if we believed that.
> Oh well. I guess your OS has the same level of no concept than you political arguing skills.
You're poorly twisting what we said with no attempt to hide it.

2026-06-30 16:03:17 UTC

- reply

@nprofile…7gxm @nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 Mullvad hasn't given us money. They gave us 2 sponsored update servers. It would cost more money for us to pay for those than it costs for them to sponsor it since we don't have a 30% discount.

2026-06-30 15:56:39 UTC

- reply

@nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 The main issue people attacking us appear to have with us is that in additional to saying we're anti-fascist, we're also opposed to authoritarians on the left and center too.
Sweden has a far right nationalist party as the largest party in the governing coalition. Mullvad's co-founder donated to a much different form of ethnonationalists. We've made it clear we oppose both. You folks haven't opposed what he donated to since you don't acknowledge it exists.

2026-06-30 15:54:45 UTC

- reply

@nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 The main issue people attacking us appear to have with us is that in additional to saying we're anti-fascist, we're also opposed to authoritarians on the left and center too.
The party the Mullvad co-founder donated too is in fact not Sweden's far right nationalist party which is part of the governing coalition but rather something quite different. If you can't acknowledge what it is that he donated to and pretend it's not a problem, then you are the problem.

2026-06-30 15:49:31 UTC

- reply

@nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 Several months ago, Mullvad gave us 2 sponsored servers from Mullvad on DataPacket which we put in Frankfurt and Dallas. We made clear public statements that we oppose the party one of their co-founders donated to.
It's fair to ask why we're being viciously attacked but https://www.qubes-os.org/partners/ or their major sponsorship of Tor aren't an issue for the same people attacking us.
It's also fair to question why us opposing authoritarianism as a whole is an issue.

2026-06-30 15:39:57 UTC

- reply

@nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 Here are examples of Linux distributions listing organizations sponsoring servers:
https://mirrors.almalinux.org/
https://almalinux.org/blog/2024-08-07-mirrors-1-to-400/
https://www.debian.org/mirror/sponsors
Is it a problem Debian is sponsored by the Russian state and lists it on their site?
https://archlinux.org/mirrors/
How about https://midov.pl/ there? We have midov.pl defederated on Matrix because it's filled with nazis.
You folks don't hold others to the same standard and viciously lie about us.

2026-06-30 15:22:11 UTC

- reply

@nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 None of our server sponsors expected us to do anything beyond what we already decided is best practice of listing them as a sponsor on our servers page with a link to their site.
IPinfo wanted us to provide information on how we're using it and wanted a link with their logo so we made the sponsors page and included the server sponsors despite that never having been a request. Both those requests are completely reasonable and are part of transparency anyway.

2026-06-30 15:20:07 UTC

- reply

@nprofile…08g8 @nprofile…7xqy @nprofile…2kp4 ReliableSite gave us 2 sponsored 10Gbps servers in Los Angeles and Miami when we heavily needed them. Those are the first set of sponsored servers we received. All they wanted was a link to their website anywhere on ours which we decided makes sense for transparency. They didn't require us to make that sponsors page, they were fine with the link on our servers page. We don't consider something we decided is best practice to be an actual string attached to it.

2026-06-30 13:24:19 UTC

- reply

@nprofile…2kp4 We've made it entirely clear we define the GrapheneOS project as being anti-authoritarian and as part of that it's opposed to ethnonationalism. These are shared values for people working on GrapheneOS. We aren't going to define the project as being anti-statist or anarchist since only some people working on it are.
> plus you're saying all this fascist shit
This is an outrageous lie.
> the money/support you receive is NEVER apolitical
We don't take money with strings attached.

2026-06-30 13:14:34 UTC

- reply

@nprofile…v9yp
> Oh, so dictatorships are left? Giving no liberties to the population is left?
No, it's neither left or right. There are many current and historical examples of it across left, center and right. None of those means anti-authoritarian.

2026-06-30 03:34:28 UTC

- reply

@nprofile…ml4y It's a virtual machine management app which includes support for audio and graphics. It doesn't have proper permission management yet including providing access to all of the profile's home directory.

2026-06-30 03:23:22 UTC

- reply

@nprofile…ml4y It supports audio recording and it now requests the permissions it knows how to use. It will work without it granted though. It does need Nearby Devices for local network access until it's moved away from the current internal local network for talking to the VM since Android 17 requires that permission for local network access and there isn't a special exception for this.

2026-06-30 03:23:00 UTC

- reply

2026-06-29 21:03:27 UTC

- reply

We've made it very clear we strongly oppose authoritarianism and ethnonationalism.
This post is taking a reply we made in response to someone claiming authoritarianism cannot exist outside the right and portraying it as something else:
https://mastodon.com.pl/@tragivictoria/116834132434709516
In the replies, it's claimed that was a mistake but there's no correction or retraction of it.
We previously reported harassment by several of their project members with links to it. We began providing it again in a DM and were blocked.

2026-06-29 20:54:12 UTC

- reply

2 of our update mirrors were recently sponsored by Mullvad. Mullvad sponsors a bunch of open source projects including QubesOS (250k/year), Tor and works with Mozilla.
We've made posts making it clear we oppose authoritarianism and ethnonationalism. We don't support the tankie ethnonationalists Mullvad's co-founder donated to.
She made recent posts on her timeline calling us unhinged, closely resembling the harassment she says she knows nothing about, and making false claims about our beliefs.

2026-06-29 20:42:51 UTC

We were asked by @nprofile…sjxs to provide links to the harassment content which has been repeatedly spread by GNOME project members. We provided the requested links to the harassment content via a DM and were quickly blocked.
We've previously filed Code of Conduct committee reports with Fedora and GNOME about this. Fedora said it wasn't covered and GNOME didn't acknowledge it at all. Multiple of their project members have repeatedly linked content from Kiwi Farms users targeting us.

2026-06-29 20:14:38 UTC

- reply

@nprofile…v9yp USSR, Warsaw Pact countries, North Korea, PRC, current era Cuba, [...]
Do you deny that tankies exist?

2026-06-29 18:10:42 UTC

- reply

@nprofile…j908 We said GrapheneOS is anti-authoritarian, not apolitical. We oppose authoritarianism and ethnonationalism. You're misrepresenting and twisting what we said to an extreme degree. We strongly oppose fascists and we also oppose tankies too. What is the problem you have with that?