GrapheneOS

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

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

NIP-05 Address

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qz9thwden5te0wfjkccte9ekk7um5wgh8qatzy4vwt2

Publishing to

relay.ditto.pub

relay.mostr.pub

Author Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Show more details

Last Notes

2026-08-25 10:24:50 UTC

- reply

As we said in the first paragraph, our initial focus is on a non-folding device. We haven't provided a timeline on when we'll be able to expand to folding devices. This thread was published to clarify people should expect a non-folding device first despite media speculation.

2026-08-24 18:08:52 UTC

AppCompatConfig version 8 released:
https://github.com/GrapheneOS/platform_packages_apps_AppCompatConfig/releases/tag/8
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/41432-appcompatconfig-version-8-released
#GrapheneOS #privacy #security

2026-08-23 18:59:18 UTC

- reply

@nprofile…s7qu That's likely the issue. We made it easier for companies to automatically add the new ones by adding a signed JSON file providing them.
https://grapheneos.org/articles/attestation-compatibility-guide

2026-08-23 16:07:32 UTC

- reply

@nprofile…s7qu Did you try the per-app exploit protection compatibility mode?

2026-08-22 17:49:01 UTC

- reply

@nprofile…xawl The current generation Motorola devices don't meet our requirements. It's a subset of the next generation ones which will meet our requirements. We pointed to the Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) as an example of what's coming. The current Signature is the predecessor to the upcoming device we're working on them with and we should be able to support the horizontal and vertical folding flagships with very similar hardware to that afterwards.

2026-08-22 17:00:26 UTC

- reply

@nprofile…ledj @nprofile…86nn @nprofile…nqv0 Our users often import Pixels to other countries and in some of those they still have those features marked as disabled for most carriers. The features usually work when simply force enabled so we added a way to do it. It's not forced by default since it may not work and we don't want to have broken mobile data and calls by default. It works with most carriers without those already enabled and users can easily figure out if it works with basic testing.

2026-08-22 16:58:53 UTC

- reply

@nprofile…ledj @nprofile…86nn @nprofile…nqv0 It works well with it.
By default, GrapheneOS works with all of the carriers supported by the stock Pixel OS. GrapheneOS adds a carrier overrides feature usable to force the availability of 5G, VoLTE, VoNR, VoWiFi and cross-SIM calling. This means GrapheneOS can be used with those features on carriers in countries where Pixels aren't available and haven't done compatibility testing to mark those as available. It makes it work better globally.

2026-08-22 16:51:17 UTC

- reply

@nprofile…kj8p We want it to be possible to buy the regular variant of the devices and install GrapheneOS on those to avoid depending on the availability of devices sold with GrapheneOS. These details all need to be worked out once it's closer to ready.

2026-08-22 16:50:26 UTC

- reply

@nprofile…0hzt We plan to support it and also plan to make it possible to use their camera app similarly to how we support using Pixel Camera.

2026-08-22 16:45:52 UTC

- reply

@nprofile…ajc2 If you use a strong passphrase as the primary lock method then you don't depend on the secure element rate limiting. A secure element exploit cannot make disk encryption less secure than it would be without the secure element. It authenticates with the secure element with a hash of the key to obtain a token stored there which is used as an extra input to key derivation. It only adds security and it's crucial for most users.

2026-08-22 16:43:13 UTC

- reply

@nprofile…ajc2 The main benefit of the secure element is having aggressive rate limiting for encryption key derivation attempts. Only 20 unique attempts are permitted for each profile to derive the key encryption keys with rapidly increasing delays between those. This being implemented by the secure element means an OS exploit or tampering with the main SoC/memory cannot bypass it. The feature cannot reduce security due to how it's integrated.

2026-08-22 16:39:23 UTC

- reply

@nprofile…ajc2 If COLDCARD had used the secure elements to get random data, it wouldn't have had the disaster it did. The Linux kernel provides the main CSPRNG on the devices we use and it uses as many randomness sources as it can to feed into the CSPRNG without trusting those sources. It uses cryptographic hashes for this so it doesn't matter if one of the sources is very poor. It generates a ton of the entropy itself via timing jitter, etc.

