S
Sloff1155

  • 25 Mar
  • Joined 22 Mar
  • The Pixel 8 Pro now has Gemini AI as part of the stock OS. Will/does Graphene OS support the use of Gemini AI for features such as photo improvements, message suggestions and other future uses of Gemini AI? I'm guessing no for various software and privacy reasons, but thought I'd ask and confirm what the the Graphene OS devs think about Gemini AI.

    • We provide a bunch of features relevant to this:

      1) Our auto-reboot feature automatically getting data back at rest after locking, with the default of 18 hours after locking (you can make it as low as 10 minutes).
      2) Our recently added low-level USB-C port control on Tensor Pixels which even disables the data lines in hardware, with the default of disabling USB data in After First Unlock state when the device is locked (you can disable it in Before First Unlock state too along, set it as charging-only or even completely disable USB including charging while the OS is booted to even eliminate the charging protocol attack surface).
      3) Our recently added full compacting garbage collection in system_server/SystemUI on the device locks.
      4) Our large amount of generic exploit protection improvements including hardened_malloc, hardware memory tagging integrated into hardened_malloc and enabled by default, BTI/PAC and lots of other assorted kernel/userspace hardening along with a minor amount of additional firmware hardening through attack surface reduction. Attack surface reduction features such as Wi-Fi/Bluetooth auto-turn-off are also relevant.

      You can see that the first feature gets the data back at rest after a timer elapses after locking if there isn't a successful unlock first, and everything else combines to secure the device against attacks.

      Improvements to OS and firmware security are shipping in the stock OS for the April release based on our upstream vulnerability reports / suggestions to make things even better, including reset attack mitigation protection for the firmware fastboot mode by having it zero all memory before activating USB.

      • AspireMan Once it's shut down or rebooted to get data back at rest, the security of the data in profiles doesn't depend on OS security anymore but rather on the security of your lock method. There are hardware-based security features integrated into the key derivation process to make even a random 6 digit PIN highly secure. A sophisticated attacker able to exploit the secure element can bypass the time-based throttling for decryption attempts and break a random 6 digit PIN. A highly secure passphrase such as 8 random diceware words is secure against any attacker no matter their resources. There's scrypt-based key derivation at the start and then hardware-bound key derivation with a key unavailable to the OS or even firmware if properly implemented, which makes a weaker passphrase far stronger than it would be without it. It's up to you how to decide to secure your profiles. Each user has separate encryption keys so you could use a random 6 digit PIN for your main profile and 8 random diceware words for a secondary user. In the near future, we plan to add a feature providing the option to add an extra PIN to fingerprint unlock to enable people to use a strong passphrase combined with fingerprint+PIN secondary unlock rather than only a fingerprint by itself, to address the weaknesses of using a fingerprint alone.

      • Data is protected by encryption. Our auto-reboot feature automatically reboots the device to get it back at rest, by default 18 hours after the device is locked and hasn't been successfully unlocked. During that window of time, an attacker who was able to exploit the device could obtain the majority of data in the users that are still logged in since most data doesn't get back at rest from simply locking. Hardware memory tagging is a massive improvement to the defenses against exploitation, making it significantly harder to exploit the device in that window before it's back at rest. The main purpose of hardware memory tagging is defending a remote attacker being able to take over an app or the OS via the most common classes of vulnerabilities for the platform, but it also defends against the scenario of a physical attacker too.

        • Edited

        steelblue I feared there'd be more to it, aw man.

        Getting T-Mobile to unlock the bootloader is technically possible. They may or may not have a policy against it, but as ErnestThornhill wrote, even if it's policy-ok probably fewer than 1% of T-Mobile "techs" know how to do it. Here are a couple of suggestions for getting connected with the right kind of tech:

        1. Use the special keyword "Shiboleet" (just kidding),
        2. Be as polite as possible, and explain that you know you're asking for something very unusual,
        3. Ask if you can speak with somebody who trains the techs,
        4. Ask if there is a tech who runs a custom OS on a phone.

        Overall, getting the phone carrier-unlocked may be easy, but unfortunately getting it bootloader-unlocked might not be possible. Good luck!

      • arnydo

        Is it expected other apps won't work

        You may have to enable Android Auto developer options and then within it enable "Unknown Sources"