GrapheneOS

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

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

NIP-05 Address

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qzxrhwden5te0wphhxar9wgh8qmrpvdjj7un9d3shjxewgz5

Publishing to

relay.mostr.pub

poster.place/relay

Author Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Show more details

Last Notes

2025-07-09 17:26:18 GMT

Robert Braxman has published another video spreading blatant misinformation about GrapheneOS in order to promote his highly insecure products and services. In addition to many false technical claims and fabrications about our team, he's falsely claiming the project is dying.

2025-07-07 19:22:46 GMT

- reply

@nprofile…nevf
> what evidence do you have that these are "state-sponsored attacks"?
The Spanish state is contacting multiple publications misleading them about GrapheneOS. They're making inaccurate and deliberately misleading claims about it and our users.
> Is it your position that no criminals use your software to thwart the authorities?
Far more criminals use iPhone and Android on their devices. There's no evidence that a higher proportion of our significant userbase are criminals.

2025-07-07 19:00:22 GMT

GrapheneOS is currently under a state sponsored attack attempting to misrepresent it as being for criminals, which we covered a bit at https://grapheneos.social/@GrapheneOS/114784469162979608. These poorly researched, biased and inaccurate news stories have led to more harassment towards our community and team.

2025-07-03 22:16:02 GMT

- reply

@nprofile…ll04 @nprofile…82me You're replying to our project account with misrepresentations of what we've said and done while downplaying attacks on the project. It's not the first time it's done it. Why do you feel the need to misrepresent our statements and downplay attacks harming our users and the project? What is it that bothers you about us addressing this? Why aren't you asking F-Droid to stop doing it but rather only us? You're choosing to follow us knowing we are going to defend ourselves this way.

2025-07-03 22:08:24 GMT

- reply

@nprofile…ll04 @nprofile…82me F-Droid is deliberately causing incompatibilities with GrapheneOS due to their grudge against the project. They're harming GrapheneOS users and then using it as an opportunity to blame GrapheneOS for it, spread misinformation about it and attack our team. Our thread is debunking their attacks on our project which can be seen throughout the linked issue while also bringing up how much they're attacking our project and team both there and elsewhere. That is defending ourselves.

2025-07-03 18:20:03 GMT

- reply

@nprofile…82me Our posts about F-Droid have always been in direct response to their attacks on our project and team. If they stop spreading misinformation about GrapheneOS and targeting our team with harassment through spreading fabricated stories and spin about them, we will no longer need to respond to it. If you support and use GrapheneOS, you should support us against these attacks on our project and team.

2025-07-03 18:18:19 GMT

- reply

@nprofile…82me F-Droid developers were involved in and supported the takeover attempt on GrapheneOS in 2018. They've subsequently engaged in years of spreading misinformation about GrapheneOS and libel about our team. They participate in blatant harassment including spreading Kiwi Farms style harassment material. Defending ourselves from attacks on the GrapheneOS project by debunking them is not drama. There are ongoing attacks on our project aimed at harming/destroying it, and we defend ourselves.

2025-07-03 16:11:24 GMT

- reply

We've repeatedly brought up F-Droid not properly listing permissions or checking for them. Their understanding of Android's permission model is wrong. The way they list permissions misleads and misinforms users. It's one of many major F-Droid flaws they consistently don't acknowledge or fix.

2025-07-03 16:11:19 GMT

- reply

Multiple of the F-Droid developers wrongly blaming their app bug on GrapheneOS in that issue are Calyx contractors. They prioritize attacking GrapheneOS with inaccurate claims and fabricated stories about our team over fixing a bug in their app impacting both GrapheneOS and non-GrapheneOS users.

2025-07-03 16:11:14 GMT

- reply

F-Droid has a long history of denying issues including covering up serious security flaws. In some cases they eventually ship a fix but still deny it. It's a major factor in why F-Droid is not a safe or trustworthy source of apps due to major security issues not being acknowledged or addressed.

2025-07-03 16:11:08 GMT

- reply

They're now realizing that it happens with standard Android permissions added / split in new releases. Their approach to installing apps has been incorrect in multiple ways for many years and this is one of them. Their approach to listing which permissions are used by apps is also very incorrect.

2025-07-03 16:11:01 GMT

