HeliBoard is good too, forgot to mention it but it's also a solid choice. The variant without glide typing is a good security choice as you don't execute dynamic code as well.
No need to be sorry at all 😄 You share the same views on the keyboard as others and it's not a hostile thing to say. Being able to choose your own keyboard isn't an issue, benefit of GrapheneOS is you can use your own apps you trust.
A mobile OS of this size is a large undertaking, maintaining it with fast, weekly updates, porting Android patches and doing community/support takes up a lot of time, it can be more work than adding features we desire. We strongly care about usability and app compatibility, but it's understandable GrapheneOS cannot compete against multibillion dollar companies with a huge budget on user experience. The community of users is our twelfth man.
In the best future all the AOSP sample apps that come bundled with the OS would be replaced with better, modern apps, like the keyboard, gallery, file manager etc. But, there'd have to be a developer who can make each one. There's a huge amount of additional work to do on improving privacy and security which obviously has a priority.
For the record: We do want to have a new keyboard eventually. The AOSP keyboard is lacking. Open source licensing issues make adding someone else's work difficult. FlorisBoard was an example. As a security and privacy focused OS we need our apps to meet stringent requirements or abide by new ones if they come up too.
Hold app icon -> app info-> Permissions -> Network -> Don't allow
This is a standard alert message. Using a keyboard app requires a lot of trust so it's just to ask if the user is sure on what they are doing.
I can't assess that Yandex Keyboard. Probably best to disable it's network access in app settings. Google's keyboard is also really good if you disable network access. Florisboard is a good open source keyboard.
#GrapheneOS version 2024040900 released:
- rebased onto AP1A.240405.002.A1 Android Open Source Project release (includes a launcher taskbar improvement)
- avoid crashes in Chromium-based web browsers and the WebView in their sandboxed processes caused by an incompatibility between exec-based spawning and the new userfaultfd-based garbage collector enabled by Android 14 QPR2
- DNS resolver: fix upstream bug resulting in NUL byte being included in the random string for the DNS-over-TLS test query
- allow privileged installers to use getSharedLibraries(MATCH_ANY_USER) in order to enable Apps to handle an edge case involving shared libraries (Vanadium Trichrome library) updated in other users while avoiding adding the INTERACT_ACROSS_USERS permission used for this purpose by the Play Store
- kernel (5.10, 6.1): update to latest GKI LTS branch revision
- kernel (5.10): reapply reverted upstream f2fs and irq changes now that the regressions are resolved
- GmsCompatConfig: update to version 102
- fix our infrastructure for testing our CarrierConfig2 app
It's been in high demand for users but something like this MUST be an opt-in.
nostr:npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5 this is scary. Can you confirm or deny whether this works on graphene devices?
https://blog.google/products/android/android-find-my-device/
This is a Google Play feature that won't work on GrapheneOS. It's an Apple find-my alternative. Bluetooth also needs to be configured and enabled by the OS to make it work that way.
(You responded to a Nostr account bridging replies from the GrapheneOS Mastodon. It doesn't always recieve it.)
Posting AI generated text in the GrapheneOS community is forbidden with the exception of clearly marked automated translations:
This is becoming a serious problem so we've made a sticky post. It will be covered in a more detailed list of rules too.
They were getting hashes derived by the device unlock credential. They aren't able to get the keys themselves because of how Pixels use a secure element, and because Android uses filesystem-based encryption rather than the standard full-disk encryption older Android or Desktop solutions like Windows or VeraCrypt would have. There is an in-depth explanation on how disk encryption works on Android and GrapheneOS here: https://grapheneos.org/faq#encryption
Putting the device in AFU and unlocking the device would leave hashes derived from the lock method credentials in memory. They could extract the hash from a memory dump and then make a tool to brute force the hash to attempt to figure out the unlock credential. When a device is powered off or in before first-unlock state then there is nothing in the flash storage or memory.
This issue that made the stock OS get affected by the attack was they do not clear memory when it is freed and that Fastboot could be exploited to dump the memory to another device. The fix Google provided is zeroing memory when switching into Fastboot mode. The actors doing this exploit discussed having no brute-force capability for GrapheneOS at the time in their product changelogs, likely because we sanitize memory on free already. That doesn't mean they could not have figured out another way though, due to the nature of the device being in-use and unlocked
Users should treat AFU smartphones like they'd treat a powered on, unlocked laptop as the data isn't at rest. That's why we've had features like automatic reboot to put data at rest after a set time and USB port controls to disable the data lines (or the port entirely) to make exploitation of devices in that state difficult.
Tools to brute force credentials for encrypted operating systems from memory dumps are trivial in that market, Passware is an example of a product. There are hardware-backed protections against brute forcing, but because of they dump the memory to a PC they aren't touching the phone at all so they could avoid that entirely.
The affair behind this have been quite big for us and it possibly deserves a longer run-down or article in the far future by someone.
A shame! They seem to like talking about us in there too and the 'fun' they have dealing with us or our features.
All of those companies will name GrapheneOS when it suits their motive, but they'll ban the GrapheneOS account after we get wins over them. They'll use our name to promote their products for "support" on extractions (which involve the user giving their passwords away) but when we discuss counter-forensics in a server all about DFIR they want us out.
We posted about https://discuss.grapheneos.org/d/11860-vulnerabilities-exploited-in-the-wild-fixed-based-on-grapheneos-reports on the Digital Forensics Discord (.gg/digitalforensics) used by DFIR students, law enforcement, employees of Cellebrite, MSAB, GrayKey etc. It's on-topic and they've regularly talked about GrapheneOS, but they got upset about it and banned our project account. 🤷
People who work at Cellebrite, NSO, law enforcement agencies, etc. are welcome to use GrapheneOS and participate in our community. We would appreciate posts from people working in these secretive industries "helping" us improve security for GrapheneOS, Pixels and Android 😉
Yes, Android (and GrapheneOS) uses file-based encryption by default. User profiles are also encrypted independently with their own keys. The data exfiltration is not the exploit but rather something that could be done from it, the encryption isn't affected.
The attack concept from the first vulnerability allowed brute forcing of an After First Unlock stock OS device thanks to exploiting the Fastboot firmware for a memory dump. It is a trivial platform reset attack. The issue was that Google did not erase the memory of an in-use device when switching to Fastboot. The stock OS doesn't clear freed memory while GrapheneOS does.
All operating systems incorporating disk encryption are vulnerable with this to a degree and the best mitigation is having the device purge encryption keys by rebooting or power off. We had defences like this already like auto-reboot and the option to disable USB entirely from hardware when an AFU device is in OS mode. Someone who'd be affected by this would be someone using the device the moment it had been stolen.
PCMag have reported our recent affair about #GrapheneOS and our success in reporting vulnerabilities. You can learn more about the background of the incidents leading up to this report:
https://uk.pcmag.com/mobile-phones/151710/new-zero-day-attacks-target-google-pixel-phones
> "Without going into details, GrapheneOS adds that Google is only introducing a “partial solution” in the phone’s firmware to fix the second vulnerability. We’ve reached out to GrapheneOS for more information."
We sent a reply to this already but in the meantime this is what we meant:
While it appears they've changed the firmware to stop the reboot to recovery for wiping being interrupted, it's still not stealthy and the device could still have the power cut off, etc. before it completes. Wiping without rebooting is the full solution to prevent bypassing the factory reset, which we'll still need to implement ourselves for our duress PIN/password feature until they have an implementation that's included.
We appear to have at least 2500 followers paying for Twitter Premium, so we now have the blue checkmark on the project account on Twitter. We haven't paid for Twitter.
PCMag have reported our recent affair about #GrapheneOS and our success in reporting vulnerabilities. You can learn more about the background of the incidents leading up to this report:
https://uk.pcmag.com/mobile-phones/151710/new-zero-day-attacks-target-google-pixel-phones
The latest Pixel security updates now contains boot chain firmware security improvements caused by our vulnerability reports to Google. The reporting developer who provided a PoC mitigation and the #GrapheneOS Foundation as a whole are now credited on the Android Security Acknowledgements.
https://source.android.com/docs/security/overview/acknowledgements#april-2024
The two vulnerabilities (now assigned as CVE-2024-29745 and CVE-2024-29748) were announced by us as being exploited in the wild, targeting a stock Pixel device. Exploitation were done by forensics companies who design (or more likely, buy) zero-day exploits to perform data extraction with physical access and sell them as a product to LE or state agencies. Companies in the business include Cellebrite, MSAB, Magnet (GrayKey) among others.
CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app, by holding volume down you are were able to cancel the reset caused by apps like Duress or Wasted. It appears they've implemented a partial solution in firmware.
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
Here is Google's confirmation of them: https://source.android.com/docs/security/bulletin/pixel/2024-04-01#Announcements
There is no knowledge of this affecting a GrapheneOS device because of the defences already in place, however since these discoveries we have placed additional focus in protecting data not at rest with security features like the USB controls, improving the auto-reboot feature and working on future features like no-reboot factory resets, a duress PIN/password and second factor device unlock.
A new GrapheneOS update is released now with the full security backports, rather than a partial release from them not being available yet.
#GrapheneOS Version 2024040200 released.
See the changes:
- full 2024-04-01 security patch level (early release based on AOSP 14 April security backports since the official April AOSP and stock Pixel OS monthly releases aren't available yet)
- fix race condition for Wi-Fi and Bluetooth auto-turn-off leading to the first auto-turn-off timer after the first Wi-Fi or Bluetooth state update potentially not being scheduled
- fix Wi-Fi auto-turn-off no longer handling Wi-Fi state change events not involving a Wi-Fi network
DocumentsUI (Files): do not delegate handling of downloaded APKs to DownloadProvider to avoid confusing install permission prompt
- flash-all: raise minimum fastboot version to 34.0.5
- kernel (Pixel 8, Pixel 8 Pro): sign vendor modules after building them instead of only signing generic (GKI) modules
- kernel (6.1): update to latest GKI LTS branch revision
- fix upstream bug breaking pressing power button 5 times to make an emergency call
- fix upstream bug causing 5 second delay to start the emergency dialer for the first time
- CarrierConfig2 (app created by GrapheneOS to replace Google CarrierSettings): add stub implementation of VendorConfigProvider
- Setup Wizard: use new API for emergency calls
- Setup Wizard: add prompt for unlocked bootloader triggering reboot to fastboot mode to lock
- Setup Wizard: add prompt for disabling OEM unlocking after the device is locked (will be disabled by default)
- GmsCompatConfig: update to version 100
- GmsCompatConfig: update to version 101
- Vanadium: update to version 123.0.6312.80.0
- Vanadium: update to version 123.0.6312.80.1
The GrapheneOS page on
nostr:npub10pensatlcfwktnvjjw2dtem38n6rvw8g6fv73h84cuacxn4c28eqyfn34f have been changed for a more up-to-date description thanks to new features and improvements to #GrapheneOS during past year and a half.
https://opensats.org/projects/grapheneos
Thankful to OpenSats for their help and support.
> Wen graphene hardware
We've always been open to work with OEMs to make hardware but they never choose to meet the requirements set here, can't afford to, or want to put the effort in:
https://grapheneos.org/faq#future-devices
The opportunity is always there, but they need to work on our terms. Having a device less secure than current options is undesirable, especially if we are likely to be blamed for failures done because of that device and only that device...