2026-08-22 02:55:20 UTC

Vanadium version 152.0.7977.54.1 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/152.0.7977.54.1
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/41371-vanadium-version-15207977541-released
#GrapheneOS #privacy #security #browser

2026-08-22 02:29:17 UTC

- reply

@nprofile…mxxt Pixel 'a' series devices get 7 years of updates from launch. Pixel 8a launched in May 2024 so it has updates until at least May 2031. Buying a used 'a' series Pixel can be as cheap as those but comes with proper updates and security protections.
Pixel 8 and later meet our full set of official security requirements including hardware memory tagging and a very good secure element with everything expected. That includes the Pixel 8a. 6th/7th gen Pixels aren't recommended anymore.

2026-08-22 02:04:54 UTC

- reply

@nprofile…mxxt Pixel 10a base price is $499 and it's often on sale for 15% off. It has the same 7 years of support from launch as the flagship devices. Older 'a' series devices are often available very cheaply on sale. It's not currently feasible to provide a competitive budget option with strong security. We'll still have Pixel support and for now those are the budget option via the 'a' series especially by getting used devices.

2026-08-22 02:03:25 UTC

- reply

@nprofile…mxxt Only once those can provide at least 5 years of proper updates, hardware memory tagging, proper secure element integration and the other requirements.
Qualcomm has the best security features and most modern code for the flagship chips. It takes time for it to trickle down to the lower end chips.
Non-Pixel OEMs also typically don't provide updates nearly as frequently or for nearly as much time for the lower end devices which would need to change for us to use those.

2026-08-22 01:48:27 UTC

- reply

Supporting a flip device with vertical folding would be a new form factor for GrapheneOS. The main use case for those is a tiny phone to use with one hand in the folded form factor. The tablet-style folding devices we already support are extremely useful for web browsing, reading, maps, etc.

2026-08-22 01:45:36 UTC

- reply

We do plan to support Motorola's Razr Fold and Razr Ultra (flip) devices in addition to a regular device. We already support the original Pixel Fold (Pixel 7) along with the Pixel 9 Pro Fold and Pixel 10 Pro Fold. We still plan to add support for 11th gen Pixels including the Pixel 11 Pro Fold too.

2026-08-22 01:33:38 UTC

- reply

@nprofile…86nn @nprofile…nqv0 T-Mobile will definitely work fine. We haven't heard of people having issues with this in the US though, only certain countries like Australia and Turkey.

2026-08-22 01:11:02 UTC

- reply

@nprofile…y93v No, you can keep using it until end-of-life. We even plan to support the Pixel 11 devices.

2026-08-22 00:57:30 UTC

- reply

@nprofile…8yyh No, since we need the security improvements in the upcoming devices and will have our hands full supporting those.

2026-08-22 00:56:52 UTC

- reply

@nprofile…86nn Razr Fold (2026) and Razr Ultra (2026) are available in the US so hopefully the next generation ones are too. Motorola Signature (2026) wasn't available in the US but hopefully that changes.

2026-08-22 00:40:21 UTC

- reply

Motorola is doing a large portion of the work of porting GrapheneOS to their devices. They'll provide us with what we need for firmware/drivers in the form we need it and it will be far easier than Pixels. We'll be able to get issues in the firmware and drivers fixed through Motorola and Qualcomm.

2026-08-22 00:38:17 UTC

- reply

Pixels have become much harder to support. Android 16 removed support for Pixels and they became harder to properly support than many other devices rather than easier. It's crucial to keep up with the major OS updates to provide all the security patches and we do but it's much harder for us now.

2026-08-22 00:35:57 UTC

- reply

It's very realistic to provide better security than Pixels against remote attacks. It's far harder to provide a secure element as good as the Titan M2/M3. There will definitely be a decent secure element providing the current generation features including the Android 16 QPR2+ rate limiting design.