- reply

F-Droid has an incorrect approach to installing apps which wrongly warns users about the standard Android POST_NOTIFICATIONS permission, our OTHER_SENSORS permission and previous Android permission additions/splits. They wrongly blamed GrapheneOS and didn't fix it:
https://gitlab.com/fdroid/fdroidclient/-/issues/2914

2025-07-03 16:10:50 GMT

- reply

For usability, apps trying to use those sensors when Sensors is disabled will trigger a notification from the OS which can be disabled on a per-app basis. This informs users about what's going on so they'll know the app is either doing something sketchy or that it may actually require it.

2025-07-03 16:10:40 GMT

- reply

When Network is disabled, we act as if the network is down for compatibility. We won't run network-dependent jobs, various APIs will report it as down and we give errors matching it being down. When Sensors is disabled, sensors not covered by standard permissions give zeroed data and no events.

2025-07-03 16:10:33 GMT

- reply

For Network, apps request INTERNET, so we provide a toggle for rejecting that request in the initial app install dialog. If it's added in an upgrade, it's disabled by default. For Sensors, apps don't request it so we handle it similarly to how Android handled POST_NOTIFICATIONS for existing apps.

2025-07-03 16:10:29 GMT

- reply

Nearly all apps are unaware of these non-standard permissions just as they're unaware of new permissions added by Android before they get upgraded. Therefore, we enable them by default for compatibility but provide the ability for users to disable them at install time like the standard permissions.

2025-07-03 16:10:19 GMT

- reply

The Android Open Source Project has infrastructure for this since it's a regular part of the app sandbox and permission model improving. We add Network and Sensors permission toggles in GrapheneOS where Network is based on the existing low-level INTERNET permission and Sensors is entirely new.

2025-07-03 16:10:09 GMT

Android regularly adds and splits permissions for new API levels. Legacy apps are handled by treating them as requesting the permission to provide a toggle for it. For example, Android 13 converted the existing toggle for disabling notifications for an app into a new POST_NOTIFICATIONS permission.

2025-07-03 15:36:40 GMT

- reply

2025-07-03 15:31:23 GMT

- reply

2025-07-03 15:31:17 GMT

- reply

2025-07-03 15:31:10 GMT

- reply

2025-07-03 15:31:02 GMT

- reply

2025-07-03 15:30:47 GMT

- reply

2025-07-03 15:30:40 GMT

- reply

2025-07-03 15:30:36 GMT

- reply

2025-07-03 15:30:33 GMT

- reply

2025-07-03 15:30:24 GMT

2025-07-03 13:22:42 GMT

- reply

@nprofile…h9ey @nprofile…0e2v GrapheneOS is working with a major Android OEM to help them produce devices meeting our requirements which may be sold with GrapheneOS officially. We hope to have this launched in 2026 or 2027. Pixels are currently the only devices meeting our hardware security and other requirements which are listed at https://grapheneos.org/faq#future-devices but there will be other options.

2025-07-03 13:10:09 GMT

- reply

@nprofile…htew @nprofile…lm3a @nprofile…99hd There's a high quality third party comparison between Android-based operating systems at https://eylenburg.github.io/android_comparison.htm. It shows how extremely different /e/OS is from GrapheneOS on privacy and security. The table has 2 lines covering average patch delays for important privacy and security patches on devices where each OS has the smallest delays. /e/OS regularly has these delayed for many months and often years. They often don't ship firmware/driver patches at all.

2025-07-03 13:08:43 GMT

- reply

@nprofile…htew @nprofile…lm3a The response from @nprofile…99hd we're replying to is an aggressive attack on the GrapheneOS project which is referencing harassment material targeting our team from Kiwi Farms. The YouTuber who posted that video attacking our team is openly a Kiwi Farms users. The video heavily engages in Kiwi Farms tropes. It consists of fabrications and spin aimed at directing harassment towards one of our team members. Referencing and spreading this content is aggressive and unethical.

2025-07-03 12:52:37 GMT

- reply

@nprofile…99hd @nprofile…lm3a What we've said about /e/OS has also been said by most privacy and security experts evaluating it. It's an objectively insecure and non-private system.
You're referring to fabricated stories and spin targeting our project and development team by groups like Murena threatened by the existence of the GrapheneOS project.
Please don't spread libel and harassment content targeting our team. Murena has participated in that and we posted public responses debunking their attacks.

