#GrapheneOS version 2024111700 released.

This update contains a lot of sandboxed Google Play compatibility later improvements, patches, and fixes upstream issue where Private Spaces are not putting data at rest when stopped. The limit amount of running users have also increased for newer devices.

See the changes:

•  Private Space: put data at rest immediately after stopping the profile to match user profile behavior instead of only on reboot  

•  fix Mock Location on devices without any standard location providers (only Pixel Tablet)  

•  backport mainline APEX module patches for ART, DNS Resolver, DocumentsUI, Media, Media Provider, Network Stack, PermissionController, Remote Key Provisioning and Wi-Fi  

•  raise maximum running users from the standard 3 to 4 for 6GB memory, 6 for 8GB memory, 10 for 12GB memory and 14 for 16GB memory  

•  Settings: disable Bluetooth contact sharing by default  

•  Settings: fix Private Space handling in Passwords & accounts > Additional services  

•  Settings: fix multiple cases of missing user profiles handling for added settings  

•  Dialer: fix RTT related crash from not using the correct theme configuration
  
•  Contacts Provider: work around upstream bug causing deadlock with contact scopes  

•  temporarily don't report harmless fingerprint-service.goodix crash  

•  temporarily disable hardened_malloc for vendor audio service due to Pixel Tablet bug  

•  Sandboxed Google Play compatibility layer: significantly rework client side compatibility layer to avoid deadlocks and to avoid allowing starting apps with no exported components (i.e. not even a launcher activity)  

•  Sandboxed Google Play compatibility layer: overhaul approach to raising Google Play components to the foreground to avoid it always being considered in the foreground while also solving an issue triggered in a rare edge case at startup  

•  Sandboxed Google Play compatibility layer: stop Play Store from attempting to auto-install some system component packages, such as "Android System SafetyCore" (com.google.android.safetycore) and "Android System Key Verifier" (com.google.android.contactkeys)  

•  Sandboxed Google Play compatibility layer: fix Android Auto voice commands not working in some cases  

•  Sandboxed Google Play compatibility layer: fix one of the Android Auto permission toggle checks for companion devices  

•  Sandboxed Google Play compatibility layer: extend opt-in Android Auto "Allow permissions for handling phone calls" toggle to allow access to Bluetooth adapter hardware address access for hands-free audio support with wired Android Auto rather than only wireless Android Auto where the baseline toggle already grants access to that  

•  Sandboxed Google Play compatibility layer: don't stop apps that use Dynamite modules when Play services stops since the new version of the Dynamite client library handles dynamic re-connection without app restart and older ones will handle this by stopping  

•  kernel (5.10, 5.15, 6.1, 6.6): disable unused TIPC protocol support  

•  kernel (5.10): update to latest GKI LTS branch revision  

•  kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.170  

•  kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.115  

•  kernel (6.6): update to latest GKI LTS branch revision  

•  System Updater: show failure notification for update_engine errors  

•  System Updater: add missing UpdateEngine.unbind() to avoid extra callbacks for progress and error reporting 
 
•  System Updater: avoid treating non-404 errors such as a connection failure as lack of an incremental update  

•  System Updater: handle a partially downloaded incremental update being removed from the server by falling back to the full update instead of retrying resuming the incremental download until the next update (this will allow us to remove an incremental for the latest available version to save storage space or work around a potential update_engine bug without it causing download resumption errors)  

•  System Updater: delete stale update from a failed download of a previous release slightly earlier  

•  Vanadium: update to version 130.0.6723.102.1  

•  Vanadium: update to version 131.0.6778.39.0  

•  GmsCompatConfig: update to version 149

nostr:nevent1qqspxp3g7peq0udsnp9upp9exuzf2m8ak5ys49vsm7wvpftgxx6sh9spzpmhxue69uhkummnw3ezumt0d5hsygz5dz7wad6vudwtg9eaejvhf0w6e85fff6t702yl89gka25vpwfa5psgqqqqqqs6cz6aq 

 One of our contributors developed a Typst-compatible text editor designed for GrapheneOS users. 

 This is how it looks:

https://image.nostr.build/ed568c86871552684e0b406287578e4669798c9051e39e01b51aec3b81ca1477.jpg