2026-08-22 00:33:43 UTC

- reply

These devices will meet or exceed of our official requirements including 7 years of proper updates, starting out with the Linux 6.18 LTS which can be upgraded to a new branch eventually, reset attack protection for firmware boot modes and everything else. There wasn't time to do it all for 2026.

2026-08-22 00:30:26 UTC

- reply

Next generation Snapdragon will have more mature support for MTE and greatly improved secure element support. It's still likely going to be a lot of work to get MTE fully deployed for the kernel and OS. We need all our hardware-based features including our USB-C port protection ported to it too.

2026-08-22 00:28:42 UTC

- reply

Tensor was a sidegrade or downgrade from Snapdragon in many ways. Tensor is paired with the fantastic Titan M2/M3 which was a huge security advantage. It also brought hardware memory tagging (MTE) with the Pixel 8. Snapdragon 8 Elite Gen 5 finally shipped MTE but it's broken on the non-Elite SoC.

2026-08-22 00:26:34 UTC

- reply

Flagship Snapdragon provides much better CPU and GPU performance and provide more of what's needed via isolated components on the SoC. That includes better cellular, Wi-Fi/Bluetooth and GNSS radios with solid security including good isolation. Snapdragon Pixels worked well for us and it will again.

2026-08-22 00:16:06 UTC

Initial focus for our partnership with Motorola is a regular non-folding device. Current generation Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) are very close to meeting our requirements but lack MTE, adequate secure element integration and other features being added for 2027.

2026-08-21 22:11:04 UTC

- reply

@nprofile…sklt ECC memory is rare and expensive. DDR5 has built-in ECC for single bit errors on the memory chips but doesn't cover the rest of the path or protect against bigger errors.
Ryzen 9950X3D supports ECC memory and is essentially the same chip as the EPYC 4585PX. We could use ECC memory with 9950X3D CPUs if we were willing to pay for it.
Hardware is not very reliable in general and not a substitute for testing. If we had more resources we could do every build twice and compare the outputs.

2026-08-21 02:30:20 UTC

- reply

@nprofile…370v What Google is doing is far harder than simply pushing the code. It's also far harder than an automated system for providing it upon request. They're choosing to do this to create harm through delays.
The intended target of that harm is probably not GrapheneOS but rather major companies forking Android. After all, they still provide first class support for alternative operating systems on Pixels at a hardware and firmware level but are making it awful for people to use because of this.

2026-08-21 02:27:35 UTC

- reply

@nprofile…370v Google is one of the largest tech companies in the world. It's an entirely negligible burden on them to quickly comply with these requests. They could have entirely automated it or at least made it automated after the initial request from an email. They chose to make it a manual process with a lot of friction and delays. They chose to go out of their way to go a lot of extra work for this. They have to package up source code this way and manually hand out access to those to people.

2026-08-21 02:26:25 UTC

- reply

@nprofile…370v We didn't say it was the fact they're doing it via Google Drive using Google Forms which makes it a GPL violation. It was stated after bringing up the massive delays and then we elaborated on the situation. We didn't consider it to be a GPL violation until they started taking weeks or more to handle our requests for the sources.
What matters is how things work in 2026 especially for the Android source code. It matters how Google shares it with partners, the impact of delays and more.

2026-08-21 00:22:39 UTC

- reply

@nprofile…370v
> the waiting time of a few weeks should be okay
No, it isn't. It's an artificial delay causing substantial harm through delayed security updates. That means we have to reverse engineer the code to get the patches. We can do that but it results in ongoing damages from Google's violation of the GPL license. They used to push it immediately and now there's a deliberate artificial delay to cause harm. What other reason is there for moving to a manual system with substantial delays?

2026-08-20 20:47:43 UTC

- reply

@nprofile…kc7k Our 9950X3D build has 2x 64GB DDR5 6400MHz. It was purchased for CA$461.99 (US$336.58 at the time) on 2025-06-22. The price is now CA$3,999.99 (US$2,899.91).
Hopefully we can get both the CPU and motherboard replaced under warranty relatively quickly.
It isn't really clear if the motherboard is also dead or physically damaged in addition to the CPU. Probably a good idea to get it replaced but a new one might be just as prone to killing a replacement 9950X3D.