2025-07-02 22:48:49 GMT

- reply

@nprofile…sl9j @nprofile…ev94 Note the Terminal app currently has a compatibility issue with VPNs in the same profile. You can work around this by putting it in a dedicated profile without a VPN since profiles each have their own VPN configuration. If you're interested in this area, you should try it out.
Unlike stock OS, it can be used to run GUI applications or whole GUI environments already.

2025-07-02 22:47:29 GMT

- reply

@nprofile…sl9j @nprofile…ev94 GrapheneOS has hardware-based virtualization support on all of the available devices. The experimental Terminal feature using it is available in developer options. You can use this to run a whole nested operating system inside of GrapheneOS. The sample virtual machine uses an Android fork of Debian, which wouldn't be out choice, but it's what is there for now.

2025-07-02 16:00:02 GMT

European authoritarians and their enablers in the media are misrepresenting GrapheneOS and even Pixel phones as if they're something for criminals. GrapheneOS is opposed to the mass surveillance police state these people want to impose on everyone.
https://www.xatakandroid.com/sociedad/cada-vez-que-vemos-google-pixel-pensamos-que-puede-ser-narcotraficante-movil-perfecto-para-crimen-sencilla-razon

2025-07-02 13:55:54 GMT

- reply

https://bsky.app/profile/iceblock.app/post/3lpewifycls27
Apple records which apps people install and requires an account to use their app store. Apple Push Notification Service (APNs) has comparable privacy to Firebase Cloud Messaging (FCM). However, iOS apps must use APNs for push while Android apps do not have to use FCM.

2025-07-02 13:55:31 GMT

- reply

https://bsky.app/profile/iceblock.app/post/3lswryqarlk2l
Making posts with inaccurate technical claims about Android doesn't inspire confidence. It's a closed source app with a closed source service fully under their control. Why is that the approach if their goal is helping people rather than monetizing interest in it?

2025-07-02 13:55:15 GMT

- reply

ANDROID_ID is a per-app-per-profile random ID. Not clear why they would need it. Android has privacy-preserving hardware-based attestation if they're talking about making it harder to spoof a location. Can't prevent either iOS or Android users making false reports via attestation APIs regardless.

2025-07-02 13:55:08 GMT

https://bsky.app/profile/iceblock.app/post/3lmzykc7rb42d
Apple stores which devices/users install which apps. They have the device IDs. US government could obtain a list of people who installed the app if a court authorized it. Not clear what they mean by having to storing device IDs. Those IDs aren't accessible to Android apps.

2025-06-30 13:44:30 GMT

- reply

@nprofile…kh7c @nprofile…x7wv @nprofile…kgqj Recommend looking at the third party Android OS comparison at https://eylenburg.github.io/android_comparison.htm for an idea of how different they are from each other. In particular, look at the 2 rows near the bottom covering security patches. Also, bear in mind it's the best case for devices where the OS has the least delay.

2025-06-30 13:42:53 GMT

- reply

@nprofile…kh7c @nprofile…x7wv @nprofile…kgqj Fairphone doesn't provide the bare minimum for privacy and security, which is a lower bar than our official security requirements. Our requirements are for a reasonably high level of privacy and security like Pixels/iPhones.
/e/OS is far more problematic and is pretty much the opposite of GrapheneOS.

2025-06-29 23:45:34 GMT

- reply

@nprofile…kgqj Fairphone doesn't meet basic security standards by providing proper updates and standard security features. They've explicitly expressed disinterest in meeting the higher standards required for GrapheneOS such as providing a secure element.
Multiple OEMs have reached out to us about meeting our requirements and working with us. One of those is capable of meeting our security and support requirements in 2026 so it's our focus.

2025-06-29 23:42:45 GMT

- reply

@nprofile…kgqj Fairphone's devices have atrocious security and they don't prioritize either privacy or security. They discontinued their OS without Google Mobile Services and replaced that with a partnership with Murena. Murena makes /e/OS, extraordinarily insecure and non-private fork of LineageOS. They've frequently attacked GrapheneOS and their attacks on DivestOS contributed to it dying. We won't be working with a Murena partner.

