<unnamed>

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhkg6t5w3hjuur4vghhyetvv9uszrthwden5te0dehhxtnvdakq4txtpg

Publishing to

ditto.pub/relay

nos.lol

relay.ditto.pub

relay.braydon.com/ember-charlie

relay.mostr.pub

relay.mostr.pub/%20

Last Notes

2026-09-06 20:35:10 CEST

We're well into the process of rewriting the Messaging app included in GrapheneOS into a modern app. We'll be making a new release of it later today with a completely overhauled user interface written in Android Compose. We've made a massive amount of other improvements and bug fixes to the app too.

2026-09-06 09:36:42 CEST

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

2026-09-05 08:46:34 CEST

GrapheneOS is partnered with Motorola Mobility which is Lenovo's mobile division.
In 2011, Motorola was split into Motorola Mobility and Motorola Solutions. Google acquired Motorola Mobility in 2012 and sold it to Lenovo in 2014. Motorola Mobility is the company selling smartphones and tablets.

2026-09-05 08:26:31 CEST

Vanadium version 152.0.7977.84.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/152.0.7977.84.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/41725-vanadium-version-15207977840-released
#GrapheneOS #privacy #security #browser

2026-09-03 20:20:17 CEST

We're aware of claims spread on German social media about GrapheneOS being exploited. We looked into it in case there was substance behind it. OS and hardware security isn't actually much of a factor in the story. Instead, the central claim is disk encryption with a strong passphrase can be cracked.

2026-09-03 08:20:43 CEST

Our replacement 9950X3D from AMD arrived today and is working well. RMA process took a bit under 2 weeks. It was sent back on the same day they provided a prepaid shipping label. It's a common issue with Ryzen 9000 X3D chips and they simply accepted it without questions.
https://grapheneos.social/@GrapheneOS/117129561025135382

2026-09-01 06:57:14 CEST

We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.

2026-08-30 21:48:18 CEST

Near the end of May 2026, Russia began filtering access to DataPacket IP space with an enforced domain allowlist for HTTP and TLS SNI. GrapheneOS services aren't on the allowlist so we had to switch from DataPacket Frankfurt to Amsterdam Cherry Servers for Russia. That's now getting filtered too.

2026-08-29 16:19:30 CEST

We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.

2026-08-23 20:59:18 CEST

- 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 18:07:32 CEST

- reply

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

2026-08-22 19:49:01 CEST

- 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 19:00:26 CEST

- 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 18:58:53 CEST

- 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 18:51:17 CEST

- 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 18:50:26 CEST

- 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 18:45:52 CEST

- 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 18:40:48 CEST

- reply

@nprofile…ajc2 The Linux kernel feeds in more entropy over time and doesn't stop. It's only during very early boot where miscalculating how much actual entropy was added can cause issues. By the time people get to the lockscreen, a massive amount of entropy has been generated. In practice it's only the early boot kASLR base, ASLR bases, stack canaries, heap canaries, etc. which could be poor. The firmware gives an early random seed though.

2026-08-22 18:39:23 CEST

- 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 04:55:20 CEST

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 04:04:54 CEST

- 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 04:03:25 CEST

- 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 02:40:21 CEST

- 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 02:38:17 CEST

- 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 02:35:57 CEST

- 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 02:16:06 CEST

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 04:27:35 CEST

- 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:22:39 CEST

- 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 22:47:43 CEST

- 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 22:09:04 CEST

- 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 21:47:44 CEST

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 16:44:39 CEST

- 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 16:38:34 CEST

- reply

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

2026-08-20 05:25:13 CEST

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-19 01:35:45 CEST

- reply

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

2026-08-16 19:55:13 CEST

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:57:01 CEST

- 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 05:57:23 CEST

- 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-12 23:49:02 CEST

- 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 04:29:29 CEST

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-12 01:11:34 CEST

- reply