2026-08-20 20:15:06 UTC

- reply

Both the CPU and motherboard should be covered by the warranties from AMD and ASRock. However, it's typically a hassle to get this dealt with and we need another build machine right away. We'll likely buy a new CPU and motherboard. Can upgrade the 5950X machine after the dead parts are replaced.

2026-08-20 20:09:04 UTC

- reply

We've had a lot of memory issues with the older AM5 7950X machine including it not working with high capacity DIMMs. i9-13900K machine had performance crippled by the updates stopping it bricking itself. The oldest 5950X machine predating DDR5 is the only one which hasn't had any significant issues.

2026-08-20 19:47:44 UTC

Most recently assembled of the 4 workstations used to build official GrapheneOS releases died today. 9950X3D CPU was likely killed by the ASRock B850 Pro RS motherboard. Many other ASRock customers with AM5 boards and X3D CPUs have experienced it. We were concerned about this so we didn't use PBO2.

2026-08-20 14:44:39 UTC

- reply

@nprofile…8q2x @nprofile…6saw It's highly unlikely these devices were running GrapheneOS. It's likely the devices were purchased from a company selling phony hardened devices to criminals. Those devices are often marketed as using GrapheneOS including devices sold by ANOM which was an FBI operation. A device being marketed as either using GrapheneOS or being based on it doesn't mean it's true. Conflating products not running GrapheneOS with GrapheneOS is common.
https://nitter.net/GrapheneOS/status/2090436537783644455

2026-08-20 14:41:49 UTC

- reply

@nprofile…8q2x @nprofile…6saw It's highly unlikely these devices were running GrapheneOS. It's likely the devices were purchased from a company selling phony hardened devices to criminals. Those devices are often marketed as using GrapheneOS including the devices sold by ANOM which was an FBI operation. A device being marketed as using GrapheneOS or being based on it doesn't mean that's true. That was the main basis for false claims about GrapheneOS in France.
https://nitter.net/GrapheneOS/status/2090436537783644455

2026-08-20 14:38:34 UTC

- reply

@nprofile…8q2x @nprofile…6saw https://nitter.net/GrapheneOS/status/2090436537783644455

2026-08-20 03:25:13 UTC

Vanadium version 152.0.7977.54.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/152.0.7977.54.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/41312-vanadium-version-15207977540-released
#GrapheneOS #privacy #security #browser

2026-08-20 02:09:33 UTC

- reply

@nprofile…vkrd The Hacker News thread is based on us answering someone's question in a reply but we've provided the same information many times before through Mastodon and other platforms. It isn't really news that the devices will be in 2027. We've been saying late 2026 to before the end of 2027. We moved to saying 2027 many months ago after determining it would be the next generation of devices meeting our requirements rather than the current one.

2026-08-20 02:05:33 UTC

- reply

@nprofile…hd7u It's not about AOSP and has no impact on our partnership with Motorola.

2026-08-19 03:48:35 UTC

- reply

@nprofile…seap @nprofile…vtea Never said you were doing it. It's /e/ and Murena themselves doing that, not you.

2026-08-19 03:22:52 UTC

- reply

@nprofile…seap @nprofile…vtea /e/ and Murena repeatedly claim privacy/security hardened devices are mainly for criminals and pedophiles. They've also been falsely claiming GrapheneOS is mainly used by criminals for years alongside misleading people about what it provides. That's why we began providing our perspective in response. Fairphone gave a weasel worded media statement supporting Murena in this and other involvement.
https://nitter.net/GrapheneOS/status/2040887784253141142
https://www.clubic.com/actualite-604786-murena-e-os-interview.html
https://nitter.net/GrapheneOS/status/2081837057433915603

2026-08-19 03:12:54 UTC

- reply