2025-06-29 20:31:11 GMT

- reply

@nprofile…38p4 That's unusual. Is it the Netflix app crashing or an OS crash? How long has it been happening? We shipped the Android 16 kernels, firmware and some other components recently so perhaps it was a recent regression from that. The rest of the Android 16 code will be shipped in a release soon.
You can enable system crash reporting in Settings > Security & privacy > More security & privacy > Notify about system process crashes to get a crash report if it's an OS component crashing.

2025-06-29 19:01:27 GMT

- reply

@nprofile…h46w @nprofile…zq5f That's is an area where macOS is far ahead of the Windows and desktop Linux world. A typical Windows laptop or desktop has a bunch of debugging functionality exposed from the motherboard to trivially take it over, unencrypted connections between important components, etc. No real verified boot also really hurts in this regard. Both the hardware and software vendors focus on checking off features like "Secure Boot" instead of actually trying to defend against real threats.

2025-06-29 18:59:24 GMT

- reply

@nprofile…h46w @nprofile…zq5f Generally, computers will be booted up with the OS able to access the data due to entering the initial encryption password even if they're locked. If an attacker gets physical access, it matters quite a lot if there are strong defenses against them getting access. GrapheneOS and iOS put a time limit on this via locked device auto-reboot but it needs to go along with strong physical security at a hardware, firmware and software level. Otherwise, can just get all the data.

2025-06-29 18:57:50 GMT

- reply

@nprofile…h46w @nprofile…zq5f At a hardware and firmware level, Macbooks are much better than typical laptops/desktops. They are pretty close to mobile hardware in terms of the nice hardware encryption support, secure element, verified boot, etc. macOS on top of that throws a lot of it away since it doesn't have nearly as much privacy/security protection as iOS, not even in regards to exploit mitigations, and it doesn't really properly benefit from verified boot, etc. Some Chromebooks are okay, not great.

2025-06-29 18:56:05 GMT

- reply

@nprofile…h46w @nprofile…zq5f Hardware and firmware security matters too. Most laptops don't get proper firmware updates for their various radios, pre-OS boot chain and other components. AMD doesn't release microcode updates for their consumer CPUs so users depend on UEFI updates for those but no one is properly providing them.
x86_64 itself and the platform around it is a huge mess for security.
Macbooks are in a league of their own for laptop hardware/firmware security, but macOS doesn't preserve that.

2025-06-29 18:53:29 GMT

- reply

@nprofile…h46w @nprofile…zq5f Getting more users for anti-fingerprinting is the only reason we plan to launch our Vanadium browser for use outside of GrapheneOS including publishing it on the Play Store in the future. We're only going to do that after some more important privacy, security and data import/export features are added so that the initial reception is better than it would be to the current very minimal fork of Chromium we have. Safari + iOS has a huge advantage from user count on fingerprinting.

2025-06-29 18:52:07 GMT

- reply

@nprofile…h46w @nprofile…zq5f Fingerprinting is a much separate thing. Apple has a huge advantage for iOS and Safari in that area due to having a huge number of a small number of device models in use. Fingerprinting depends on how many people have the same setup. GrapheneOS does and will continue to only support a small number of device models, expanding beyond Pixels but only to a few other future high security devices. However, we do not have iOS user scale so iOS clearly has an advantage in that area.

2025-06-29 18:49:32 GMT

- reply

@nprofile…h46w @nprofile…zq5f Sandboxing is not heavily used through the OS. There aren't strict whole system MAC/MLS policies with the OS designed around them. Nearly everything is memory unsafe C and C++ code rather than the majority of new code and a large portion of existing code being memory safe. Modern exploit protections are not integrated.
There's no real verified boot, although this is less important than the earlier stuff. An incomplete chain of trust verifying only the kernel isn't comparable.

2025-06-29 18:47:32 GMT

- reply

@nprofile…h46w @nprofile…zq5f No, it does not provide comparable privacy and security.
They do not provide a modern app sandbox let alone it being mandatory. There isn't a proper permission model and case-by-case consent for the opt-in approaches they do have for apps to choose to use.
In regards to encryption, the hardware/firmware/software provides almost no protection against data extraction. That means if the device is in After First Unlock state as is usually the case, it's easy to get data from it.