@nprofile…3w94 Yes, wireless charging still works with the USB-C port mode set to Off. Setting it to charging-only provides most of the security value but we decided to offer the ability to fully disable it in case there are ever USB-PD vulnerabilities in the USB controller. USB-PD is a secondary form of limited data which could be used to exploit the USB controller itself, turn on USB data and then reach the remaining attack surface for USB in the kernel despite drivers being off.

2026-08-12 00:59:50 CEST

- 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-12 00:59:07 CEST

- 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-09 20:34:49 CEST

- 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 17:14:36 CEST

- reply

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

2026-08-08 06:43:35 CEST

- 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 03:13:54 CEST

- 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 03:00:01 CEST

- 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 02:39:53 CEST

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-07 01:40:14 CEST

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 14:05:51 CEST

- 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.

2026-08-06 13:36:49 CEST

- reply

@nprofile…3w94
> the unfortunate part is I can't download it from play store anymore at all
Do you pass the Play Integrity API basic integrity level? You can run one of the Play Integrity API checker apps to test this. We're getting inconsistent reports on whether people can install Revolut and sign into it. Some users are still able to do it while others can't. It's unclear exactly what they've changed which results in more people having issues installing it or logging in.

2026-08-06 13:35:14 CEST

- reply

@nprofile…3c0l GrapheneOS is neither security theatre or a honeypot. Your claims are completely unsubstantiated nonsense.

2026-08-06 10:16:07 CEST

- reply

@nprofile…x6d7 GrapheneOS isn't negatively impacted by the warning you're talking about and it doesn't change GMS Android in the way many have portrayed it.
You'll be giving up having privacy and security with a dumb phone. It lacks encrypted calls or texts. They also typically have awful security without basic patches and protections. It fully depends on cellular too.
How does that help with this app banning anything but iOS or GMS Android?

2026-08-06 10:13:00 CEST

Vanadium version 151.0.7922.83.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/151.0.7922.83.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/40971-vanadium-version-15107922830-released
#GrapheneOS #privacy #security #browser

2026-08-06 04:38:49 CEST

- reply

Revolut specifically tries to detect and ban GrapheneOS. It has checks for the build user/value values we set for deterministic builds so we had to change those. They also ban yellow verified boot state (locked with non-stock key) but not orange (unlocked) which we worked around.

2026-08-06 04:02:00 CEST

- reply

This likely still works for most users:
1) Log into a throwaway Google account so basic integrity passes.
2) Install Revolut via the sandboxed Play Store so the installer check passes.
We'll be shipping a secure solution fixing apps with an installer check in the near future.

2026-08-06 03:48:49 CEST

- reply

We worked around Revolut's blocking of GrapheneOS in January 2025 and got it working for everyone. However, it's still fully their intention to ban GrapheneOS and we've started seeing reports of users having issues logging in. It still consistently works when already logged in.

2026-08-06 02:48:07 CEST

- reply

If Revolut insists on doing a verification of the hardware, OS and app then they can use the hardware attestation API to verify GrapheneOS devices. They've received links to https://grapheneos.org/articles/attestation-compatibility-guide for years prior to their recent ban of GrapheneOS. They have no excuse to ban it.

2026-08-06 02:39:02 CEST

- reply

GrapheneOS is far more secure than the most secure Android devices they permit. The security standards Revolut claims to be upholding are non-existent. The least secure devices they allow are outrageously bad. They go out of the way to support devices without updates for 8 years.

2026-08-06 02:07:57 CEST

- reply

Revolut is incredibly negligent when it comes to security. It includes a bunch of closed source third party libraries with privacy, security and compatibility issues. Several of these libraries supposedly exist to protect security but in fact create serious security weaknesses.

2026-08-06 02:01:46 CEST

Revolut recently banned using GrapheneOS without any justification. They're falsely claiming to do be doing it for security reasons. In reality, they're enforcing licensing Google Play. Revolut doesn't enforce security standards. It runs on Android 9 with no patches since 2018.

2026-08-05 21:45:11 CEST