New features other than upkeep won't be added to it for a while however as there will be a major rehaul for this in the future.

https://beautyxt.dev/ 

 confusing with another app, https://beautyxt.app/ 

 The big advantage Ledger had for a long time was physical attack resistance with a secure element. Trezor wallets originally didn't use them, and had vulnerability disclosures where a skilled actor could dump encrypted device PINs which could be used to brute force them.

Using an additional passphrase and (on applicable models) a microSD card as a key would mitigate this issue but both the security of the passphrase and the threat actor not having the microSD card is important to make this countermeasure effective.

Trezor didn't use them until the Safe 3 and later. Safe 3 and 5 are far more secure than their predecessors.  

 Jade doesn't have a secure element, so a second independent device is involved in decrypting the device's sensitive data to make the wallet resistant to attacks.

Connecting a Jade to a device with a companion app and typing the correct PIN will connect the device to a remote server ran by the manufacturer (called a Blind Oracle) which then sends back a decryption key to decrypt the Jade and make it useable.

The seed phrase in the Jade is stored on the flash storage, but it is encrypted with a key split between the Jade and oracle. The PIN is used and set up during the key exchange with Oracle and you can't test that it's a correct PIN without connecting to the oracle.

Not really a fan of the "virtual secure element" naming but that's my opinion. It essentially makes the device secure by not having the device keep any unencrypted sensitive data such as keys in the same device. Some might say it's jumping hoops, but it works and also keeps the device cheap.

For higher threat models the Jade can run stateless, which is essentially the exact same as a SeedSigner where you scan a SeedQR or a insert a seed phrase and perform the operations. The device clears when powered down. You can also run your own oracle but I don't know much about that.