2025-06-29 18:16:04 GMT

- reply

@nprofile…h46w @nprofile…zq5f If the goal is avoiding always being connected to cellular, there's airplane mode and the option to disable the SIM to also disable Wi-Fi calling/texting. Some people use a smartphone as a portable computer without being connected to cellular much or at all. It's not mandatory to have it.
Laptop hardware other than Macbooks is a substantial downgrade for privacy and security. Traditional desktop operating systems are similarly a substantial privacy and security downgrade.

2025-06-27 23:04:28 GMT

- reply

@nprofile…8z6w It could be a bug in DNSnet. Can you try with a different VPN service app and see if the problem occurs with that too? It could also be an issue with your cellular provider's DNS.

2025-06-26 14:13:49 GMT

- reply

@nprofile…sl9j Apple users expect a lot more consistency on macOS and to an even greater extent on iOS so developers are forced to do it by user pressure. There are a noisy minority of Android users who care about this but developers can ignore it, just like how some app developers ban using an alternate OS and largely ignore that they've blocked 1% or so of Android users from using their app.

2025-06-26 14:12:54 GMT

- reply

@nprofile…sl9j Material UI guidelines are quite directly comparable to what Apple has and have if anything been leading ahead of Apple. However, getting apps to actually adopt it is a whole different story. Even Google's apps aren't perfect at adopting it because there is so little pressure to do so, although they've gotten a lot better at it. Users do not expect consistency for UI from Android apps therefore app developers don't really do it.

2025-06-26 14:11:43 GMT

- reply

@nprofile…sl9j There are a growing number of OEMs not substantially changing the UI but it's still common. The ones not heavily changing the UI are still lagging behind on OS releases quite a lot and usually not supporting their devices as long. Combined with many of the devices being very cheap, low-end ones only getting a couple years of updates at best and it adds up to having tons of inconsistency regardless of what Google does with the UI.

2025-06-26 14:10:04 GMT

- reply

@nprofile…sl9j Nexus devices and now Pixels are there to act as reference devices. Only Pixels ship the latest Android release each month.
Other devices take the initial yearly release, fork it and usually make major changes. They apply the monthly backports of High and Critical severity patches, often late. Pixels aren't shipping backports but rather a new monthly, quarterly or yearly release each month, and without core OS changes from AOSP.

2025-06-26 14:02:21 GMT

- reply

@nprofile…sl9j Google has very similar guidelines and possibly even has more specified in detail. The issue is entirely the lack of compliance with it. It doesn't help that most Android devices do not use the standard Android Open Source Project interface shared by GrapheneOS and the Pixel stock OS. Most people buy Samsung devices, etc. with massive changes to the UI not at all in compliance with the Material UI guidelines.

2025-06-26 13:59:39 GMT

- reply

@nprofile…rrsa @nprofile…sl9j
> The other drawback of GrapheneOS is the camera app has struggled immensely to keep up with stock Android.
Our Camera app has HDR+ and Night mode but you do not have to use it.
> There was a time where you couldn't even take pictures.
There has certainly never been a release of GrapheneOS in the Stable or Beta channel where it wasn't possible to take pictures.

2025-06-26 13:33:16 GMT

- reply

@nprofile…sl9j @nprofile…m40s @nprofile…d7j8 One of the issues is that they went through several iterations of the Material design and many apps are using an older version of it. There has been too much change to have things consistent. It's difficult to keep up with the latest design and existing lack of consistency reduces pressure to do it.

2025-06-26 13:32:11 GMT

- reply

@nprofile…sl9j @nprofile…m40s @nprofile…d7j8 Material UI has specifications covering nearly everything. The main issue is that applications lag far behind on adopting it and aren't aware of the more detailed UI specifications. Core OS UI itself is fairly consistent and modern. Need to ignore the legacy AOSP apps in GrapheneOS we'll be replacing.

2025-06-25 23:27:58 GMT

- reply

@nprofile…sl9j @nprofile…6f9s You need to explicitly select it. It's not enough for it to show as selected, you need to press it there and authorize it. The Android UI for this is misleading when the OS doesn't bundle one since it will show the first installed one as selected before it's activated.

