If she has followed the install guide properly and her phone shows a yellow "Your phone is booting an alternative operating system" page, then her bootloader is locked already. Fortunately this is already in the instructions π
Also make sure to consult the usage guide:
Your app choices are up to you. Some use the normal play store apps via Sandboxed Google Play while others do not. I can't make choices for you of course, it's up to your preference.
If you downloaded an APK from a website check your file manager in the Downloads folder for the APK of the app that you downloaded. If the app tells you it cannot install unknown apps, click the Settings button and allow it π
Then do the above, the option should appear there!
Assuming this is about OEM unlocking?
Developer options should appear after tapping Build Number 7 times in Settings -> About phone
We are hopeful that the April security updates following are likely the ETA for the upstream fixes to the firmware/OS for vulnerabilities we reported to Google in January that affected the stock operating system.
We had already done our own work after our disclosure from auto-reboot improvements, USB port controls and other additional hardening these past few months despite the ineffectiveness of the vulnerabilities against GrapheneOS. The hardening done would increase difficulty of exploitation to perform data extraction of a device in an AFU state by a threat actor with physical access. USB controls would also likely throw off a prepared actor who had prepared to exploit ASAP to prevent an automatic reboot from occuring.
Having an upstream fix is great as it would disrupt these threat actors further and help people not using GrapheneOS, it also makes our current work more complete.
#GrapheneOS version 2024032100 released:
This is a larger update containing a lot of fixes for apps or apps using libraries that are breaking with Android 14 QPR2. The temporary Bluetooth compatibility toggles have also been removed as Bluetooth devices should be fixed.
See the changes:
- Bluetooth: revert broken upstream change and changes depending on it to fix Galaxy Watch 6 Classic and likely other devices impacted by the same issue (this was a failure of upstream testing and release engineering for AOSP and doesn't impact the stock Pixel OS because it uses a different APEX module revision branched from an older revision of AOSP but it will impact every other AOSP-based OS on Android 14 QPR2 since there isn't a Bluetooth mainline module published in the Play Store and AOSP yet)
- Android Runtime: disable stripping symbols for libart to restore compatibility with many obfuscated Chinese apps using a specific obfuscation SDK which was broken by Android 14 QPR2 when not using the mainline ART module due to the mainline module being based on an older codebase
- Android Runtime: remove Android's hard-wired speed-profile compilation for launcher apps which was limiting ahead-of-time compilation for user installed launcher apps to the parts of the code included in baseline and/or cloud profiles rather than compiling the whole app via our default speed compilation which we use to replace JIT compilation and JIT profiles guiding background AOT compilation
- backport 12 upstream fixes from the mainline MediaProvider, Wifi, NetworkStack and HealthFitness APEX modules
- allowlist using device controls quick tile when unlocked since it already has a toggle for controlling availability so our new default requirement of the device being unlocked needs to be overridden for it
- revert disabling hardened_malloc for Broadcom Bluetooth HAL (does not appear to be a memory corruption bug found by GrapheneOS but rather the stock OS is using an older Bluetooth module without the issue)
- revert allowing users to disable Bluetooth for Bluetooth system app (does not appear to be a memory corruption bug found by GrapheneOS but rather the stock OS is using an older Bluetooth module without the issue)
- more complete setup design configuration to improve appearance of Setup Wizard, etc.
- Settings: fix upstream footer formatting issue for App pinning screen
- update timezone module to Android mainline 341510010 (based on tzdata 2024a)
- kernel (5.15, 6.1): improve support for hosting servers by enabling SYN cookies as we do for the older kernels
- kernel (6.1): drop obsolete usage of YAMA which we replaced with our dynamic SELinux flag extension
- kernel (5.10): update to latest GKI LTS branch revision
- GmsCompatConfig: update to version 99
Will answer all of your questions/replies here:
You can switch between Stock and GrapheneOS without issues but you will lose data every time you do this, it's up to you to back up your data. The install page shows how to start going back to Stock.
Magic Eraser is a feature from the photo editor rather than the camera. You can use Google Photos on GrapheneOS but it has a hard dependency on GSF so you need to install the sandboxed Google Play apps. A lot of their editing also requires internet access and is done via cloud.
All apps on Android are sandboxed (that's why you can control permissions of apps) but GrapheneOS improves that sandbox (Storage Scopes, Contact Scopes, Network permission toggle) and runs a compatibility layer to allow Google Play services or apps to run in an unprivileged, sandboxed manner. LineageOS doesn't make any improvements, and many changes they make from AOSP have flaws, it is not hardened.
The Play Services being sandboxed means they are placed in the same sandboxes that other user installed apps would have. What the apps see entirely depends on what you allow via the permission controls. If you are concerned about app communication then use a user profile to separate.
The sandboxed Google Play apps cannot see installed apps by themselves, but, if you are using Play Store to get them then it is likely they'd get an idea. If an independent app includes Google connections or services within them then that is a separate matter. Some also work without it, Firebase Ads and Analytics is an example of a library that works without Google Play services.
This comment would help
https://stacker.news/items/464619?commentId=466680#
I'd 100% be thrifting an old phone to get money for a signing device if I were only using an older unsupported phone just for that. Although I definitely consider GrapheneOS reasonable for *warm* higher-value assets. I'd store more on a GrapheneOS device than I ever would on any other phone, providing I was using all the security features and setting it up in a dedicated profile.
I can't assess apps like Samourai in detail, I do mobile security not Bitcoin, but admittedly I have researched them when making this comment: https://stacker.news/items/464619
They were one of many wallet apps that was a target of mobile forensics research I did in the distant past as well. This was long before my affiliation with GrapheneOS and this is not GrapheneOS work though.
A lot of wallet apps have security modelling relying on the security baseline of the device and OS the app is running on, if they get enough time to move funds away during or before compromise then the wallet did it's job in protecting funds. That is also explicitly Samourai's aim. Physical compromise or sophisticated remote compromise could trivially clone an app's data and brute force the PIN, but on a up-to-date secure device this is difficult, especially one running GrapheneOS. If you're targeted this hard and this detailed there is much there's a lot worse to worry about.
This time would be enough to move funds to a new wallet just on its own. Would be nice to see further improvements like passphrases and stronger key derivation with Argon2 if they don't plan or do it already to further slow them down, but at that point it's just adding additional small frills and isn't important.
Comments on Stacker News about mobile OS security, GrapheneOS and use of GrapheneOS with cryptocurrency wallets. May be useful.
https://stacker.news/items/464619/r/final?commentId=466606
Try using the exploit protection compatibility mode too.
Note some apps may break due to the transition to Android 14 QPR2. App developers need to do their due diligence and make sure their apps work for it, these are *major* quarterly updates. We haven't done anything to change this ourselves...
Do you have Obtainium installed on another profile? App updates go to all profiles at once. You'd get an error if you may be installing an app you installed on another that is a version lower or if it has a different signing key. Make sure to use the latest APK/version.
No, you can install an eSIM from GrapheneOS, if you have one already then it will persist when you install GrapheneOS.
Considering switching to nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm from iOS.
Will I be able to load regular Google Play apps on the phone?
Thanks π #grapheneOS
Yes. If you mean Google Play apps as in the play store and services, they are handled by the Sandboxed Google Play compatibility layer and they can be installed optionally from the Apps app. The Google play apps run in an unprivileged state and so you can control permissions of those apps like location and network access.
You can also get your apps from the Play Store if you choose. It's your choice.
Only apps that won't work are apps blocked completely from running on anything but a Google certified OS but they are very few and far between.
GrapheneOS as a whole have reported several issues upstream to AOSP in the past, some appear on Android's Security Acknowledgements web page too but not always. Oldest is in 2015 but there is none credited to the GrapheneOS name rather the independent developers themselves. There are likely more to come since these recent upstream vulnerability reports.
This only counts unique discoveries, there have been times where the team discovers a vulnerability to find out it is a duplicate already being investigated internally. The major lock screen bypass vulnerability from 2022 was discovered by GrapheneOS independently that June when working on developing a duress PIN feature and had an initial patch developed for it by then. However when it was submitted to Google, it was a duplicate. It got fixed by the upstream in November.
Sometimes AOSP will add a security feature the OS had prior, when this happens we remove it from the features page off the site.
This only counts AOSP, there have been contributions to the Linux kernel, LLVM and others. It also isn't just security issues but it can also be general bugs. There is a wide range.
βοΈβοΈβοΈ
#GrapheneOS: Our users have found additional Android 14 QPR2 Bluetooth memory corruption bugs which so far appear to be specific to pairing recent Galaxy Watch devices with GrapheneOS. We're working on finding and fixing this as we did with the BLE audio bugs.
The Android 14 QPR2 Bluetooth LE audio bugs we found were fixed in the March 9th release of GrapheneOS: https://grapheneos.org/releases#2024030900.
We also reported it as an #Android vulnerability in the same day and it has been initially triaged by them as a High severity and High quality report.
Users on the stock OS are experiencing Bluetooth regressions with Android 14 QPR2 too. These latent and often exploitable bugs breaking functionality for certain users in certain situations often get turned into reliable crashes/breakage due to our memory corruption protections.
The downside is that more of our users get impacted by the issues and they tend to break a specific niche feature completely such as whatever is being used by the Galaxy Watch. On the stock OS, it breaks for some users and may break in a subtle way such as corrupting other data.
The upside is our users are protected against exploitation through these bugs and many others. Since the issues stop being subtle and turn into reliable breakage, it also forces us to look into what's wrong and we often figure out how to fix it completely as we did for BLE audio.
The end result is that GrapheneOS users end up with an OS that's not just more secure but has additional bug fixes since our exploit protections force us to fix these issues right after they're introduced instead of remaining dormant breaking things for some users for months.
#security #privacy
#GrapheneOS version 2024031100 released:
This fixes several small regressions causes by the transition over to Android 14 QPR2 while defaulting our new USB-C port control feature and additional integration of ARMv9 security features.
See the changes:
- toggle USB port after device unlock to automatically detect a device plugged in while it was in charging-only mode while locked, etc.
- Tensor Pixels: change default mode for our USB-C port control feature able to truly disable USB at a hardware level to "Charging-only when locked, except before first unlock" (doesn't apply to connections that were made before locking or first unlock) which can be changed by users in Settings > Security > USB-C port
- fix Wi-Fi auto-turn-off issues leading to it not triggering in certain cases caused by backwards incompatible changes in Android 14 QPR2
- Pixel 8, Pixel 8 Pro: fix enabling DisplayPort alternate mode support
- Pixel 8, Pixel 8 Pro: fully enable PAC and BTI for userspace too, especially since ShadowCallStack is not currently used in userspace and Clang type-based CFI is only used for a large subset of the important userspace code
- GmsCompatConfig: update to version 98
- improve internal infrastructure used by GrapheneOS features
https://grapheneos.org/releases#2024031100
#security #privacy
#GrapheneOS: We're continuing work on integrating ARMv9 security features. MTE is the highest impact and most interesting of these features, but there's less important work to do expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful.
Pixel 8 was the first device with a usable MTE implementation despite it launching as part of ARMv8.5. Android world stayed on ARMv8.2 until ARMv9 and Apple hasn't shipped MTE. Apple was a much earlier adopter of the much less useful PAC. From our perspective, PAC was a misstep.
PAC is a weak probabilistic mitigation requiring lots of case-by-case integration. MTE can provide many deterministic guarantees and does a much better job as a probabilistic mitigation by catching memory corruption rather than only protecting specific memory corruption targets.
PAC requires bits which would have been better served by 16-bit MTE support and using a 48-bit address space. Hardware shadow stack is a better backwards edge CFI approach. MTE could be used to mimic hardware shadow stack support via a reserved tag for ShadowCallStack.
We're currently the first platform using userspace heap MTE for hardening in production. We plan to do the same with userspace stack MTE along with doing both in the kernel. Turning ShadowCallStack in the kernel into a hardware protected shadow stack would also be nice to ship.
In the kernel, Pixel OS uses PAC for backwards edge CFI and Clang type-based CFI for forward-edge. We use ShadowCallStack + PAC together and enable BTI in addition to type-based CFI due to lots of functions being excluded from type-based CFI. We plan to do the same in userspace.