- reply

@nprofile…lqhl
> Is Seedvault still the way to backup GrapheneOS?
It's how you should back up most app data and contacts. You may want to back up the home directory in a more efficient way but it does work for that too.
> If so, is Seedvault still hit or miss?
It's missing many features we want and has a poorly designed user interface and experience but it works fine. It uses the device-to-device transfer mode which Google uses for their switching phone feature. It includes most app data.

2026-08-05 05:02:15 CEST

- reply

@nprofile…nymm GrapheneOS passes basic integrity but isn't Google certified so device and strong won't pass. Around 10% of banking apps check for device integrity.
A growing number of banking apps are explicitly permitting GrapheneOS via hardware attestation as an alternative to the Play Integrity API. That means services checking for the Play Integrity API device integrity level doesn't imply those won't work on GrapheneOS.
It's very strange this photo sharing service checks the Play Integrity API.

2026-08-04 07:18:48 CEST

- reply

@nprofile…rtl5 @nprofile…pkaf @nprofile…ulnl We don't keep support for end-of-life devices very long since it's not possible to provide a reasonable level of security. We tend to do it for a while mainly so we can inform people about it via a notification at boot. At a certain point, we're doing more harm than good.
It's quite doable to port a device to new major Android system image versions now due to Treble. However, it likely does more harm than good to do it without patches for what's underneath.

2026-08-04 07:13:09 CEST

- reply

@nprofile…rtl5 @nprofile…pkaf @nprofile…ulnl LineageOS won't provide those hardware-related patches. It has a significantly weakened security models and delayed patches even on a supported Pixel. That makes little difference on a Pixel 3a since the userspace AOSP patches don't matter more than the missing kernel patches. It has an end-of-life Linux kernel with barely anything backported.
It would still have remotely exploitable radio vulnerabilities even with Linux 6.18 with full rewrites of the drivers.

2026-08-04 07:10:15 CEST

- reply

@nprofile…rtl5 @nprofile…pkaf @nprofile…ulnl It has gone over 4 years without updates the firmware, kernel, drivers and HALs. That includes many critical vulnerabilities usable to take over the device remotely or from an app. It's also essentially not going to have working encryption in After First Unlock state. The secure element wasn't as hardened and is known to have been exploited by commercial exploit vendors but encryption would work with a strong passphrase when at rest. It's not a good situation.

2026-08-04 01:53:41 CEST

- reply

@nprofile…jc4r We're partnered with Motorola Mobility which is a wholly owned subsidiary of Lenovo. It's an entirely separate company from Motorola Solutions.
Those haven't been part of the same company since all the way back in 2011 when they were split apart. Motorola Mobility was subsequently acquired by Google in 2012 and sold to Lenovo in 2014.

2026-08-04 01:47:21 CEST

- reply

@nprofile…jc4r It isn't possible to provide GrapheneOS in the form of a GSI. GrapheneOS has core privacy and security protections requiring kernel and driver changes. The project you linked doesn't include the kernel hardening, USB protection, hardened_malloc, MTE, various userspace features depending on kernel changes, verified boot and other unlisted features. Various other features were disabled by default. Many features only partially work. GrapheneOS is based on AOSP 17 but this isn't yet.

2026-08-04 01:28:21 CEST

- reply

@nprofile…rtl5 @nprofile…pkaf @nprofile…ulnl It happens very late in the boot process after the boot is considered successful. It can complete before unlocking but it's common to have time to unlock before it finishes. It's asynchronous and doesn't block the booting process.
The OS disables automatic rollback prior to updating the anti-rollback values for both the OS and the firmware. For the firmware, it triggers updating fuses to the current value in the firmware rather than a specific hard-wired value.

2026-08-03 23:35:40 CEST

- reply