2025-06-25 21:24:54 GMT

- reply

@nprofile…sl9j @nprofile…6f9s For TTS on GrapheneOS, you need to install a TTS app. There are a bunch of both open source and proprietary options. Some are based on old school hard-wired text-to-speech data while others use LLMs. eSpeak NG is an example of a more old school one with basic functionality. If you want something better there are options. LLM ones improve quality but hurt latency.

2025-06-25 18:11:32 GMT

- reply

@nprofile…x3wl @nprofile…havt They don't meet our hardware security requirements. See https://grapheneos.org/faq#future-devices. We expect proper privacy/security patches, OS update support and hardware-based security features. Fairphone is quite behind on those compared to many more mainstream devices. It's not a good fit for GrapheneOS. They're finally moving to ARMv9 but still apparently no secure element.

2025-06-21 15:00:16 GMT

- reply

@nprofile…vmg7 We have not done anything of the kind. We have never claimed people should only trust us. We have pointed out that nearly all phone products marketed as private and secure actually have atrocious privacy and security far worse than many mainstream devices, which is accurate. iPhones are one of the only examples of devices with high private and security which are being marketed that way. Nearly all the other options are acting as if they're better than iPhones while being far worse.

2025-06-21 13:59:43 GMT

- reply

Our very reasonable hardware requirements are listed at https://grapheneos.org/faq#future-devices. We expect industry standard security patches/features, not anything exotic. Multiple OEMs have indicated they should have no issue meeting these requirements with the next generation Snapdragon SoC.

2025-06-21 13:54:20 GMT

- reply

Pixels remain the only devices providing a high level of security combined with proper secure support for using another OS. We hope to have more options by the end of 2026 based on contact with an OEM interested in meeting our requirements but there's no specific timeline.

2025-06-21 13:48:22 GMT

Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We've made it clear we're shipping Android 16 soon and that the supported devices will remain supported.

2025-06-20 17:40:57 GMT

We need help testing our experimental Android 16 support. If you have a spare 6th, 7th, 8th or 9th generation Pixel, you can help us test early builds for Android 16 soon. You can join our testing chat room via Matrix or Discord if you want to help. https://grapheneos.org/contact#community-chat.

2025-06-17 16:44:56 GMT

- reply

@nprofile…uqnt @nprofile…tfka Linux does not mean systemd and GNOME. GrapheneOS is a Linux distribution. Bringing a dramatically less private and secure desktop software stack to mobile is not bringing Linux to mobile. It is rolling back privacy and security, things which you are in fact opposed to in order to push your preferred software and ideology. Do not expect that you can try to leverage stuff we post to undermine us and others to push your preferences without us responding to it to defend ourselves.

2025-06-16 15:16:55 GMT

- reply

We do all production builds on 3 local GrapheneOS Foundation machines and each OS developer has at least one powerful local workstation. However, we need a lot more computing power than usual due to the way we're adding back device support to AOSP requiring many clean builds.

2025-06-16 15:13:23 GMT

We need to do a large number of generate-prep and development builds as part of finishing up our new approach and automation for Pixel device support. Can anyone get us cloud computing credits? Otherwise, we need to start paying for multiple new Hetzner dedicated servers.

2025-06-15 16:44:22 GMT

- reply

@nprofile…8tdh We accept on-chain Bitcoin donations:
https://grapheneos.org/donate#bitcoin
It's hard for us to add Lightning donations especially in the near future with how busy we are. It's already a struggle to get our cryptocurrency transactions, etc. audited for legal compliance since few accounting firms are willing to do it. We don't know if they would be capable of handling Lightning.

2025-06-15 14:29:18 GMT

- reply

@nprofile…lzzj It's likely that we can still add support for the Pixel 10 and future Pixels, but it will take us more time as it would for a non-Pixel devices. Pixels are still the only devices meeting our hardware requirements (https://grapheneos.org/faq#future-devices) so they're still by far the best choice for us. Other devices with non-stock OS support don't meet far more basic security requirements. Among Android phones, only Pixel hardware is putting up a good fight against common exploitation.

2025-06-15 14:19:55 GMT

- reply