@nprofile…seap @nprofile…vtea It has fewer Google apps and services but it still comes with many default enabled Google services. It has those baked into the OS with highly privileged access. It gives that privileged access to Google Play executables which are downloaded by default too. It quietly gives it to apps such as Android Auto to make those work.
Using a device far behind on standard privacy patches and protections leaves you far more vulnerable to invasive behavior by apps, not less.

2026-08-19 03:09:56 UTC

- reply

@nprofile…seap @nprofile…vtea
> Fairphone's mission is important to me
There's a severe lack of evidence for the working conditions and supply chain of T2Mobile being better.
Their devices lacking proper updates means they aren't sustainable. We do know Fairphone's marketing claims on updates, privacy and security do not check out.
> corporations are not sucking all the data out of my phone unlike if it was on standard Android
It has far weaker privacy from apps than AOSP or the stock Pixel OS.

2026-08-18 23:35:45 UTC

- reply

@nprofile…etys @nprofile…70hf
https://grapheneos.social/@GrapheneOS/117119132068170702

2026-08-18 23:35:31 UTC

- reply

@nprofile…vtea
GrapheneOS will never run on any of the existing Fairphones because none of those are reasonably secure devices.
Fairphones have atrocious updates including drivers and firmware we would have to use. Fairphones lack very important hardware-based security features. They're very far from meeting our requirements.
You shouldn't buy a Fairphone if privacy and security are priorities. There's no way to use their devices with important standard privacy/security patches and protections.

2026-08-17 06:16:15 UTC

Vanadium version 152.0.7977.42.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/152.0.7977.42.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/41236-vanadium-version-15207977420-released
#GrapheneOS #privacy #security #browser

2026-08-16 17:55:13 UTC

GmsCompatConfig version 173 released:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-173
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/41221-gmscompatconfig-version-173-released
#GrapheneOS #privacy #security #gmscompat

2026-08-14 20:58:25 UTC

- reply

@nprofile…9vyn /e/ has highly privileged support for Google services built into the OS. It even downloads and runs Google Play executables with privileged access automatically.
That's not very important compared to /e/ being incredibly far behind on standard privacy and security patches. It's missing many High and Critical severity patches from Pixel Update Bulletins and far more. It lags months and even years behind on patches.
See our response at https://nitter.net/GrapheneOS/status/2081837057433915603 for much more info.

2026-08-14 18:57:01 UTC

- reply

@nprofile…5swn Try without MTE (which is opt-in for user installed apps) but with hardened_malloc still enabled (enabled by default) before trying disabling hardened_malloc.

2026-08-14 18:56:51 UTC

- reply

@nprofile…5swn Try without MTE (which is opt-in for user installed apps) but with hardened_malloc still enabled (enabled by default).

2026-08-14 03:57:23 UTC

- reply

@nprofile…5swn No, it's working fine. It may have memory corruption bugs requiring not using hardware memory tagging or similar issues with hardened_malloc. Those are upstream WhatsApp bugs and should show clear crash reports for MTE.

2026-08-14 03:56:49 UTC

- reply

@nprofile…5swn No, it's working fine.

2026-08-14 03:07:16 UTC

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

2026-08-14 02:33:34 UTC

- reply

@nprofile…5swn Exploiting the hardened secure element to bypass the time-based rate limiting and maximum limit of 20 attempts. It could be via a firmware exploit or a very sophisticated physical attack. However, the latest generation secure element for the Pixel 11 could have the hard limit done in a more directly hardware enforced way so only a very sophisticated physical attack would work.

2026-08-14 02:33:11 UTC

- reply

@nprofile…5swn Exploiting the hardened secure element to bypass the time-based rate limiting and maximum limit of 20 attempts. It could be via a firmware exploit or a physical attack. However, the latest generation secure element for the Pixel 11 could have the hard limit done in a more directly hardware enforced way so only a hardware exploit would work.

2026-08-13 17:26:46 UTC

- reply