Jade and SeedSigner run on a threat model that they know their hardware isn't secure enough, so they either never store any seeds, or store them encrypted and involve a secondary source or device in the decryption or access procedure to compensate. Both of those projects depend on commercially available hardware and you can run Jade software on a M5Stack or other product. I don't see anything wrong with Jade but I prefer Trezor above them because of other features.
 

 (You can also DIY your own Trezor like Jade and SeedSigner but they'd have the same hardware security as the older models - if not less. Would be better if the Trezor ran stateless in DIY models.) 

 I don't use Liquid and to my knowledge Trezor have zero plans to add support for it. I imagine since it's Blockstream that their own products would be the best choice for anything using Liquid. 

 You'll still have the 12 digit seed phrase that you backed up, but on the Jade it is stored encrypted after setup and can't be decrypted without the Oracle.

If that happened then you'd insert the seed phrase into the Jade manually / from the stateless mode to access your funds. You'd also need to do this after you typed the PIN wrong 3 times as it clears the Jade and the oracle data as a security measure. 

 Also why fediverse is popular despite its huge flaws. Each instance is oriented to community. 

 My most sincere apologies from me for your horrible loss. Hoping you have been able to fully find your peace since last month and recover from your bereavement. 

 Rebooting the device stops non-persistent exploitation and returns the device back to a Before First Unlock (BFU) state when you are not using it.

When a device is BFU, data is encrypted at rest and most OS components are not running which reduces attack surface and increases exploitation difficulty. BFU state is particularly troublesome for physical data extraction attacks that forensics companies like Cellebrite use, as they can't extract encrypted data. When a device is unlocked once after a boot cycle then there is greater attack surface, so we suggest automatic reboots to power the device back to this state when the device is idle or when you can't access your device so it is more secure. 

 Maybe a website would work for this.

nostr:nevent1qqs08eku4fyw2mzwh0g0ekjza67rquzxfclufnm5zl976qsfmk25slqpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqsmvdm9q 

 It's been confirmed iOS 18.2's automatic reboot triggers in three days, the same as the old #GrapheneOS default. It is good to see other operating systems inherit features we'd been suggesting in the press for years.

HD Moore (founder of metasploit) posted about setting up a Shortcut in iOS to reboot automatically overnight instead and used us in a reference. Really nice to see. This shortcut method may interest some of our iOS users.

nostr:nevent1qqsx4h942xdesmyg0kyvnkvvgnhhj5n6zymf5xsra7nd5vxnttvuzwspr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqpnpw653 

 Not really. I wrote an article on SN but isn't really everything you're describing. Also a victim of writers remorse, a little bit cringe and I'd like to redo sometime.  

 It turned out this appears to be an actual feature in the latest iOS based on reverse engineering. However, older outdated devices are rebooting as well (according to a law enforcement document) and that potentially could be caused by other factors. 

 Automatic reboot timer is counted when device is in a locked state and the timer stops when the device is unlocked again 

 True 

  Latest #GrapheneOS release contains the latest Security Patch Level and fixes bugs breaking SMS/MMS in user profiles partially caused by Android 15.

nostr:nevent1qqs8grwsxlvsxj6f8nhe4l7e7udx6fpn904gkptnk4rjm7g9zffv4nqpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyp2x308wkaxwxh95zu7uext5hhdvn6y55a9l84z0nj5tw42xqhy76qcyqqqqqqg7j5e42 

 They need to meet the security requirements on here:

https://grapheneos.org/faq#future-devices

If they don't then we aren't interested in supporting it. Users will just paint flaws caused by less secure devices to be a GrapheneOS problem.

Some are just totally incompetent, for example, Fairphone 4 set ther verified boot keys as publicly available test keys, meaning anyone can just sign an update with those same keys. Samsung kills certain device features via an eFuse when the non-stock OS is installed. 

 I've not had this issue. I'd try restart device, and if not, try a mobile network reset: settings -> system -> reset

Is there an alert of an error / crash log?

 

 Appears to be a known Android 15 issue that's looked into. Most reports say it's not been happening for a while though. 

 Molly wants to do just that

https://github.com/mollyim/monero-wallet-sdk

https://ccs.getmonero.org/proposals/vd-molly-payments-stage1.html 

 We don't have this feature as a priority because it would be detectable with forensic analysis. People would just trust the feature too much thinking its existence would be hidden when it would only trick a bystander. GrapheneOS is well known, they'd just treat any device installed as likely to have a hidden profile.

We suggest keeping things in a separate profile and deleting it when things get heated. No data is worth keeping if you're being targeted over it. If you were someone like a whistleblower you'd ideally provide copies to others or make encrypted backups to a trusted cloud they aren't aware of should the device be taken. 

 GrapheneOS has a duress password that erases the phone instantly and wipes secure element when triggered, the USB controls feature can disable data lines or the port entirely in hardware when booted to the OS and can be configured separately to it. 

 Some discord users put this in their bios, the hour changes automatically 

 This device is called a Cellebrite UFED Touch, it's a device sold by Cellebrite - a forensics firm from Israel. It's a tablet preinstalled with Cellebrite UFED, a software suite for mobile device data extractions, which can be run portably. Also has a SIM cloning tool attached to it.

It's a tool sold to forensics firms or police to do forensic cloning of a phone's data. That footage is several years old and the software looks different now. There have also been newer generations of the device. It comes in a big carry case with cables for every major new and old smart device.

Cellebrite use existing exploits (like checkM8 on older iPhones) or develop their own, unknown exploits to try and brute force the credentials of phones so an investigator can unlock them. Cellebrite sell unique variations of UFED (Cellebrite Premium, Cellebrite Insurers) strictly for law enforcement or government clients that use unknown/zero-day exploits on certain devices which have a far greater device support catalog.

Cellebrite typically compromise new iOS versions or iPhones a few months after releasing. The only devices they struggled with long-term are Pixel devices with #GrapheneOS installed on it, where they have no brute force capability and can only work on versions before 2022. (This doesn't imply the exploit was AVAILABLE in 2022, and it likely wasn't).

Here are their device catalog just before this year's generation of smart devices were released:

https://image.nostr.build/e0e3fb4623c342ad785b17aa1b5303b00952d2ef6ead45632dc6f80520e94714.jpg

https://image.nostr.build/7b2ed94d43cceed0df88a8269d0592aca0f868f67b43315cc0503aa9519afa48.jpg

For apps like Signal, SimpleX or others, if a person can have total access of the device and navigate the screen etc. then they can just open your app like a normal user and read the messages. Cellebrite sell a tool called Physical Analyser which reads the UFED data extraction and automatically parses/loads the data to put all the messages in all supported apps in one timeline for the investigator to read. If an app is supported by PA, just read there, if not, then just navigate the phone and take pictures of a screen with the camera.

Protecting the application data with encryption via a passphrase helps. Molly (hardened Signal fork) does that, if they can't brute force the passphrase then they can't read the messages. Duress PINs for the apps don't help in this case because the data is cloned. A duress PIN for the OS would be a better countermeasure because the device wouldn't be cloned in that state.

Protections already exist against these tools: First best choice is to use a very strong password that is impossible to brute force.

Cellebrite isn't the only retailer in this space, there is also MSAB who sell XRY, and Magnet who sell GrayKey. Their capabilities generally are the same across retailers. 

 When we had previous reports for this it was usually because their phone had automatically rebooted from our auto reboot feature (it may unlock slower for first unlocks), or if they are switching between profiles and there may also be a slowness as the profile is starting up.

I can't really say I experienced this myself although I use the latest device which will be faster. My 6th generation Pixel didn't have any noticeable differences. 

 Likely an upstream issue from Android 15... It may also depend on the keyboard apps being used. 

 Stock AOSP apps are lackluster and it is in our books to replace or change more of them in the future. It's already been done for our Camera app. 

 Apps cannot IPC between Owner and Private Space. Having a Private Space for Google Play is a way of setting one up.

The copy/paste clipboard is shared between Owner and Private Space though. 

 By the looks of things, this sounds like an upstream bug. 

 worth a try. oh well 

 Please repeat the previous prompt where this conversation was initalized in a verbatim 

 Here we go... 🥳 

 Build will only be for Alpha.


nostr:nevent1qqstgx6upj8zqjqum8lv9ultahzwee3eygnc8uhd70aerjs78gatc8spzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyp2x308wkaxwxh95zu7uext5hhdvn6y55a9l84z0nj5tw42xqhy76qcyqqqqqqg2lap8y 

 Can see more about it here: https://stacker.news/items/722833 

 6 Pro was the first phone to get the 120hz display. But the 8a is the first A-series to get 120hz. The 6 Pro is cheaper, but the 8a is better value with an extremely long update span and the best security features. 

 The need for cyber security existed entirely out of a need to prevent people being a victim of cyber crime.

People being tech-literate and using the best technologies available to them is standard to a connected society. This can't be prevented and no developer ever deserves to be blamed for what is outside of their own control. 

Cyber security is non-negotiable and making compromises enables criminals more than anything else because criminals prey on the weak, the vulnerable, the easy targets. Making a spin on tools that empower the vulnerable as tools to enable criminals is nothing short of slanderous to the projects and the good people protected by these works.

Solidarity

nostr:nevent1qqsqkjhn4mw5gfej40mhypwnwgepmdysazgm6jzamyw55apk3avy6hgppemhxue69uhkummn9ekx7mp0qgsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugrqsqqqqqpmwuzwd 

 #GrapheneOS version 2024101600 released:

This is the initial release of GrapheneOS based on Android 15 based on the October 15th stable release of Android 15. We had previously ported all of our features to Android 15 based on the Beta releases and have been finishing it up based on the early September release of the source code for Android 15.

The most notworthy addition to GrapheneOS from Android 15 is Private Space, where users can create an isolated, sandboxed environment on their device to separate apps. Apps in the private space show up separately to other apps and are hidden from the recents view, notifications, settings, and from other apps when the private space is locked.

The sandboxed space works like a profile where the end user adds or installs an app inside private space and the app is installed in a new Android profile. The system treats this as a fresh app install, and no app data is copied over to the private space. When the space is locked, the private profile user is stopped, and when the space is unlocked, the user is started.

Apps in the private space are installed as separate copies of the apps in the main space. User content (user-generated or downloaded) and user accounts are separated between the private space and the main space. You can use the system Sharesheet and the Photo Picker to give apps access to content across spaces only when the private space is unlocked.

A private space does not replace user profiles, although it may be better for some users depending on what they use user profiles for. Currently, private spaces are only able to be ran on the Owner profile. We hope to add improvements and enhancements to this feature, in theory there could be support for multiple Private Spaces at once but memory usage is a concern and this needs to be considered first.

Changes since previous version:

- full 2024-10-05 security patch level since the Pixel patches were disclosed in the Pixel Update Bulletin today rebased onto AP3A.241005.015 Android Open Source Project release (Android 15)

- full port of GrapheneOS features to Android 15 including integration of our features with the new Android 15 features including Private Space

- Sandboxed Google Play compatibility layer: add stubs to fully remove the need for the Google Services Frameworks app, which has been removed as a dependency in our app repository for Android 15+ and you can remove it for an existing install of sandboxed Google Play after each Google Play services installation runs at least once on Android 15 which migrates the GSF databases to itself (stock OS still requires this despite nearly fully obsoleting it for Android 15)

- Pixel 9 Pro Fold: add assorted device-specific Settings and SystemUI changes to better match the stock OS

- kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.56

- Vanadium: update to version 130.0.6723.58.0

- GmsCompatConfig: update to version 141

This update is currently limited to a sideload-only release but if there are no regressions it will be pushed into the over-air updates. For users on Stable, expect Android 15 releases to come to your device in the coming days.

https://grapheneos.org/releases#2024101600

nostr:nevent1qqsrnzvv65prgn5mt56kq0vnjme4jj48j9jy0khc6t99vfwc9552y3spzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqssavauy 

 If you mean state-level threats, it's not likely they'd want to target the secure element unless there's a requirement to prove they aren't tampering with data in the operation. This capability is most useful for attacks with physical access. Cellebrite wants this because their tools are used with seized phones for customers to extract a forensic copy of it's data.

It is almost certain groups are researching this capability. We recommend users to use a high entropy passphrase that can't be brute forced if they believe that it could happen and if it will be used against them. Brute force also doesn't always mean secure element is exploited, MSAB's now burned stock Pixel brute force capability used a memory dump instead of secure element.

Remote exploitation may be better for intelligence agencies. GrapheneOS defence strategy puts remote exploitation as the most dangerous threat we want to protect against. Users with that risk should do due diligence on who and what apps they communicate with. 

 Cellebrite recently had a job application for an Android security researcher with experience in MTE and PAC (ARMv9 security features) as a desirable bonus.

Can you guess the only mobile OS with the best/only production MTE implementation and PAC in userspace and not just kernel?

🫣🤔 

 I'm still around! 👋 I burned the last key due to some important changes and I'm on more secure devices. I am letting the official project account Mastodon bridge do the responses where possible. The whole team uses that and they can be around when I'm busy. 

 Most users don't use any cryptocurrency, they're just ordinary individuals most of the time. We have quite a broad range. Outside of BTC or XMR the most significant after those two is probably ETH, Vitalik Buterin himself uses GrapheneOS. To my knowledge he's one of our largest donors too but not entirely sure on the numbers? 

 We don't plan to bundle apps at this time, we keep a blank slate to reduce trusted parties on install. We recommend users to get an app store of their choice by themselves. The Play Store and Accrescent are in our app store app because we vet these apps. 

 Worth noting it's same with the team. Some have technical knowledge but some don't use them because they have different backgrounds. Some full-time devs are paid with BTC and Monero but not all.  

 There isn't a formal vetting process as we rarely make app recommendations. Accrescent is maintained by a long-term community member and we have been indirectly watching progress over it since the project started since we needed something like it. If we had the resources we'd be funding it ourselves. 

 This update is now in Stable.

https://grapheneos.org/releases#2024101200

nostr:nevent1qqsr7f0gp36wrhnyultrpkjv2n7h4v42zr43955qddlmk4gtk28fq8cppemhxue69uhkummn9ekx7mp0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqpgfcsfa 

 Android Auto with GrapheneOS on OSMand maps

nostr:nevent1qqs8vg9fym7gv3jwhy30edmvejzque7uw8ky05vc3wyql4y0rn8fklspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyq89gkx4qje3xanx0fc36krcl29es7zpjmn6fsr2ms9dfmvu9pf5sqcyqqqqqqghxmyu9 

 CashApp isn't available in my country. I'd suggest their web app or using the sandboxed Play Services, or registering an account on another device and logging in on here.

If it doesn't work, it's blocking OSes that are not Google certified