@nprofile…rtl5 @nprofile…pkaf @nprofile…ulnl We've seen a lot of hardware failures. It can be hard to tell if it's a hardware failure initially especially since it's a pain for people to test a factory reset or flashing the stock Pixel OS again. We end up learning which kinds of tracebacks from the Bluetooth stack, Linux kernel, etc. are caused by hardware failures and can quickly identify a lot of them. If it's a frequent issue then people can usually confirm by flashing stock. We deal with it regularly.

2026-08-03 23:29:53 CEST

- reply

@nprofile…rtl5 @nprofile…pkaf @nprofile…ulnl No, since fastboot mode is provided by the littlekernel-based bootloader loaded by the SSD. If the current boot slot bootloader is broken and the device isn't in a post-update mode where it automatically rolls back to the other slot then the device is bricked. This can't generally happen when the device is locked. An unlocked device is a lot less reliable even without using fastboot mode directly. Verified boot helps it avoid getting bricked in multiple ways.

2026-07-31 20:57:39 CEST

- reply

@nprofile…7xqy We'd like to have support for recent tablets but there are none available with what we need. It's likely we'll be able to support a future Motorola Mobility tablet but isn't currently part of what we're working on with them as part of our partnership.
We can't recommend buying a Pixel Tablet at this point due to how far it is into the support lifetime:
https://grapheneos.org/faq#device-lifetime
https://grapheneos.org/faq#recommended-devices
The folding devices are very nice to use but very expensive too.

2026-07-31 01:46:24 CEST

GrapheneOS Camera app version 91 released:
https://github.com/GrapheneOS/Camera/releases/tag/91
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/40836-grapheneos-camera-app-version-91-released
#GrapheneOS #privacy #security #camera #android

2026-07-30 07:51:51 CEST

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

2026-07-30 00:16:49 CEST

- reply

@nprofile…2w6z
> everyone's threat model is different
The context of the proposals is border security with access to forensics software.
> could do the trick for victims of domestic violence
Easy to notice it's running GrapheneOS. Features GrapheneOS provides will be widely known and discussed.
> against muggers who demand that you unlock your phone
People can choose to heavily use Private Spaces which are a very good feature themselves. Android already has a dubious feature for poorly hiding it.

2026-07-29 23:27:33 CEST

- reply

Exploiting the OS becomes drastically easier after being granted access to a profile. USB becomes available, every radio can be turned on and an app can be installed with every permission granted. Developer options and ADB would need to be available to pretend to be Owner...

2026-07-26 14:27:17 CEST

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android has worked with mainline kernels for years. Mainline Linux kernel drivers with proper functionality are drivers Android can use too. Any efforts to improve the upstream Linux kernel directly benefit Android since it's a Linux distribution itself. Android devices now regularly move to new LTS branches throughout their lifetime. Pixel 7 moved from the 5.10 LTS to 6.1 and now to 6.12. Android benefits from upstream improvements to Linux.

2026-07-26 06:53:43 CEST

- reply

@nprofile…v6g6 @nprofile…3kzl Java and Kotlin are used as systems programming languages on Android. That doesn't exclude garbage collected languages. It's how they're used.
Android supports ahead-of-time (AOT) compilation for Java and Kotlin in addition to JIT. It uses AOT for core OS code written in it as part of OS builds. GrapheneOS extends the use of AOT compilation.
ART uses generational concurrent GC making dynamic allocation fast, defragmenting the heap and avoiding stop the world pauses.

2026-07-26 06:27:48 CEST

- reply

@nprofile…ecjg @nprofile…c8pt @nprofile…ppje @nprofile…dey5 That's completely untrue. Android works with a mainline kernel since many years ago. Every kernel feature it requires was landed upstream or replaced with upstream features. A bunch of code was ported to eBPF to avoid needing downstream changes.
Android uses a very minimal kernel configuration, extensive attack surface reduction and many kernel hardening features because it provides reasonable security, unlike those desktop operating systems.

2026-07-25 20:30:19 CEST

- reply