@nprofile…5swn We recommend using a randomly generated 6 digi PIN as the minimum secure lock method. This fully depends on the secure element rate limiting for security. The rate limiting is aggressive enough that a randomly generated 4 digit PIN is also secure due to only permitting a total of 20 attempts.
If you want to avoid depends on the hardware security features which could be bypassed by a very sophisticated attacks,, then you need a strong passphrase such as 6-8 diceware words.

2026-08-13 05:56:59 UTC

- reply

@nprofile…u5vp We're talking about the Bluetooth accessories being old, not the phone. Pixel 8a is fully supported and is one of the recommended devices.

2026-08-13 05:38:07 UTC

- reply

@nprofile…xrf2 Apps requiring Google Play services SMS verification currently require granting a permission for it to Play services via ADB since we don't have a UI toggle for it:
adb shell appops set com.google.android.gms READ_OTP_SMS allow
We need to come up with an approach to support it without this.

2026-08-12 21:49:02 UTC

- reply

@nprofile…halg Did you install the app from the sandboxed Play Store?
Does GrapheneOS show a Play Integrity API notification for the app?

2026-08-12 15:32:08 UTC

- reply

@nprofile…halg Try the per-app exploit protection compatibility mode.

2026-08-12 02:29:29 UTC

Vanadium version 151.0.7922.137.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/151.0.7922.137.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/41114-vanadium-version-151079221370-released
#GrapheneOS #privacy #security #browser

2026-08-11 23:28:32 UTC

- reply

USB vulnerabilities are widely exploited. It's used against journalists, activists, dissidents and others at border crossings, protests and elsewhere. Android 16+ has opt-in protection but it's far weaker than our default and blocks installing apps from outside the Play Store.

2026-08-11 23:27:38 UTC

- reply

USB vulnerabilities are widely exploited. It's routinely done against journalists, activists, dissidents and others at border crossings, protests and elsewhere. Android 16+ has opt-in protection but it's much weaker than our default and tied to blocking installing apps from outside the Play Store...

2026-08-11 23:22:58 UTC

- reply

USB vulnerabilities are being widely exploited. It's done as a routine thing against journalists, activists, dissidents and others at border crossings, protests and elsewhere. Android and iOS have obscure opt-in settings to block most of the attack vector. We have better protection on by default.

2026-08-11 23:22:31 UTC

- reply

@nprofile…ulnl You can see many of the replies at https://nitter.net/linuxuser1996/status/2086757738055389637. We wrote several responses and copy-pasted those to dozens of the replies. Most of the people who replied said they have the feature on their standard Android device when they don't. They believe the standard Android USB menu is the same thing when it isn't at all. Android Advanced Protection Mode added in Android 16 is similar to the software part of our feature but not as good and it's missing the hardware-level blocking.

2026-08-11 23:22:15 UTC

- reply

@nprofile…ulnl You can see many of the replies at https://nitter.net/linuxuser1996/status/2086757738055389637. We wrote several responses and copy-pasted those to dozens of the replies. Most of the people who replied said they have the feature on their standard Android device when they don't. They believe the standard Android USB menu is the same thing when it isn't at all. Android Advanced Protection Mode in Android 16 is similar to the software part of our feature but not quite as good and it's missing the hardware-level blocking.

2026-08-11 23:19:57 UTC

- reply

@nprofile…4qru @nprofile…3w94 Setting it to Off disables USB including charging in the regular OS boot mode.
It will still charge in the special OS boot modes: charging, recovery, fastbootd and rescue. Charging mode is what boots when you plug the device into a charger while it's turned off and shows the battery percentage on the screen.
It can also still charge while powered off and in the firmware boot modes: fastboot mode and boot ROM recovery mode.
It can't brick the device.

2026-08-11 23:13:50 UTC

- reply

@nprofile…ulnl Yes, it has all of the USB peripheral functionality enabled. You can also plug in a display and it will connect to it, although current Android will prompt before mirroring the screen to it.
Android's main USB menu only controls the USB gadget mode and has nothing to do with the device Android is running on using USB peripherals itself. iOS works similarly.
Many users misunderstand Android's standard approach.
See the replies to https://x.com/linuxuser1996/status/2086757738055389637 for why we posted this thread.

