#GrapheneOS version 2024111700 released.

This update contains a lot of sandboxed Google Play compatibility later improvements, patches, and fixes upstream design 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


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/


#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


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


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


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


You'll still have the 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.


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.


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


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.


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.


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 and aren't affected by these attacks.


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.


Acresccent alpha has added some more apps to the repo.

Some of the new open source apps includes "Inter Profile Sharing" a FOSS third-party app meant for sharing files between other user profiles, "Just Video Player" a video player app with support for tons of encoding and file types, and "FlashDim" a robust configurable flashlight app with brightness controls.

More work needs to be done with Acresscent (as it is maintained by a sole developer) before more apps can be implemented at a large scale.


Acresccent alpha has added some more apps to the repo.

Some of the new open source apps includes "Inter Profile Sharing" a FOSS third-party app meant for sharing files between other user profiles, "Just Video Player" a video player app with support for tons of encoding and file types, and "FlashDim" a robust configurable flashlight app with brightness controls.

More work needs to be done with Acresscent (as it is maintained by a sole developer) before more apps can be implemented.


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.


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


Maybe a website would work for this.

nostr:nevent1qqs08eku4fyw2mzwh0g0ekjza67rquzxfclufnm5zl976qsfmk25slqpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqsmvdm9q


If the NSA[1], GrapheneOS[2], and Apple[3] all believe that rebooting your mobile phone regularly is something that protects your data, you might consider doing it more often. Shortcuts on iOS make this super easy to setup.

1. https://www.documentcloud.org/documents/21018353-nsa-mobile-device-best-practices&xcust=2-1-2330195-1-0-0

2. https://grapheneos.social/@GrapheneOS/112204443465440601

3. https://www.404media.co/apple-quietly-introduced-iphone-reboot-code-which-is-locking-out-cops/

https://media.infosec.exchange/infosec.exchange/media_attachments/files/113/467/285/641/330/104/original/ca5a8da970013e69.png


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.


The Punkt MC02 phone doesn't run GrapheneOS. It still runs a fork of Android 13 while #GrapheneOS is solely based on Android 15. MC02 is clearly using the LineageOS update client, not the GrapheneOS update client. It's problematic that some people think it's a way to get GrapheneOS.

MC02 appears to use an older version of our sandboxed Google Play compatibility layer, but they haven't kept up with our updates at all so they don't have the full app compatibility of GrapheneOS. We're unsure how much other code they used from GrapheneOS but it's not current.

There are many companies selling devices with GrapheneOS preinstalled. It's also very easy to install it on your own with https://grapheneos.org/install/web from a web browser on another device. MC02 isn't a way to obtain GrapheneOS preinstalled and GrapheneOS can't be installed onto it.

There's a lot of media coverage about the device including reviews where it's portrayed as running GrapheneOS. We weren't contacted by news publications about their stories/reviews. We would have been happy to correct misconceptions if we have been contacted about any of this.


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


iOS 18.1 added an implementation of the auto-reboot timer for locked devices we've been using in #GrapheneOS since June 2021:

https://chaos.social/@jiska/113447894119816217

This was one of our early generation protections against forensic data extraction. We added a lot more protections this year.

iOS 18.1 was released on October 28, 2024. This has nothing to do with recent news coverage where cops are blaming imaginary features for devices not staying in After First Unlock state. Devices likely crashed due to one of many bugs which exist, including already patched ones.

The fantastical theories about iPhones communicating with each other about being kept without cellular access and rebooting based on what they were told by other phones do not check out. It doesn't make sense. Law enforcement have the capability to host properly signed cellular and produce cloned SIM cards that provide the same metadata but limit cellular network access.

It wouldn't make sense for Apple to deploy such as strange and insecure take on it. They've deployed essentially the same feature we use in iOS 18.1, although we aren't sure when they enable it. We enable our auto-reboot feature by default with an 18h timer, which used to be 72h.

Our auto-reboot implementation builds upon our other hardening which protects the device. We use default enabled hardware-level + software-level disabling of USB-C data while locked, default enabled aggressive use of hardware memory tagging in a hardened allocator and a lot more.