@nprofile…glgc @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android is objectively Linux. Linus Torvalds, Greg KH and other core members of the Linux project regularly confirm Android is Linux.
Android is Linux and has been called Linux since long before the products you're claiming have exclusive rights to the term Linux Phone existed.
Linux doesn't mean systemd, GNU and XDG desktop standards. It doesn't mean using GNOME or KDE. Server and embedded Linux is Linux, as is another kind of desktop userspace.

2026-07-25 01:11:55 CEST

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android also works fine with a mainline kernel.

2026-07-25 00:36:54 CEST

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 The claim that it is because of lack of effort to upstream code is completely false. It's due to the official policies, unofficial policies and politics of the kernel that it has failed to end up with working or complete drivers for most mobile hardware. It's a major problem for desktops and laptops too. The system isn't working well and that's a Linux kernel problem that's not specific to Android which works with mainline.

2026-07-25 00:12:10 CEST

- reply

@nprofile…x48d There was a constructive discussion there and our posts were useful, factual information addressing misconceptions people have about GrapheneOS. We regularly boost things we put effort into writing because we don't want the effort going to waste buried in threads hardly anyone will see. What we said is plainly true and innocuous. It's not something which cause people to pile on with bad faith arguments and abuse towards us. It's totally uncalled for in response to what we said.

2026-07-24 23:42:18 CEST

- reply

@nprofile…x48d Their claims about GrapheneOS are objectively inaccurate, not logical and often harm our project. We were responding in a thread where we were explicitly mentioned with our handle to correct misconceptions. We didn't respond to the original post in the thread but rather we responded to a sub-thread where GrapheneOS was being discussed.
Multiple people were abusive towards us due to disagreeing with us about GrapheneOS being Linux, which it clearly is. We weren't the unkind ones.

2026-07-24 23:39:31 CEST

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 The Pixel drivers are in separate repositories using the GKI permitted subset of the kernel API. It would be straightforward to port them into the kernel tree and remove the GKI infrastructure but that exists to make porting them easier by reducing how tied they are to the kernel tree. Pixels always build the drivers with their latest kernel tree so GKI is pointless for them and we'd rather not have it. It wasn't made for Pixels.

2026-07-24 23:37:18 CEST

- reply

@nprofile…75s8 @nprofile…gun3 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android can already be built with 6.18 or a mainline kernel. It doesn't require downstream changes to the kernel.
Hardware support is a separate thing not specific to Android. Pixels have public Linux 6.12 support in Beta.
Android has a GKI branch for 6.18 already and it wouldn't be a large amount of work to switch out 6.12 with 6.18 and adjust the Pixel drivers to work for it. They're not part of the kernel tree itself.

2026-07-24 23:31:55 CEST

- reply

@nprofile…29v2 @nprofile…c8pt @nprofile…dey5 We don't. PostmarketOS uses systemd with musl.

2026-07-24 23:31:16 CEST

- reply

@nprofile…gun3 @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Using Linux to exclusively refer to an OS using glibc, systemd and XDG desktop software isn't something we've seen people doing or insisting on. It likely isn't how you use the term Linux yourself. You probably consider Alpine Linux to be Linux along with many server and embedded distributions. Those use various different init, libc, shells, CLI utilities and other software. What's the logic of those all being Linux but AOSP is arbitrarily not Linux?

2026-07-24 23:18:58 CEST

- reply

@nprofile…gun3 @nprofile…c8pt @nprofile…ppje @nprofile…dey5 KDE Plasma is built to run as part of a far different userspace. It's not relevant to whether GrapheneOS is a Linux distribution. Linux isn't glibc, systemd, Wayland, PipeWire and KDE. It isn't the XDG desktop standards. Linux is a kernel and Linux distributions are the operating systems using it as a kernel.
Android apps are Linux apps. You can't easily run those without using AOSP. It's the same thing the other way around. Both are still Linux.

2026-07-24 23:00:49 CEST

- reply