2026-08-11 23:03:38 UTC

- reply

GrapheneOS blocks new USB connections while locked by default at both a software and hardware level. It can be enabled while unlocked too. It can even be set to fully disable USB while booted including USB-PD and other charging functionality. More info:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control

2026-08-11 22:59:50 UTC

- reply

Standard Android USB charging-only mode does not block new USB connections. It only means the device Android is running on isn't acting as a USB peripheral such as a webcam, MTP or MIDI device itself. USB debugging is another of those gadget modes which can be on simultaneously.

2026-08-11 22:59:39 UTC

- reply

Android 16 added Android Advanced Protection Mode which can be used to toggle on multiple extra security features. It blocks new USB connections at a kernel level while the device is locked. Our approach also blocks new USB connections at a hardware level and disables USB data.

2026-08-11 22:59:33 UTC

- reply

They have their tool pretend to be a certain USB peripheral to target specific Linux USB drivers. These exploits are widely used including against journalists and political activists. Here's a technical article about a specific case of this in Serbia:
https://securitylab.amnesty.org/latest/2025/02/cellebrite-zero-day-exploit-used-to-target-phone-of-serbian-student-activist/

2026-08-11 22:59:15 UTC

- reply

Exploiting Linux kernel USB vulnerabilities is how exploit tools from Cellebrite and other companies extract data from Android devices in practice. They also exploit firmware bugs in other boot modes but we convinced Google to eliminate most of that attack surface for Pixels.

2026-08-11 22:59:07 UTC

- reply

Android's standard USB menu being set to charging-only means the device has MTP enabled with file transfer disabled. It always has USB data and USB peripherals enabled. GrapheneOS USB-C port charging-only means USB data is disabled in hardware and kernel USB drivers are disabled.

2026-08-11 22:58:50 UTC

Android has USB data and a large number of USB drivers available including while locked. Plug in a mouse, keyboard, external drive or other USB accessory and you'll see that's the case. When Android says charging-only, it means not allowing file transfer.

2026-08-09 18:39:32 UTC

- reply

@nprofile…pgkx Misusing the term ROM for the OS directly contributes to many commonly held misconceptions and misunderstandings.
It contributes to people wrongly believing GrapheneOS is a modification of the stock OS, believing it's flashed to special storage rather than written out to the SSD and much more.
It also causes confusion when talking about verified boot and recovery procedures.
Deliberately misusing the term within the context of GrapheneOS to be contrarian is a form of trolling.

2026-08-09 18:34:49 UTC

- reply

@nprofile…pgkx GrapheneOS is an operating system stored on writable SSD partitions.
GrapheneOS runs on devices with an SoC boot ROM. The boot ROM loads, verifies and runs the firmware for the next boot stage from the SSD.
There's a ROM recovery mode which is entered if the SSD firmware can't be loaded from the SSD. Incorrect or unsafe use of fastboot commands resulting in lack of usable firmware on the SSD will cause fallback to the ROM recovery mode. That's not the GrapheneOS recovery mode.

2026-08-08 21:03:59 UTC

- reply

@nprofile…pgkx GrapheneOS is an operating system stored on writable SSD partitions.
An SoC boot ROM loads the main SoC boot firmware from the SSD and then the final stage of that firmware loads GrapheneOS. There's a ROM recovery mode which loads if the SSD firmware can't be loaded from the SSD. The boot ROM including the ROM recovery mode is a ROM. The firmware and the OS on the SSD aren't ROMs.
There are various other ROMs for other components beyond the SoC boot ROM too.

2026-08-08 15:14:36 UTC

- reply

@nprofile…sxvf They started doing this for Pixel kernel drivers after the initial release of Android 16.

2026-08-08 04:43:35 UTC

- reply

