[object Object]

  • 2 Posts
  • 60 Comments
Joined 2 years ago
cake
Cake day: September 22nd, 2024

help-circle
  • Generally GrapheneOS is looking for sufficiently secure hardware it seems.

    Non-exhaustive list of requirements for future devices, which are standards met or exceeded by devices starting from Pixel 8 (shiba) through Pixel 10a (stallion):

    Support for using alternate operating systems including full hardware security functionality
    Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
    At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
    Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
    Linux 6.1, 6.6 or 6.12 Generic Kernel Image (GKI) support
    Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
    Hardware memory tagging (ARM MTE or equivalent)
    Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn't used or can't be deployed (BTI/PAC, CET IBT or equivalent)
    PXN, SMEP or equivalent
    PAN, SMAP or equivalent
    Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode and decode, image processor and other components
    Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
    Verified boot with rollback protection for firmware
    Verified boot with rollback protection for the OS (Android Verified Boot)
    Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
    StrongBox keystore provided by secure element
    Hardware key attestation support for the StrongBox keystore
    Attest key support for hardware key attestation to provide pinning support
    Weaver disk encryption key derivation throttling provided by secure element
    Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
    Inline disk encryption acceleration with wrapped key support
    64-bit-only device support code
    Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
    Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
    Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that's completed
    Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked
    

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





  • If by malware you do genuinely mean those that exploits vulnerabilities on your system to gain unauthrorised access (as opposed to apps that have heavy telemetry), I think apps from official sources are sufficient like Play Store or F-Droid. Malware will usually ask you excessive number of permissions. Deny them whenever possible. Installing them in second profile would make the damage contained.

    But since you said degoogling, I would go with F-Droid, or directly from GitHub, where most apps are open source. Obtainium is a great tool to manage those applications. Last but not least, denying network access can block some telemetry on apps that don’t require network to function.



  • I don’t quite see how AI assisted searching would be different in terms of privacy from normal search engine from the searcher’s perspective. Biggest issue with AI in the context of privacy is that it gets trained on a lot of personal data and can also be used to deanonymise when used against others. The only kind of information you would give away to the third party uniquely in AI search engine (I think) would be your speech pattern if you are having a conversation with it instead of simply typing in keywords. Duck.AI claims to ensure your data is not used to train the AI, but there’s no way to verify if the AI provider is holding up that promise. Still it’s a good choice since you don’t have to log in.

    Accuracy is not very relevant in privacy, so it would depend almost solely on what you choose as your provider.

    If I were to use one, I would choose whichever you can use without logging in, and gives reasonably accurate information.



  • Their website (https://coveryourtracks.eff.org/learn) do mention the concern you have; Blocking trackers means you are a user with a very specific privacy settings. I suppose it would be like going around with a full face mask; You are technically private, but you are uniquely identifiable unless someone else does that. I also get “Uniquely Identifiable” on my personalised browser, but nothing like it when I try it out on newly installed Mullvad browser with no changes.

    Not that I know much about how Tor traffic is identified, but Tor bridges seems like a potential solution? I would dig into that a bit more.