@nprofile…8tdh We plan to add our own text-to-speech engine based on an existing model for it. The existing options don't provide the functionality we need and most also lack permissive or GPLv2 licensing.

2025-06-13 21:55:19 GMT

- reply

@nprofile…d82u @nprofile…r2ra Pixels being closer to every other non-Pixel phone in the work we need to do to support them doesn't change that they're the only devices meeting our very reasonable hardware requirements (https://grapheneos.org/faq#future-devices).
We were always going to need to have hardware produced for our usage. We need to be able to make hardware and firmware level improvements. We need more control over the low-level choices. We need long term support which continues to meet our requirements.

2025-06-13 21:49:25 GMT

- reply

@nprofile…uqnt @nprofile…tfka Bringing desktop Linux software to mobile is the direct opposite of building a more private and secure computing platform.
Hardware with extraordinarily poor security like the Pinephone using bottom of the barrel components with no attention to security whatsoever does not interest us. It's the direct opposite of what we work on.
We're concerned about far more minor issues than using a device where we wouldn't have the most basic security patches and defenses available.

2025-06-13 21:38:32 GMT

- reply

@nprofile…uqnt @nprofile…tfka You are yourself advocating for rolling back privacy and security. You're trying to diminish the efforts of serious efforts to improve them instead of simply paying lip service to them as part of false marketing. You think you're superior because you're telling people to use niche platforms. They're unable to protect people from basic malware and exploits. They are not and will not be something non-technical people would consider using and involve huge sacrifice.

2025-06-13 21:12:10 GMT

- reply

@nprofile…uqnt Our security requirements are very reasonable. They're all standard features deployed by mainstream devices. They're what's needed to protect users against real world, widespread commercial exploit tools such as Cellebrite device extraction tools exploiting Linux kernel and firmware vulnerabilities. You promote highly insecure and non-private hardware, firmware and software.
You're promoting is highly insecure and non-private hardware, firmware and software that's harming people.

2025-06-13 16:24:20 GMT

- reply

@nprofile…s5s0 @nprofile…5lme We're still going to try to support future Pixels but it's going to be much harder and we depend on them not deciding to cut support for it. The cuts to AOSP are supposedly due to cost cutting measures. They don't realize they're actually earning a ton of money from having this and therefore think they're cleverly cutting costs not bringing in revenue. They're incredibly wrong about that.

2025-06-13 15:47:09 GMT

- reply

We have early builds based on Android 16 booting on Pixels but will need to do a lot more work to reach production quality.
We're also beginning building/testing backports of Android 16 firmware updates to Android 15 QPR2 with the aim of releasing those patches to Alpha today.

2025-06-13 14:26:46 GMT

- reply

@nprofile…5lme We'll be making a device based on what we want to have for a device, not what a tiny minority of people consider essential. We want to use an upcoming Snapdragon flagship SoC with MTE support. That would mean significantly better CPU and GPU performance than a Pixel without us doing anything, providing at least one good reason beyond us having more software/firmware control to buy it over a Pixel. It has to be a flagship device for security and cost reasons.

2025-06-13 13:47:48 GMT

- reply

@nprofile…uqnt @nprofile…tfka There are major releases 4 times a year with the latest code from the development branch where the latest changes are pushed to AOSP. The other releases are minor ones not moving to a new revision of the development branch.
The right thing to do would have of course been replacing the internal branch with the largely unused AOSP main, eliminating the need to keep merging it into an internal branch. They eliminated that mess by rolling back progress to open development instead.

2025-06-13 13:41:30 GMT

- reply

@nprofile…uqnt @nprofile…tfka AOSP doesn't include those things for non-Pixel devices either.
> AOSP in general is no longer developed in the open, they'll just throw some sources over the wall some time after releases happen (i.e.: in the style of macOS/Darwin).
No, this is highly inaccurate. AOSP releases are published alongside stock Pixel OS releases with full source code history for the non-Pixel portions. It is not published later and is not published as simply tarballs without the commit history.

2025-06-13 13:30:40 GMT

- reply

@nprofile…uqnt Pixels are still the only devices meeting our security and other requirements. Other devices are not capable of offering competitive or better security to iPhones. It doesn't do any good to push for us supporting other devices which do not have the foundation to offer a high level of privacy and security. There isn't a single other option with even the basics needed to protect user security well.
Other devices with the required security features don't allow a non-stock OS to use it.

2025-06-13 06:36:43 GMT

- reply

We've ported all of our features to Android 16. However, part of our hardware-based USB-C and pogo pins port control feature may need to be reimplemented due to being part of device support code. We have a lot of work remaining reimplementing device support removed by AOSP 16.

2025-06-13 06:26:32 GMT

We'll be making at least one more Android 15 QPR2 release soon to ship backports of important firmware and driver security patches released with Android 16. This wouldn't usually be required since we'd have Android 16 released to end users using the Alpha channel and soon Beta.

2025-06-13 00:53:04 GMT

- reply

@nprofile…s5s0 Yes, but beyond that we would have the source code. It is shared source and we would be building the binaries ourselves. It isn't open source but if we were working with an ODM, we would be able to build that code. We would also be building the late stage boot chain and various other things. Qualcomm did take over more of the lower level parts themselves over time and we probably wouldn't be able to modify the TEE or secure element OS, but we could make applets for each of them.

2025-06-12 21:59:46 GMT

- reply

Paying an ODM to make a Snapdragon device for us is increasingly appealing. We would have all the device support code we need, could build it with compiler-based hardening and would be able to harden a lot of the device's firmware. We could also make secure element applets.

2025-06-12 21:56:10 GMT

- reply

We received early notice of Android 16 removing the device support code from AOSP but were unable to confirm it or determine the details. We have existing automated tooling for this we can significantly extend to generate what we need. It will be difficult and a major regression.

2025-06-12 21:52:41 GMT

- reply

We'll be starting from the Android 15 QPR2 device support code and stripping it down to a bare minimum. Pixel 9a is a special case and will be more work.
Our hardware-based USB-C port control feature will no longer work with this approach and we need to replace half of the code.

2025-06-12 21:48:52 GMT

- reply

Normally, we would have announced the availability experimental releases based on Android 16 already. Unfortunately, Android 16 dropped device/hardware support from the Android Open Source Project and we're going to need to put it together ourselves without being prepared for it.

2025-06-12 21:47:12 GMT

Our initial port to Android 16 has been completed and can be built for the emulator from our 16 branch. All of the device-independent GrapheneOS code has been ported. There are some parts of the port which will be redone better and a lot of testing and fixing regressions to do.

2025-06-12 20:31:10 GMT

- reply

@nprofile…pvvr @nprofile…5hv3 An initial GrapheneOS device would likely just an existing Snapdragon Android device platform from an ODM or OEM we would be paying for it. It would have first class GrapheneOS support where we can modify a lot of the firmware and build the Snapdragon userbase code. It would provide all of our security requirements once Snapdragon adds memory tagging support.

2025-06-12 18:14:25 GMT

- reply

@nprofile…5hv3 @nprofile…pvvr Traditional dumb phones have atrocious privacy and security with no way to do secure communication.
Reasonably secure dumb phones vs. reasonably secure smartphones would be the same hardware in practice. Flagship SoCs have the best security so performance comes with security even if it's not needed.
If people want to limit how they use computers, they can.

2025-06-12 16:42:17 GMT

- reply

The baseline will be several million dollars, which can be spread out across the cost of preordered devices. This is the cost of making a modern, secure device with a secure element and the other requirements we have for one instead of a low-end device with outdated hardware.

2025-06-12 16:41:00 GMT

- reply

Once an OEM offering the service of making custom devices has a platform based on a new Qualcomm Snapdragon SoC with hardware memory tagging support, we can do a crowdfunding campaign to raise the money needed to have them build a device for us. We have talked with a couple OEMs.

2025-06-12 16:39:56 GMT

- reply

If the Pixel 10 does meet our requirements, we'll support it, but it will take significantly more time and effort to develop support for it. At the end of the year, Qualcomm should finally release a new SoC providing hardware memory tagging. If they do, we can shift focus to it.

2025-06-12 15:45:43 GMT

- reply

For years, Google has been using extraordinarily anti-competitive Google Mobile Services (GMS) licensing agreements with OEMs to disallow competition. To further prevent competition, they made the Play Integrity API where apps devs are convinced to check for valid GMS licensing.