GrapheneOS shipped every single one of the patches they falsely claim were missed. We quickly moved to each new stable release of AOSP as the new base for the OS. Every patch included in AOSP or the stock Pixel OS was quickly included in GrapheneOS. We also included many patches they did not ship.

2026-08-08 04:30:09 UTC

- reply

The paper has a table listing the patches they're inaccurately claiming are missing in GrapheneOS. They claim the ones marked as green were manually verified to be missing. The first patch listed in the table is CVE-2015-6609, which we reported to Google in 2015.
https://source.android.com/docs/security/bulletin/2015-11-01#acknowledgements

2026-08-08 02:53:18 UTC

- reply

@nprofile…06pu It's incredibly backwards and very hard to understand why they want to drive away people from using their devices.
Nexus and Pixel devices had a lot of Android enthusiasts using them who are increasingly being driven away by these decisions.
They're driving a lot of people away to using iPhones rather than simply using other Android devices.
The management making these decisions largely use iPhones, not the products they're gradually stripping of thei actual advantages.

2026-08-08 01:42:15 UTC

- reply

@nprofile…vwy6 We're probably just going to host them as Git repositories without a whole social coding platform. If we want to take pull requests ourselves without GitHub then we could host Gerrit ourselves.

2026-08-08 01:31:38 UTC

- reply

For Motorola devices, we plan to prepare our releases early and have everything ready for major Android updates at launch. We should be able to simply push the code to our own repositories for major Android releases. We'll need to host all the AOSP Git repositories ourselves.

2026-08-08 01:16:58 UTC

- reply

They're obligated to fulfill our requests. We need each of the Beta tags because we port and test in advance. If they don't want to deal with our endless requests for each release, they can simply push the tags to Git. They chose to waste the time of several employees on this.

2026-08-08 01:13:54 UTC

- reply

If they insist on using Google Drive, they could at least automate giving access. It shouldn't depend on a person going through a huge backlog as a low priority. Requests not being handled for weeks is unacceptable. They could simply push the Git tags and stop dealing with it.

2026-08-08 01:04:37 UTC

- reply

Google could simply push signed tags to Git instead of having a person assigned to go through form submissions and give access to specific files. They could also give access to folders instead of files to avoid needing to give us access to more files multiple times a month.

2026-08-08 01:00:01 UTC

- reply

These changes won't negatively impact GrapheneOS on upcoming Motorola Mobility devices. In fact, it's a major part of why our partnership exists. It only negatively impacts Pixels and hurts Google more than anyone else. Google wants to make Pixels worse for no apparent reason.

2026-08-08 00:51:56 UTC

- reply

Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us. They're the ones who chose to use this archaic system instead of pushing Git tags and it's their responsibility to handle requests promptly.

2026-08-08 00:45:33 UTC

- reply

Prior to moving it to Google Drive, they started squashing the history into a single commit prior to pushing release tags. The tarballs provided via Google Drive have exactly the same source code. However, they went out of the way to make it more inconvenient in several ways.

2026-08-08 00:39:53 UTC

Google replaced pushing Git tags for certain source code with obtaining source code via Google Drive after making a request through Google Forms. It's completely ridiculous and they've gradually become very slow at handling requests. They're in clear violation of the GPLv2 now.

2026-08-08 00:38:10 UTC

Google replaced pushing Git tags for certain source code with obtaining source code via Google Docs after making a request through Google Forms. It's completely ridiculous and they've gradually become very slow at handling requests. They're in clear violation of the GPLv2 now.

2026-08-06 23:40:14 UTC

Vanadium version 151.0.7922.108.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/151.0.7922.108.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/40986-vanadium-version-151079221080-released
#GrapheneOS #privacy #security #browser

2026-08-06 12:05:51 UTC

- reply

@nprofile…3w94 Device and strong integrity won't pass since those require a Google certified OS. The difference between device and strong is mainly that strong always requires hardware attestation while device has loopholes permitting not having it. Strong is also the only tier with any form of security patch level check, but it only checks it for Android 13+ and permits a security patch that's up to a year out-of-date.