@nprofile…x48d You weren't blocked for your off topic hostile replies but that reply crossed the line.
Further context for it is that GrapheneOS has been targeted with relentless harassment and libel towards our team for years. It's common to target our team members baselessly claiming we're insane, delusional and schizophrenic. Your own replies make it clear you're aware of the years of attacks on our team and why we'd have an issue with your reply even without the direct context you made it in.

2026-07-24 22:58:42 CEST

- reply

@nprofile…x48d Your post was made in the context of supporting the person who made the posts linked above. All of this was done in the context of relentless harassment and libel towards our team for many years including from Kiwi Farms and their supporters. You showed up in the thread t derail it with completely non-sequitur reply not having any relation to it with disingenuous arguments. You doubled down on it. You did it in support of the attacks by the person who was making personal attacks.

2026-07-24 22:15:31 CEST

- reply

@nprofile…z4st @nprofile…dey5 @nprofile…c8pt Replacing Linux for software written for the Linux kernel is possible. Android has a mandatory app sandbox with yearly backwards incompatible improvements to the privacy and security model phased in via mandatory target API levels (within around a year for Play Store apps, far longer outside it). It also heavily reduces accessible kernel APIs.
Running on both FreeBSD and Linux is easier than porting to a sandboxed environment and using those APIs.

2026-07-24 20:55:10 CEST

- reply

@nprofile…z3n8 @nprofile…8kpe Google cannot take back AOSP being open source, that's not how it works. The existing versions will always be open source. It's still a far better starting point even without them. Your attempt at a statistic on how much they write is completely wrong, and you greatly underestimate how many non-Google Android OS developers there are. There are a massive number of very serious forks of AOSP including projects which heavily branched away from it already in the past.

2026-07-24 19:07:49 CEST

- reply

@nprofile…75s8 @nprofile…f4ec @nprofile…c8pt @nprofile…ppje @nprofile…dey5 No, that's completely untrue. Android moved away from requiring downstream changes to the Linux kernel years ago. Modern Android works with mainline, stable and LTS kernels.
Android has branches of the upstream LTS kernels with additional backports but also works directly with the upstream LTS kernels. The minimum kernel version for a major Android release is higher when using an upstream kernel since they backport and depend on features.

2026-07-24 18:35:06 CEST

- reply

@nprofile…c8pt @nprofile…ppje @nprofile…dey5 Moving to a microkernel from Linux would be a great way to make enormous progress on privacy, security and stability.
Moving away from POSIX / Linux APIs for the OS to more modern ones designed around privacy and security would be nice too but is far harder and impractical since app compatibility is important for success.
Moving to a microkernel with a compatibility layer is realistic. It would also be even bigger progress if it was largely memory safe too.

2026-07-22 19:32:31 CEST

- reply

@nprofile…7a7m Device and strong integrity require a Google certified device running the unmodified stock OS. Basic is expected to pass when logged into a Google account which can be a purpose-specific throwaway but those won't.
GrapheneOS has a feature intercepting Play Integrity API requests and it uses that to show a notice when an app uses it so you would know if the app was using Play Integrity API. If there isn't a notification, it isn't.

2026-07-20 23:12:12 CEST

- reply

@nprofile…2p5t It was suspended by the infosec.exchange moderators, not mastodon.social. An instance can suspend an account from another instance to block any of the content being visible or any direct interactions with the account such as replies. It got reported by a bunch of people even before we replied so some instances have blocked it, but not the one it's actually hosted on. We would prefer if the person who made it renames the website and the accounts themselves so we reached out here.

2026-07-18 11:09:32 CEST

- reply

@nprofile…05ad You can add it as a search engine by setting it to GET mode, using it and then adding it as one in the search engine menu. There will be a better search engine menu soon.

2026-07-17 20:26:43 CEST

- reply

@nprofile…hett Both apps are compatible with GrapheneOS. Neither is banning using a non-Google-certified OS with the Play Integrity API.
https://grapheneos.social/@GrapheneOS/116936668043273041