Our USB-C port control feature and hardware memory tagging are examples of features built on hardware-specific features. Hardware memory tagging is near exclusive to Pixels, but the stock OS only has it as a developer option for finding bugs with a weaker implementation and bugs.

We proposed auto-reboot, USB-C port disabling, reset attack mitigation and wipe-without-reboot as features to Google in January 2024. They implemented part of our reset attack mitigation proposal for Pixels in April 2024 and wipe-without-reboot in June 2024, but not the others.

We've made a lot of proposals and vulnerability reports to help improve Pixel and Android security but they don't always listen to us. Perhaps they'll add auto-reboot now that Apple shipped something, although as we said above we don't know if it's lockdown mode exclusive, etc.

Apple and Google have much weaker forms of USB attack surface reduction than our approach. It's also not enabled by default for either. We designed the default balanced security vs. usability mode of "Charging-only while locked" to avoid disrupting almost any real world use case.

We use support in the Pixel USB-C controller for disabling new USB connections but keeping existing ones working. As soon as there are no active connections, data is disabled. People who want more security can make it stricter and even disable charging to block USB-PD exploits.

We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (https://grapheneos.org/faq#future-devices) and we expect it could be implemented for Snapdragon too but it's missing hardware memory tagging and devices using it are missing far more...


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.


Latest #GrapheneOS release fixes a contact scopes compatibility issue that breaks apps like WhatsApp caused by the latest Android security patches.


True


GmsCompatConfig version 148 released:

https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-148

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/17141-gmscompatconfig-version-148-released

#GrapheneOS #privacy #security #gmscompat


New OP_RETURN
Thanks for GrapheneOS
https://mempool.space/tx/8d39d01104020e9d6ebc9ef34fe1adb26f6264913df01588b0ad02f4ff9b11c1


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 won't lie, my older articles make me cringe.


 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


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


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.


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?


Simple Crypto Widget is now Material 3! Good time to have widgets since #GrapheneOS patched the upstream bug of widgets disappearing in user profiles ;)

https://github.com/hwki/SimpleBitcoinWidget/releases/tag/btc-8.6.0


Molly wants to do just that

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

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


#GrapheneOS device deployment and management was mentioned in the requirements for a director-level job vacancy in a large (multi-million) NGO about wildlife and environment preservation. Their overall security commitments outside of their mobile security demands is also very impressive.

https://image.nostr.build/1f5a43c393de180f0d007718fb81b9fb1327cc6ab93cc4cc669c33fdc6f98da0.jpg

It is great to see big organisations with big requirements choose GrapheneOS because they know we provide security and privacy other platforms do not have. For too long users with tougher security requirements were left in the dark because every commercial OEM is often thinking about seamlessness or user experience. Users should have the choice to go above.

Let it be a message to every exploit broker and mercenary who tries to use our name / the platforms we support for marketing an urgency to attack our work: You cannot claim your actions to be for the greater good. You want to target a project that protects people in organisations campaigning for a cause far more important than yours. GrapheneOS works for good while you arm oppressors who work against causes like the ones above.

The security community's greatest principle is transparency and you can't claim yourself to be trailblazers when you keep research a secret and we will continue our work in spite.


#GrapheneOS device deployment and management was mentioned in the requirements for a director-level job vacancy in a large (multi-million) NGO about wildlife and environment preservation. Their overall security commitments outside of their mobile security demands is also very impressive.

https://image.nostr.build/1f5a43c393de180f0d007718fb81b9fb1327cc6ab93cc4cc669c33fdc6f98da0.jpg

It is great to see big organisations with big requirements choose GrapheneOS because they know we provide security and privacy other platforms do not have. For too long users with tougher security requirements were left in the dark because every commercial OEM is often thinking about seamlessness or user experience. Users should have the choice to go above.

Let it be a message to every exploit broker and mercenary who tries to use our name / the platforms we support for marketing an urgency to attack our work: You cannot claim your actions to be for the greater good. You want to target a project that protects people in organisations campaigning for a cause far more important than yours. GrapheneOS works for good while you arm oppressors who work agsinst causes like the ones above.

The security community's greatest principle is transparency and you can't claim yourself to be trailblazers when you keep research a secret and we will continue our work in spite.


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.


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


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.


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.


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


#GrapheneOS version 2024102400 is out. It brings back the a stricter DNS leak block that was previously reverted due to it breaking a lot of popular VPN apps (notably Proton VPN). An additional fix was made for the VPN DNS routing to prevent the compatibility issues from before. The ancient Android bug to do with widgets in secondary users disappearing have also been fixed by us.

IMPORTANT NOTICE that only affects a small amount of users: Apps which were only installed in secondary users but not Owner before updating to Android 15 and which were then installed in Owner after updating to Android 15 will have a one-time revocation of their Network/Sensors permissions after updating to this release as a minor consequence of migrating them from Android 14 again. If you installed an app, check those permissions!

Changes since the 2024102100 release:

- switch back our original stricter approach to DNS leak blocking from our [2024050900](https://grapheneos.org/releases#2024050900) release with an additional fix for an Android DNS routing bug causing requests to the VPN DNS servers to be routed incorrectly, which should avoid the compatibility issues experienced with certain VPN apps when we tried to ship it before
- avoid resetting Network or Sensors back to the global default after app updates in a specific case when migrating the state from Android 14 or earlier
- add an extra one-time migration of Network and Sensors being disabled in Android 14 to Android 15 to work around an issue with the previous migration of the permission state which occurred for some users with some of their apps
- fix ancient Android bug causing widgets to disappear from the user's home screen when the user stops, which was a major usability issue for secondary users
- Keyboard: extend fix for upstream layout bug in landscape mode to fully fix it for 3-button navigation in addition to the default gesture navigation
- Gallery: fix upstream cropping activity bug when both the input and output URI is the same to fix setting profile pictures for user profiles
- raise backup service transport (Seedvault) timeout from 10 minutes / 5 minutes to 60 minutes / 30 minutes to handle very large backups, particularly for the device-to-device mode which includes nearly all app data
- temporarily revert enforcing minimum 64kiB stack guard size for arm64 since Facebook recently included a buggy stack overflow check for the React Native Hermes runtime that's incompatible with larger gap sizes and beginning to be shipped by apps (revert was not applied for Android 15 port)
- Sandboxed Google Play compatibility layer: add stubs for update_engine wrapper API to avoid potential Play services crashes if the existing approaches to disable the update service fail
- Pixel 8, Pixel 8 Pro, Pixel 8a: disable Wi-Fi HAL debug logging to avoid memory corruption caught by hardware memory tagging on GrapheneOS
- kernel (6.1): update to latest GKI LTS branch revision
- use hardened GrapheneOS 6.6 LTS kernel for microdroid virtual machines for both arm64 and x86_64
- Vanadium: update to version 130.0.6723.73.0
- GmsCompatConfig: update to version 145

https://grapheneoss.org/releases#2024102400


#GrapheneOS version 2024102400 is out. It brings back the stricter DNS leak block that was previously reverted due to it breaking a lot of popular VPN apps (notably Proton VPN). An additional fix was made for the VPN DNS routing to prevent the compatibility issues from before. The ancient Android bug to do with widgets in secondary users disappearing have also been fixed by us.

IMPORTANT NOTICE that only affects a small amount of users: Apps which were only installed in secondary users but not Owner before updating to Android 15 and which were then installed in Owner after updating to Android 15 will have a one-time revocation of their Network/Sensors permissions after updating to this release as a minor consequence of migrating them from Android 14 again. If you installed an app, check those permissions!

Changes since the 2024102100 release:

- switch back our original stricter approach to DNS leak blocking from our [2024050900](https://grapheneos.org/releases#2024050900) release with an additional fix for an Android DNS routing bug causing requests to the VPN DNS servers to be routed incorrectly, which should avoid the compatibility issues experienced with certain VPN apps when we tried to ship it before
- avoid resetting Network or Sensors back to the global default after app updates in a specific case when migrating the state from Android 14 or earlier
- add an extra one-time migration of Network and Sensors being disabled in Android 14 to Android 15 to work around an issue with the previous migration of the permission state which occurred for some users with some of their apps
- fix ancient Android bug causing widgets to disappear from the user's home screen when the user stops, which was a major usability issue for secondary users
- Keyboard: extend fix for upstream layout bug in landscape mode to fully fix it for 3-button navigation in addition to the default gesture navigation
- Gallery: fix upstream cropping activity bug when both the input and output URI is the same to fix setting profile pictures for user profiles
- raise backup service transport (Seedvault) timeout from 10 minutes / 5 minutes to 60 minutes / 30 minutes to handle very large backups, particularly for the device-to-device mode which includes nearly all app data
- temporarily revert enforcing minimum 64kiB stack guard size for arm64 since Facebook recently included a buggy stack overflow check for the React Native Hermes runtime that's incompatible with larger gap sizes and beginning to be shipped by apps (revert was not applied for Android 15 port)
- Sandboxed Google Play compatibility layer: add stubs for update_engine wrapper API to avoid potential Play services crashes if the existing approaches to disable the update service fail
- Pixel 8, Pixel 8 Pro, Pixel 8a: disable Wi-Fi HAL debug logging to avoid memory corruption caught by hardware memory tagging on GrapheneOS
- kernel (6.1): update to latest GKI LTS branch revision
- use hardened GrapheneOS 6.6 LTS kernel for microdroid virtual machines for both arm64 and x86_64
- Vanadium: update to version 130.0.6723.73.0
- GmsCompatConfig: update to version 145

https://grapheneoss.org/releases#2024102400


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


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.


#GrapheneOS fully supports the Private Space feature in Android 15, which is essentially a separate user nested inside of the Owner user.

We strongly recommend it as a replacement for a work profile managed by a local profile admin app. It has better OS integration and isolation.

Private Space is an isolated workspace (profile) for apps and data similar to both user profiles and work profiles. All 3 forms of profiles also have entirely separate VPN configuration which is very useful even if you connected to the same VPN, since exit IPs can be separate.

All forms of profiles have separate encryption keys. You can keep a Private Space at rest while the Owner user is logged in just as you can with a secondary user.

Private Space makes it easier to share data than users. The clipboard is shared, but we could add a setting for it.

GrapheneOS users choose to use the OS in different ways. A lot of people largely use open source apps and not sandboxed Google Play. Others use sandboxed Google Play in their main profile. Many use sandboxed Google Play in a dedicated profile to choose which apps use it.

Regardless of how people choose to use sandboxed Google Play, they're regular sandboxed apps without special access. Private Space makes it easier to use a dedicated profile for sandboxed Google Play though.

It's also worth noting you can still use a work profile alongside it.

All of our features including Contact Scopes, Storage Scopes and sandboxed Google Play have full support for Private Space. We added support for it significantly before the release of Android 15, even before the initial early release of the source code was published in September.


#GrapheneOS: We've finally fixed the ancient Android bug causing widgets/shortcuts to disappear in secondary users when switching away from them. It will be included in our next release. This issue impacts every Android-based OS with secondary user support and was a major usability issue.

We've also fixed 2 more Android 15 regressions in AOSP. AOSP Gallery had a long time bug in the cropping activity which started breaking setting profile pictures for users in Android 15. We also extended our AOSP keyboard landscape layout fix for the legacy 3 button navigation.


worth a try. oh well


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


I can't believe I am still seeing this be suggested as advice in some places, but, no, Signal does not contaminate digital evidence / attack forensics machines. Do not use apps claiming they can make attacks for these tools.

For some background: In April 2021, Signal got a hold of a Cellebrite UFED kit, a software package designed to create forensic clones of data for smartphones. Signal found a remote code execution vulnerability in UFED and made a snarky joke about leaving files designed to exploit the vulnerability on phones with Signal installed that were designed to exploit the vulnerability.

They didn't actually do this, it was a joke, and it wouldn't work. Cellebrite is a multimillion security company, they have the budget and skills to patch.

DO NOT ALLOW YOUR DEVICE TO BE ACCESSED JUST BECAUSE YOU THINK SOME APP WILL STOP IT.

- Cellebrite patched the vulnerability.

- Other retailers like MSAB support Signal in their products, so even if there was an RCE in one tool, another tool would be used instead.

- Giving away your password just because you think the evidence would be tampered is silly. They still have access to your device.

Some other apps you shouldnt rely on are apps that do duress features like Wasted or concept anti-forensic tool apps like LockUp.

For duress apps relying on a device admin like Wasted, the stock OS factory resets on almost any other device that are caused by admin apps can be bypassed by holding the volume down button to fastboot or recovery, effectively cancelling it. GrapheneOS Foundation is on the CVE for this. GrapheneOS duress erases before reboot so you cannot do this bypass.

Remote erasure apps also don't work if you're concerned about users with tools like this. It is common forensics practice to immediately airgap devices with a faraday bag, removing SIM and enabling airplane mode (where possible) to prevent this situation.

Apps like LockUp triggering resets based on detecting tool activity, file hashes and signatures are a temporary, flawed solution

- The companies routinely research these apps and will just change known hashes or signatures if they are found out.

- It uses device admin, so can be bypassed the same way as Wasted.

- LockUp was designed by a security researcher to assist Cellebrite and patch vulnerabilities. It's not been updated in years. Cellebrite gives credit in their changelogs for the disclosure to the authors.

LockUp gets recommended in some space as an app to protect you, but you shouldn't use it. Not even the developer says you should because it's a proof of concept for a vulnerability disclosure.


Here we go... 🥳


#GrapheneOS based on Android 15 will reach the Stable channel later today. It's very stable already and we've fixed a bunch of upstream bugs including several impacting the stock Pixel OS. We've made 7 official releases based on 15 already and the 8th is going to reach Stable.

We normally would have had it in the Stable channel already. We've been quickly fixing all the significant issues as they've been reported, but people kept reporting new ones afterwards and they've been past what we consider significant enough to delay the release until today.

An AOSP keyboard app layout issue was reported today where in landscape mode the right side is slightly cut off but still remains usable. We could push out the current release to Stable, but we've resolved this and we're building another release so we'll very likely wait for it.

We're capable of pushing out a fix for the keyboard app issue via our App Store. We're currently considering which option is best while we build the release. It's too bad this didn't simply get reported yesterday in which case the release would already be in the Stable channel.


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


Build will only be for Alpha.

nostr:nevent1qqstgx6upj8zqjqum8lv9ultahzwee3eygnc8uhd70aerjs78gatc8spzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyp2x308wkaxwxh95zu7uext5hhdvn6y55a9l84z0nj5tw42xqhy76qcyqqqqqqg2lap8y


I've not posted changelogs for today's update as there will be more updates for Android 15 fixes as they come including another update today/tomorrow. Would spam the feed.

Most users will not get the Android 15 updates yet as it is exclusive to Alpha release channel so testers can provide feedback on fixes with AOSP bugs.

Some improvements also need to be made to Private Space. It needs to be worked on further to be more useable to GrapheneOS users, like an install available apps feature similar to user profiles. Private Space was only designed for installing apps from the OS source so it ends up opening the GrapheneOS App Store or Play Store for now, would need to get APKs manually, may be a problem to some.

Private Space also can't transfer files from Owner to Private Space (other way around is fine) which is a regression. Additional work needs to be done.

Here is how the Private Space feature looks so far. This footage belongs to tuxsudo, a Cake Wallet contributor.
 https://image.nostr.build/3940b2b6978e5629db0e29f36c23e4e0ef17e21c93ca1a3d84b343964a3bed91.jpg

Check out his thread for more, note this is footage from a sideload-only pre-Alpha build of GrapheneOS and regressions in this thread have or are currently being addressed in following updates. If you are a normal user then you do not have this feature yet.
 https://xcancel.com/tuxpizza/status/1846494168496959667#m


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


Final

Still fighting. Security researcher and engineer, contributor #GrapheneOS. Npub used for post comments and support.

Different key? Burned my last npub. See first note for verification.


Stacker News is going noncustodial!

- Zaps to me aren't affected, transactions to final@stacker.news always attached to my own external wallet. Sending to there sends to final@minibits.cash.

- regardless, I have replaced the zap address on my Nostr page.

- Yes, I accept ecash now. #Nuts!


Not usually something I like to post about, but I was waiting for a Material 3 UI Notes App for a long time.

Then I found this app: https://image.nostr.build/ed3abbd7ae3e6381ebf516776ba26b83f692045f0451671af7adb489c751d3f6.jpg

Text formatting, exports to Markdown and JSON, media support, and encrypted backups. I've personally wanted an app like this for a long time. Other apps are either text editors or are very dated.

Apps like these fit extremely well into #GrapheneOS and I have a soft spot for them. I hope the developer continues working on it.

Check it out: https://github.com/maelchiotti/LocalMaterialNotes


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.


New key for nostr:nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnv0md0, give him a follow if you want updates on GrapheneOS.

nostr:nevent1qqs99ufgxxxd33ennrmlwjqjjpd7zrtszftdnmsn8yzu6a3aehhgtccpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqp9dea0e


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.


#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


Our initial #GrapheneOS release based on Android 15 is now available for early testing for technical users willing to sideload the release to their device. It's a regular production release and this can be done on a locked device with USB debugging disabled, but it's not heavily tested yet.

If you're interested in helping with either the early testing via sideloading or regular public testing via our Alpha and Beta channels, join our public testing chat:

https://grapheneos.org/contact#community-chat

You can choose between Matrix, Discord, IRC or Telegram. Most people use Matrix or Discord.


Initial Android 15 release for GrapheneOS looking good so far. OS builds are built for 6/15 devices and counting. Hope to have a release out soon.


Big day for GrapheneOS coming.


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?

🫣🤔


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.


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


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.


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.


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?


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.


This update is now in Stable.

https://grapheneos.org/releases#2024101200

nostr:nevent1qqsr7f0gp36wrhnyultrpkjv2n7h4v42zr43955qddlmk4gtk28fq8cppemhxue69uhkummn9ekx7mp0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqpgfcsfa


New change to #GrapheneOS website.

You can now see which device has which releases in Alpha, Beta, and Stable channels. This let's you know what release you'll be on depending on the channel you used.

https://grapheneos.org/releases


Facebook shipped buggy stack overflow detection in the Hermes JavaScript engine used by React Native:

https://github.com/facebook/hermes/issues/1535

It breaks when the default stack guard is 64k instead of 4k. The standard 64-bit ARM Linux ABI requires 64k. So far only 1 person noticed a broken app.

We're going to be temporarily reverting a change in today's release of #GrapheneOS before Facebook's broken code reaches more apps. We tried lying to apps about the stack layout to hide this change but that breaks compatibility much more. We'll have to detect the Facebook library instead.

Not particularly important since we weren't planning on switching to standard 64k stack probes instead of 4k stack probes to avoid risk. However, it's nicer if it's larger to cover 3rd party code without stack probes. Very minor compared to other things blocked by app compat.

The main feature that's blocked due to third party app bugs is enabling hardware memory tagging by default for all user installed apps. That works fine but catches many memory corruption bugs. We might put the toggle into the setup wizard so that most users end up enabling it.

We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.

We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.

Enabling ShadowCallStack for Vanadium worked well but caused issues with WebView-based apps, likely due to anti-tampering code. This would be nice even on the recent devices with PAC and MTE until we have stack allocation MTE enabled... which is blocked due to app bugs for now.


Android Auto with GrapheneOS on OSMand maps

nostr:nevent1qqs8vg9fym7gv3jwhy30edmvejzque7uw8ky05vc3wyql4y0rn8fklspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyq89gkx4qje3xanx0fc36krcl29es7zpjmn6fsr2ms9dfmvu9pf5sqcyqqqqqqghxmyu9


TLDR: Tech 'journalism' sensationalizing something that happens on every other Android device to be a Pixel 9 issue to scare people away from Pixels into less secure platforms.


GrapheneOS statement regarding a highly misleading and inaccurate article from Cybernews about the Pixel 9 'phoning home'

https://discuss.grapheneos.org/d/16338-highly-misleading-and-inaccurate-article-from-cybernews-about-the-pixel-9


Tor Browser users, please update your browser.

https://blog.torproject.org/new-release-tor-browser-1357/

Latest update patches a remote code execution vulnerability confirmed to be exploited in the wild.


Also, this is outdated and we published the July version as well. These docs don't reflect newer iOS versions or iPhone 16


We're the ones who published these documents on the GrapheneOS social media account.


New GrapheneOS update out now folks. Contains this month's security patch level and some fixes with memory tagging by patching some Android memory bugs.

nostr:nevent1qqsvvwunwpzx4492p3j3vx0t5vw78mk943f7nsz9awh3pd4pfngtg8gpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyp2x308wkaxwxh95zu7uext5hhdvn6y55a9l84z0nj5tw42xqhy76qcyqqqqqqg9x7e5q


GrapheneOS features don't just stop exploitation of vulnerabilities, but uncovers potential vulnerabilities in apps.

nostr:nevent1qqsdhlnf5ezmjkdvc08gdmljex320jh5etyyxxcdlfazgmx8ppsmjaspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyp2x308wkaxwxh95zu7uext5hhdvn6y55a9l84z0nj5tw42xqhy76qcyqqqqqqgtw6and


That npub was burned, I don't use that one anymore.

(Check GrapheneOS forum profile for npub so you don't click a sketchy from me.)

It's not something we come across, but we are aware Orbot has some problems, that's why a Tor VPN app is being redone (not by us) in the future.

We are aware of leaks caused by some VPN apps and we keep making patches to fix it but they end up breaking said apps and force us to revert. It's predominantly an app issue, look at the posts on my old npub about Mullvad to get what I mean here.

Latest build added a second-generation leak prevention mechanism but for it's for multicast leaks: https://grapheneos.org/releases#2024092900

I'd contain Tor usage in its own profile so I don't see this happen. I guess if it happens right when Orbot is connecting, give it a few seconds after connecting before doing something?


Top of Stacker News, thank you so much.


#GrapheneOS: The Purpose, The Strategy, and The Why [Article]

This post explains a bit about the development approach, reasoning and strategy behind GrapheneOS security innovation and how power users protect themselves.

On SN: https://stacker.news/items/705242


cc: nostr:nprofile1qqsyawyrzrttfmv4cmtx5w2m85702kdct7hv3amfrkhagpdf9cz46mgprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpydmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef08ankcmmzv9kr6ctvds20l3q3 believe I mentioned making a post like this to you before, here it is.


Using an app that locks with the OS credential  like Phoenix Wallet in GrapheneOS allows you to trigger the device duress password when starting the app because the duress feature also extends to any OS credential input. This doesn't extend to apps exclusively doing their own implementation of a PIN though.


The older generation face scanning hardware was far more robust and secure and the current face unlock options are far less.


RE: Chainalysis

Companies targeting users of cryptocurrencies like Blockchain analysis firms being a fan of the tech would be expected. I would expect they use it on a daily basis and would know more about it than the typical maxi would. In conferences i've met FBI digital forensics lab staff who hold Bitcoin because of learning more about it during seizures.

We have a similar two-faced relationship with forensic companies who try and target GrapheneOS and the Pixel platform.  Hate that we do whatever we can to break their capabilities but some definitely use GrapheneOS because they are impressed by the security offerings. I also find some of their tools interesting. Chainalysis is a very well made application.


Didn't have the zap address back, only the NIP-05 (which is the same as the zap address)


What would you want to see in a post about #GrapheneOS? Preferably something you've not seen in posts before. I want to be unique here. Is there a feature you want to understand the technical details about? Maybe a justification on X? Would be inrerested to know.

nostr:nevent1qqsrk40h6yrmwsm7lmgjylpulecz3khpy8yncp8havkkulglvcql9rspzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqstru8hv


Believing they are using the literal definitions to base their statement here... For data to be uncensorable it needs to be known and distributed to everyone. Online privacy is about reducing, hiding, or anonymizing data so it's not known. Some privacy techniques involve self-censorship.

You can use censorship resistant platforms with privacy technologies like onion routing to make the connection between your identity and the platform private, but what you create on the platform is never private.


If a nation state had been in my old phone I'd almost consider it a compliment because I am fucking boring 🫡


Every time a GrapheneOS post trends on SN I feel like delaying my big post I promised a year ago because I don't want to oversaturate the trending with the project. Suffering from success...


Wasn't really something I looked into since it was extremely unexpected. Also up to believe official GrapheneOS platforms would suffice in announcing my key change. I dont want to spread fear by people misunderstanding a personal and isolated incident as a GrapheneOS one.


All the text the LLM produced are just explaining the default features of Android (secure boot, disk encryption, data collection etc). Doesn't go into the features of any of them. Also some features like "secure boot" (likely means Verified Boot) depends on device support. Replicant definitely doesn't have that.

Id look at: https://eylenburg.github.io/android_comparison.htm


That would be the standard procedure, but circumstances about the event meant I couldn't. Users should announce change of keys if able to.


I didn't put the links as some people may have thought links may be phishing (IF YOU DO, GO FIND MY PAGES ON A SEARCH ENGINE INSTEAD! DONT TRUST ME!)

BUT, if you kinda trust me:

Official GrapheneOS forum page: https://discuss.grapheneos.org/u/final

My stacker.news page:
https://stacker.news/final

All zaps are going to the original address the old npub has as you can see on my profile so I earn nothing doing this if I was a real faker anyway.


how im looking today
 https://image.nostr.build/e32bccf36796b26d7877f8bccdee568d20406e2018f1c136c27e39f3ee5e38f4.jpg


I understand. I imagine I have really annoyed a ton of people but oh well.

Key pairs for Nostr are great for verification but are a disadvantage towards certain security measures. Nsec is only as secure as the app that generated it and is only as secure as the least secure platform you stored/used it on. Takes a lot of responsibility, which I'm fine with, but most people aren't.

If you want to change security requirements (like me) you likely need to burn your key... I guess it's no different to PGP keys that expire on a set time but I'd really be waiting for a dedicated secure hardware signer before I ever share my Nostr nsec keys on any other app or device... and id probably also rotate my keys again if a device existed.


He has bursts of being quite busy.


1. npub is burned, can't post what I don't have the keys for.

2. Official GrapheneOS forum page: https://discuss.grapheneos.org/u/final

3. https://stacker.news/final

Trust me or not, it's up to you. All zaps are going to the original address the old npub has as you can see on my profile so I earn nothing doing this if I wasn't who I'm claiming to be.

You're free to contact another GrapheneOS team member.


Metroplex: nostr:nprofile1qqsyxcm6xydptuwz2w6avpmc4d65ftrrnwywz688yf9fqr22gy5rrqcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtc9zjrax

He was in Nostr before I was.


1. npub is burned, can't post what I don't have the keys for.

2. Official GrapheneOS forum page: https://discuss.grapheneos.org/u/final

3. https://stacker.news/final

Trust me or not, it's up to you. All zaps are going to the original address the old npub has as you can see on my profile so I earn nothing doing this.

You're free to contact another GrapheneOS team member.


#plebstr #nostr #newstr (winks)

nostr:nevent1qqs8d4xg7f0fyfl29wjfxyest6fshsy7x2te298cfs2xj7sema4zh7cpz4mhxue69uhkummnw3ezummcw3ezuer9wchsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqspt0sq8


Hi all, Final from #GrapheneOS again.

Due to an extraordinary event (not a breach!) and a change causing me to up my security requirements, I have burned the previous npub I used. This is my new npub. My security requirements are above people's conveniences, I apologise for these inconvenience but I don't regret necessary actions either.

- I will use this npub for post comments and support.
- I will refrain from constant GrapheneOS reposts as Mastodon bridges fulfill that space. Rest of the team can also USUALLY see posts there. I believe I should be more diverse in my content here.
- In short, less GrapheneOS, and more Final.

I can be verified using the original Stacker News account (final) NIP-05, Bio and LN address.

I can be verified via the GrapheneOS discussion forum user page (final). You may also verify me in any official GrapheneOS platform you wish.

Thank you for the support.

-- final


Relay list to discover the user's content