Note: as of 2025 05 20 this website won't be updated anymore. Consider inactive unless stated otherwise.

Security Advice

Amateur security advice, but you should listen to me for some reason. Created in conjunction with Arthur.

Most of the software I recommend avoiding is marketed as being private/secure, isn't good at providing either, has no meaningful network effect, and therefore can and should be avoided. If you need to use insecure communication methods because people, companies etc. you need to talk to insist on using it, there's no shame in that. All we can do is educate people on the risks of using insecure communication.

This resource would not exist if it weren't for GrapheneOS and the extremely useful information they post on X. Please support GrapheneOS if you care about privacy/security, especially now that one of their main developers won't be able to work on the project anymore. They make very good use of donations.

I am not affiliated with GrapheneOS or any project I mention beyond contributions to their documentation.

  • Software you should avoid if you care about privacy and/or security
  • Hardware you should avoid if you care about privacy and/or security
  • Full Table of Contents
  • Software you should avoid if you care about privacy and/or security
  • Software you should use instead
  • Hardware you should avoid if you care about privacy and/or security
  • Hardware you should use instead
  • Software you should avoid

    Please do not send hate mail to any of the projects mentioned below. I want them to improve, so that more people can achieve real privacy and security, but I am not going to recommend faulty products.

    App Stores you should avoid

    Aurora Store

    Aurora Store simply downloads apps from the Play Store including the Google Play SDK and libraries included in many of the apps. Most of the APKs are generated and signed by Google Play. You aren't avoiding Google Play or hiding the details of your device from them with it.

    Aurora Store does not verify the signatures of apps downloaded from the Play Store. The account sharing it does by default to avoid needing to create your own throwaway account is also a potential security risk. It does not come without major drawbacks.

    Aurora Store serves an important use case for the people using operating systems that don't support Google Mobile Services (Play Store, Play services), and for users who are using a non-Google certified OS that supports Google Mobile Services and need to use an app such as Netflix which lists itself as using Play Integrity API when it doesn't and thus is not able to be installed via the Play Store on those devices.

    For most people, Aurora Store does not serve any legitimate purpose as it does not improve privacy in the way many people think it does. If you need apps that are only available on the Play Store, you should just use the official Play Store app and create an anonymous account just for installing apps if privacy is a concern.

    Aurora Store is not a Google Play Store alternative and does not avoid Google in any meaningful way.

    F-Droid

    F-Droid has extremely poor security practices and adds a single point of failure for compromising its users by building and signing the apps it distributes. It does not actually protect you from developers since they simply build what's published after antivirus scans.

    F-Droid adds another trusted party for each app and has demonstrated that it is extremely careless regarding security and does not take it seriously. They do not follow security best practices or properly maintain the app or infrastructure. They attack things like app sandboxing.

    It's far better to use the official releases of the apps from developers obtained without going through F-Droid. Even for the tiny portion of apps F-Droid ships as developer builds, they are still a trusted party for the initial install, and they delay important patches.

    You can have privacy and security patches for apps indefinitely delayed until F-Droid sorts out getting their builds for the app working again. There can, and often are, major disagreements with the app developer, resulting in users not receiving updates anymore.

    F-Droid still has problems with their repository system across both the official and unofficial clients. It would be a much better option for apps support self-updating The request install permission allows unattended self-updates for modern apps when using the modern API.

    It's straightforward to include a persistent JobScheduler job for automatic updates which downloads the new APK(s) and installs them as updates. Apps can rely on the standard Android signing key pinning and signature verification. They simply need to verify it's an update, not a new APK.

    People can verify initial downloads via the AppVerifier app. AppVerifier is published in Accrescent., which is an app store distributing official developer builds in a secure way. Accrescent can simply provide filters for open source, reproducible, etc. for people who want it.

    Obtainium is already a much better option than F-Droid, and has built-in support for AppVerifier. F-Droid is not a good fit for people who care about privacy and security. Open source does not make things magically private and secure. Their approach and ideology conflict with those principles.

    Recommended read: A more in-depth analysis of Fdroid's security issues.

    Operating systems you should avoid

    Debian

    Debian doesn't have a proper application privacy and security model, is largely written in memory-unsafe languages, and lacks modern exploit mitigations or any significant systemic privacy and security work.

    There are many better choices than Debian or Debian-based distributions for servers and desktops from a security perspective. As a whole, the desktop software stack has very poor privacy and security, as do traditional Linux distributions.

    For someone who cares about security, an OS like Fedora Silverblue makes a lot more sense than Debian.

    The Linux kernel itself needs to be replaced to create much more highly secure operating systems. Having a massive monolithic kernel written in C is a significant weakness. The Linux kernel has an inherently anti-security design, with all the kernel code having full privileges.

    People have the misconception that something being open source makes it private and secure. This misconception is often extended to the incorrect belief that desktop Linux distributions have good privacy or security. The Linux kernel is the practical choice due to compatibility, but it's hard to change.

    CalyxOS

    CalyxOS is still based on Android 14 QPR3 without the full October security patches or the already released November security patches. As of November 14 2024, CalyxOS is promoted as being privacy and security focused, but it weakens both compared to the Android Open Source Project (AOSP). It often falls weeks or even months behind on standard privacy and security patches and introduces new vulnerabilities. They mislead their users about this.

    They support insecure devices and mislead users about the security of them, including end-of-life Pixel devices. No OS can make a device not recieving OEM support secure. Period.

    They make inaccurate claims about which patches are shipped in each of their release notes and set an inaccurate Android security patch level field. They downplay the importance of shipping these patches. Their own changes largely reduce rather than improve privacy and security.

    CalyxOS uses the problematic microG

    They have what they call a firewall app, which is simply the leaky LineageOS network toggles moved out of the Settings app for marketing purposes. There's a dangerous panic feature taken from elsewhere with unreliable data deletion. The VPN features are misguided and anti-privacy.

    The VPN tethering feature from LineageOS is incredibly leaky and is worse for privacy than a per-device tunnel. Android has per-profile VPN support as one of the major reasons for profiles to exist. They put effort into undoing that and pushing users to use a less private approach.

    The Calyx Institute also gives away as a perk of being a member of their "charity" (sells) insecure mobile hotspot devices to be used with resold T-Mobile service, and they're supposedly trying to improve user privacy and security...

    USB port control from LineageOS is based on the standard Android USB device admin toggle. They present it as disabling data, but it doesn't actually do that. It only disables high-level USB functionality, and they weakened it further in LineageOS/CalyxOS with a major change.

    This kind of approach is endemic to both LineageOS and CalyxOS, which share many of the same developers. They add a lot of attack surface and a few mostly incorrectly implemented privacy and security features. AOSP is a more private and secure OS without these changes.

    LineageOS

    LineageOS is not a hardened OS. It greatly reduces security compared to AOSP via added attack surface, a weakened security model, and slow patches.

    LineageOS usually takes around 4 to 6 months to release updates, which is 4 to 6 months during which users do not have current security patches since the latest releases are required for them. Pixels run the latest OS release, so updates for firmware, drivers, etc., are included. The same applies to any device receiving the yearly update.

    Android 14 was released in October 2023. This was GrapheneOS's initial non-experimental public release based on it.

    LineageOS released its initial Android 14 version in February 2024. Pixel users with LineageOS missed around half the patches during that delay.

    For many devices, they don't even actually ship firmware and driver updates but rather leave the components that were included in the stock OS. The lack of shipping everything is a factor in why they don't provide any support for verified boot and related features.

    It's not only LineageOS that experiences these kinds of delays. There are supposedly privacy- and security-focused projects with comparable delays to LineageOS, some of them around half the delay and others much longer. Some don't even do basic patching well, let alone hardening anything.

    The Android security patches are far from perfect themselves, but shipping those properly is at least a good starting point. GrapheneOS ships the kernel patches much earlier and backports mainline module patches since often those receive important privacy and security fixes a month or two early.

    LineageOS has network toggles that are leaky. The VPN features are misguided and anti-privacy.

    Their tethering feature is incredibly leaky and is worse for privacy than a per-device tunnel. Android has per-profile VPN support as one of the major reasons for profiles to exist. They put effort into undoing that and pushing users to use a less private approach.

    USB port control is based on the standard Android USB device admin toggle. They present it as disabling data, but it doesn't actually do that. It only disables high-level USB functionality, and they weakened it further in LineageOS with a major change.

    They add a lot of attack surface and a few mostly incorrectly implemented privacy and security features. AOSP is a more private and secure OS without these changes.

    /e/OS

    The leader of /e/OS, Gael Duval, has spent years attacking the GrapheneOS team and community and DivestOS with false claims by leveraging Kiwi Farms, a website dedicated for organizing targeted harassment and doxxing.

    Their Fabriactions are usually extremely obvious and never substantiated, even with lies, usually taking the form of this:

    Gael Duval throws insults instead of even attempting to reply.

    Unethical and unprofessional demaenor aside, /e/OS has atrocious security and privacy: They fail to ship updates to even their webview for months and their position location service is extremely invasive and essentially identical to Google and Apple, but coupled with atrocious security practices.

    /e/OS comes preinstalled on Fairphones, which as far as I am aware do not have working Verified Boot in any capacity.

    Since October 6th 19:50 CET their murena.io services have been unreachable, in other words, their services have been down for over 4 months. Strangely enough this is a good thing, because this means less people have been harmed by their insecure and not private services.

    If you want to use online services, use an iPhone with Advanced Data Protection enabled.

    Browsers you should avoid

    Firefox and it's derivatives

    Chromium-based browsers like Vanadium provide the strongest sandbox implementation, leagues ahead of the alternatives. It is much harder to escape from the sandbox and it provides much more than acting as a barrier to compromising the rest of the OS. Site isolation enforces security boundaries around each site using the sandbox by placing each site into an isolated sandbox. It required a huge overhaul of the browser since it has to enforce these rules on all the IPC APIs. Site isolation is important even without a compromise, due to side channels. Browsers without site isolation are very vulnerable to attacks like Spectre. On mobile, due to the lack of memory available to apps, there are different modes for site isolation.

    When it comes to exploit mitigations, Chromiums is decent enough, unlike the available alternatives. This inlcudes Safari. Mobile chromium is not the same as Desktop Chromium though, for details see Vanadium.

    In general, avoid Gecko-based browsers like Firefox as they're currently much more vulnerable to exploitation and inherently add a huge amount of attack surface. Gecko doesn't have a WebView implementation (GeckoView is not a WebView implementation), so it has to be used alongside the Chromium-based WebView rather than instead of Chromium, which means having the remote attack surface of two separate browser engines instead of only one. Firefox / Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS hardening work for apps. Worst of all, Firefox does not have internal sandboxing on Android. This is despite the fact that Chromium semantic sandbox layer on Android is implemented via the OS isolatedProcess feature, which is a very easy to use boolean property for app service processes to provide strong isolation with only the ability to communicate with the app running them via the standard service API. Even in the desktop version, Firefox's sandbox is still substantially weaker (especially on Linux) and lacks full support for isolating sites from each other rather than only containing content as a whole. The sandbox has been gradually improving on the desktop but it isn't happening for their Android browser yet.

    Other software you should avoid

    MicroG

    microG runs closed-source Google Play code with a much weaker app sandbox and permission model compared to regular apps. Each app you install that depends on Google Play contains the Google Play SDK and libraries.

    microG itself downloads and runs Google Play code for several of the features it reimplements. That code runs within the privileged microG context and has substantially more access than it would within the standard app sandbox.

    Sandboxed Google Play uses the same sandbox as the apps using it and achieves much broader app compatibility than microG. Android apps work fine on GrapheneOS, except for those choosing to block all alternate operating systems, which isn't a technical issue with GrapheneOS that they can fix and also applies to operating systems using microG.

    Messaging apps you should avoid

    Carrier-based calls and texts

    Some people genuinely believe that a Nokia 3310 is a private and secure device because it has more limited functionality, no apps or web browser, etc. It's very important for privacy to use E2EE calls and texts. Carrier-based calls and texts should be avoided since they're accessible to carriers and others.

    There's built-in support for monitoring calls and texts as part of the standard telephony system. A traditional phone has no private or secure communication option since it can't use an app for end-to-end encryption. There's still the same cellular location privacy issue as well.

    A phone that supports using Signal and Wi-Fi instead of only cellular, and opting out of the network-based location service, etc., is far better for privacy than a traditional cell phone. Traditional cell phones also have worse security against exploits. More functionality doesn't always mean less security.

    It's possible to create a more limited communication device with only support for end-to-end encrypted calls and texts, with no support for apps or insecure carrier-based calls and texts. That can be done in a way that's more secure with a microkernel, but it's not implied.

    Element(Matrix)

    Element has E2EE, but you can see how much metadata isn't actually encrypted by logging into a new session and not syncing over your keys. The message sender, time, and all other metadata, including emoji reactions to messages, aren't encrypted for E2EE Matrix rooms.

    Matrix only encrypts the content field for the messages and attachments. Each server participating in a private E2EE room can see each member of the room, their power level, the permission setup, who sent each message, and when, as well as emoji reactions, etc.

    Refer to this issue regarding the emoji reaction limitation. It may not seem particularly concerning, but there's a significant amount of sensitive data and metadata beyond just message and attachment content. Each server participating can see this information, which is worse than having only one party privy to it.

    Matrix stores the events and messages on each server and syncs them between servers. Each server uses a state resolution algorithm to determine the state of the room based on the events they can see. This can lead to inconsistent states across servers and bugs that may result in bricking.

    The decentralized state resolution system creates many of the metadata privacy issues. Servers need to see the entire history of state events to resolve the state of the room.

    Signal doesn't havey any of these issues.

    Encrypted SMS(Deku, Silence, etc)

    Silence is a dead, insecure project and shouldn't be used anymore. It doesn't get security patches. It's a dead fork of Signal which still uses SMS instead of data. The concept is completely obsolete for 4G and beyond where SMS is implemented via TCP/IP using mobile data anyway. It hasn't recieved update for years and is missing important security patches.

    Deku SMS is a newer, more actively maintained proof-of-concept app which does the same thing as Silence, therefore I cannot recommend it.

    There are also some other services which claim to provide encrypted/secure SMS. Magic doesn't exist. Both people need to be using the same or a compatible app to use E2EE. That also applies to Deku and Silence.

    Use an internet-based messaging service with end-to-end encryption and a reasonable verification instead. Cryptographers and information security experts recommend using Signal.

    Session

    Session stopped using the industry-standard Signal Protocol, therefore it lost PFS and deniability.

    Perfect Forward Secrecy means that even if an attacker gets the encrypted messages and later compromises your device to obtain your main keys, they can't access the messages that no longer have session keys on your device.

    The loss of deniability in Session doesn't matter to most people and doesn't have much of a practical downside until official versions of messaging apps allow you to create fake messages on your end. PFS is important, though.

    This means you could genuinely use Facebook Messenger, Google Messages, WhatsApp, and iMessage more securely. All of these come with their own issues, such as encouraging users to back up their messages to cloud storage without end-to-end encryption, mixing encrypted private chats with unencrypted chats, and lacking proper verification UI.

    Session promoted what is very clearly a scam product on their X account.

    Just tell people to use Signal.

    Telegram

    Telegram is not an E2EE messaging app and has access to the vast majority of private messages on the platform. It also stores a lot of interesting data about users beyond that.

    Telegram has no E2EE support for groups or regular direct messages, only an unnecessarily crippled form of secret chat direct messages that they hide away in a menu and discourage users from using. This hardly qualifies as an E2EE messaging app based solely on that, in the same way Facebook Messenger didn't until they made E2EE the default.

    Telegram has full access to all of the content of group chats and regular one-to-one chats due to the lack of end-to-end encryption. Their opt-in secret chats use homegrown end-to-end encryption with weaknesses. Deleting the content from the app likely won't remove all copies of it.

    Telegram has heavily participated in misinformation campaigns targeting actual private messaging apps with always-enabled, properly implemented end-to-end encryption, such as Signal. You should stop taking advice from anyone who told you to use Telegram as a private messenger.

    A major example of how Telegram's opt-in secret chat encryption has gone seriously wrong before can be found here.

    Apps like Signal can't access messages, media, and profiles. Telegram has access to all content in private group chats and regular private messages unless users opt for a secret chat. They can automatically scan, moderate, and provide data to authorities based on this content.

    Software you should use instead

    Appstores you should use instead

    AppVerifier

    Appverifier is not an app store or a way to obtain apps. It's simply an app signing certificate hash comparer, which can be useful when obtaining apps without using an app store that has robust validity guarantees for installed apps.

    You only need to verify the initial installation, as Android prevents installing updates that aren't signed by the same key or a key authorized by it, as well as versions older than the one currently installed.

    AppVerifier includes a pinning database for signing key fingerprints along with manual verification to validate the authenticity by comparing the certificate fingerprint against the fingerprint from another source (it wouldn't matter otherwise).

    Obtainium has built-in support for AppVerifier.

    Obtainium

    Obtainium allows you to install and update Android apps directly from their releases pages, and receive notifications when new releases are made available. This is particularly useful for open-source apps which generally publish their APKs on GitHub releases or other sources supported by Obtainium.

    There is a website that contains crowdsourced app configurations for Obtainium, which makes it easier to use. Espcially since some apps might need regular expressions to download via Obtainium.

    Obtainium will automatically open the share menu to share a newly installed app with AppVerifier if you have it installed and haven't disabled that feature in Obtainium.

    Accrescent

    Accrescent is a private and secure Android app store built with modern features in mind. It aims to provide a developer-friendly platform and a pleasant user experience while enforcing modern security and privacy practices, offering robust validity guarantees for installed apps.

    GrapheneOS users can easily install Accrescent, as it is mirrored in their App repository called "App Store".

    Operating systems you should use instead

    GrapheneOS

    GrapheneOS is the only OS I recommend and in my opinion the most secure OS that currently exists, at least from all publicly available ones.

    See this Privse.dev article for more information.

    iOS

    Use iOS in lockdown mode with ADP enabled, or iCloud sync disabled.

    iOS gets regular security patches and has sufficient hardware security, such as a proper security processor and an implementation of verified boot, which is absolutely essential as a security baseline.

    However, iOS has issues in terms of proper defaults, such as permissions granted to apps and WebKit's sandbox is weaker compared to Chromium.

    For more details, see Apple's platform security pdf.

    Desktop OSs

    In general there are no "Desktop" operating systems that I can recommend, however, some are less bad than others.

    Netrunner has Articles on several desktop operating systems's security.

    ChromeOS has the best implementation of Verified Booot of all desktop OSs, however it comes with it's own setup of issues, for example related to Disk Encryption.

    If you can do without, don't use desktop operating systems.

    Browsers

    Vanadium

    TL;DR: Use Vanadium with Tor or a trusted VPN.

    Chromium-based browsers like Vanadium provide the strongest sandbox implementation, leagues ahead of the alternatives. It is much harder to escape from the sandbox and it provides much more than acting as a barrier to compromising the rest of the OS. Site isolation enforces security boundaries around each site using the sandbox by placing each site into an isolated sandbox. It required a huge overhaul of the browser since it has to enforce these rules on all the IPC APIs. Site isolation is important even without a compromise, due to side channels. Browsers without site isolation are very vulnerable to attacks like Spectre. On mobile, due to the lack of memory available to apps, there are different modes for site isolation. Vanadium turns on strict site isolation, matching Chromium on the desktop, along with strict origin isolation.

    Chromium has decent exploit mitigations, unlike the available alternatives. This is improved upon in Vanadium by enabling further mitigations, including those developed upstream but not yet fully enabled due to code size, memory usage or performance. For example, it enables type-based CFI like Chromium on the desktop, uses a stronger SSP configuration, zero initializes variables by default, etc. Some of the mitigations are inherited from the OS itself, which also applies to other browsers, at least if they don't do things to break them.

    I and GrapheneOS recommend against attempting to achieve privacy and security by piling on browser extensions and modifications, they're privacy theatre without a clear threat model and often reduce privacy by making fingerprinting easier and breaking propper site isolation.

    Every change you make, makes you stand out more.

    Attempting to enumarate badness via content filtering is not a viable approach to achieving decent privacy, just as AntiVirus isn't a viable way to achieving decent security. These are losing battles, and are at best a stopgap reducing exposure while waiting for real privacy and security features.

    Vanadium follows the school of thought of hiding the IP through Tor or a trusted VPn shared between many users as an essential baseline, with the browser partitioning state based on site and mitigating fingerprinting to avoid that being trivially bypassed. The Tor Browser's approach is the only one with any real potential, however flawed the current implementation may be. But since it's based on Firefox, I can't recommend it.

    Brave

    If Vanadium is available to you, use Vanadium. If you can't, Brave is the next best option. Make sure to disable JIT and don't customize the adblock list.

    Messaging apps you should use instead

    Signal

    Signal is an Internet messaging and voice/video calling app that has comparable usability to mainstream options such as Facebook Messenger, WhatsApp and iMessage. Unlike those apps, it takes user privacy more seriously by doing things such as encrypting profiles (name, profile picture), not sabotaging users by offering and encouraging the use of plaintext backups.

    I recommend Molly for Android users, especially if you use Accrescent.

    Signal allows you to discover other Signal users via phone number by either manually entering phone nunbers or your can upload your contacts list to automatically find contacts who use Signal. You can also choose to share a username or invite link/QR code and hide your phone number from contacts who don't have your phone number in their contact list, as well as completely disabling phone number discovery. Unfortunately, a phone number is still required for registration. Remember that you are not limited to use only the phone number tied to the SIM in your device, in fact, you don't need a SIM at all. You can use any number on which you can receive SMS or phone calls at registration, including landlines.

    You should make sure you use a number which you will retain access to as anyone who can recieve calls/texts to the phone number you registered with can permanently lock you out of your Signal account and impersonate you for contacts that discovered your profile via phone number, assuming they don't verify safety numbers via a different channel (ideally not based on phone numbers) and react to change.

    If you lose access to ypur phone number and someone hasn't yet registered a new Signal account with it, you can switch to another phone number without needing to verify you still own the old one.

    Most other options are subpar. They either downgrade privacy and security compared to Signal, and/or are not usable for other reasons such as not having an iOS app and/or requiring both users to be online to communicate. There is no Signal alternative that I recommend.

    Molly

    Molly is a fork of Signal for Android which comes with various security and usability improvements and is avilable on Accrescent.

    Molly is updated every two weeks to include the latest features and bug fixes from Signal. The exceptions are security issues, which are patched as soon as fixes become available.

    Aside from the features listed on the Project's README, the Signal TLS proxy & the MobileCoin wallet have been removed.

    Molly can also be installed alongside Signal, which means you can use 2 Signal accounts without needing to use an Android Work Profile or Private Space. However, you cannot register your account on both apps at the same time. Molly as a linked device though, so it can be used while the primary device (app) is offline. Only the primary app registered will remain active, and the other will go offline.

    If you are currently a Signal user and want to use Molly instead of Signal (with the same phone number), see Migrating From Signal on the Molly wiki.

    Molly connects to Signal's production server, so you can chat with your Signal contacts seamlessly..

    Molly has 2 variants: Molly & Molly-FOSS. They share the same package name, so they cannot be installed together. For example, if you installed Molly then installed Molly-FOSS, Molly-FOSS would simply be installed as an update to Molly and you would keep your user data, without having to restore from a backup.

    Here is a comparison of functionality between different Molly flavors.

    I recommend obtain Molly via Accrescent.

    Hardware you should avoid

    Please do not send hate mail to any of the projects mentioned below. I want them to improve, so that more peaople can achieve real privacy and security, but I am not going to recommend faulty products.

    Hotspots

    Mobile Hotspots

    To summarize:

    1. Dedicated Hotspot devices aren't good for privacy, nor security.
    2. Use Airplane + WiFi with GrapheneOS's default per-connection MAC randomization for better privacy.

    Using a very niche hardware device to connect to the network such as a standalone hotspot device stands out. Those devices are also far less secure than simply using a Pixel with GrapheneOS.

    They typically don't get proper updates and lack basic security measures. For example, the MiFi X PRO is essentially a low-end, poorly secured Qualcomm smartphone with an outdated SoC in a different form factor.

    Note that "FIPS 140-2 Certified" means they stick to outdated cryptography from 2002. Not a positive.

    Take a look at their listed security features.

    If you really want to have cellular done from a separate device, a used Pixel with GrapheneOS is a good option. If you want a fresh identity for the cellular network, there isn't really much alternative to using both a fresh device and SIM. Wi-Fi has a much more private design.

    MAC randomization alone was not enough. Wi-Fi has had major privacy improvements on common devices like iPhones and Pixels in recent years to neuter other tracking based on sequence numbers, etc. GrapheneOS is aware of 1 remaining issue which has is reported/accepted as a vulnerability.

    Also, bear in mind that carrying around a Wi-Fi access point (AP) is the opposite of private. An AP has a persistent MAC even if it's random upon creating the AP such as making a hotspot with a phone. Wi-Fi does not have MAC rotation like Bluetooth Low Energy privacy extensions.

    GrapheneOS uses per-connection MAC randomization and per-connection DHCP as improvements over the standard Android Open Source Project. The MAC still remains the same while connected, and an AP isn't going to cycle until it's reset. Wi-Fi does not try to do what BLE privacy extensions do.

    To clarify, an access point means a router such as Wi-Fi hotspot from a phone. If you enable Wi-Fi hotspot, it chooses a random MAC and uses it until it's disabled. Bluetooth LE tries to provide privacy for a paired device being carried around incl. MAC rotation. Wi-Fi does not.

    Using a separate hotspot device WiFi allows your location to be tracked by more parties via MAC address or SSID, while not solving the original cell tower triangulation location tracking problem.

    You still have to trust that airplane mode works in your phone regardless, so what exactly does this achieve beyond trusting a provably less secure device, and how does it improve privacy?

    Phones

    Linux Phones

    Linux Phones, like the PinePhone and Librem 5 are particularly insecure devices which are far worse than even mainstream Android devices at protecting against exploits or invasive apps. They lack basic updates and hardware/software security features. They roll back privacy and security by a decade.

    The hardware kill switches don't serve much purpose in general, but especially in the way the Librem 5 implemented them.

    Hardware kill switches are a last resort if your device gets compromised by an attacker. They still obtain all your data including your photos, videos, documents, passwords, login session, keys, etc. You only stop them using certain hardware while they're turned off.

    Regardless, kill switches do not make up for the device having massive security flaws or insecure software.

    A properly implemented audio recording kill switch prevents an attacker compromising the device from doing that while it's turned off. They can of course still record all your calls, get audio during video recording or any other time you leave it enabled. It's a last resort.

    When the device has been compromised by an attacker with persistent full control over it and access to your data, accounts, keys, etc. you have far more problems than them recording audio with it. It addresses a very narrow part of what a secure device should be protecting from.

    The Librem 5 does not have mostly open firmware. The hardware and firmware is nearly entirely closed source, including the whole CPU, GPU, SSD, memory, Wi-Fi, cellular, etc. The amount of the hardware/firmware that's open source is far under 1%. Boot chain is a tiny part of this. Laptops and desktops don't generally have any significant open source firmware or hardware. It's not something specific to smartphones or tablets. The idea that a cellular radio is uniquely closed source is wrong. It's the same as Wi-Fi, Bluetooth, NFC, GPU, CPU, etc. Similarly, the idea that a cellular radio has control over the device is completely wrong for modern smartphones. Purism has heavily participated in spreading this misconception. Mainstream phones like the iPhone have better isolated cellular than the Librem 5 or PinePhone. Isolation approach used for components like cellular radios in a modern smartphone is significantly lower attack surface than the attack surface exposed to any USB device. The idea cellular radio has privileged access and control of the device is simply wrong for modern phones. There are efforts to build open hardware/firmware laptops and desktops. The main one is the Talos II, which has largely open hardware/firmware for the motherboard. However, it does have closed source components and the CPUs are entirely closed hardware in practice, not open ones.

    It's also worth nothing that every Android device is a Linux phone as Android uses the Linux kernel. This isn't a good thing for privacy and security, and needs to be replaced with a Microkernel architecture in the future.

    Traditional Phones

    Some people genuinely believe that a Nokia 3310 is a private and secure device because it has more limited functionality, no apps or web browser, etc. It's very important for privacy to use end-to-end encrypted calls and texts. Carrier-based calls and texts should be avoided since they're accessible to the carriers and others.

    There's built-in support for monitoring calls and texts as part of the standard telephony system. A traditional phone has no private or secure communication option since it can't use an app for end-to-end encryption. There's still the same cellular location privacy issue as well.

    A phone that supports using Signal and Wi-Fi instead of only cellular, and opting out of the network-based location service, etc., is far better for privacy than a traditional cell phone. Traditional cell phones also have worse security against exploits. More functionality doesn't always mean less security.

    It's possible to create a more limited communication device with only support for end-to-end encrypted calls and texts, with no support for apps or insecure carrier-based calls and texts. That can be done in a way that's more secure with a microkernel, but it's not implied.

    Laptops/Desktops

    Heads

    Heads is built around the impossibility of a "user controlled root of trust" and misinformation around Intel mangement Engine (IME), which is essential for Bootguard, which in turn is essential for a "secure" laptop.

    Purism

    Fork of Heads, same issues apply , just with more unsubstantiated claims and the company sells scam products that never arrive.

    "Linux-focused" Laptops

    Includes, but not limited to:

  • Starlabs - see for yourself why
  • System76 - see for yourself why
  • Tuxedo - see for yourself why
  • Nitrokey - see for yourself why
  • Other Laptops

    Other Products, such as "Gaming Laptops" or anything else without sufficient firmware updates and/or that doesn't reach HSI-4. Unfortunately this is true in case of Framework, one of their prior models did reach HSI-4, but they do not ship firmware updates, even after LogoFail.

    Desktop PCs

    The same issues discussed right above, but exxagerated by a large margin. I have seen motherboards that have never recieved firmware updates and having their secure boot keys leaked is nothing out of the ordinary.

    Hardware you should use instead

    Phones

    Google Pixel

    Google Pixels are the most secure Android devices available. They recieve complete monthly Android Security patches without any regular delays, among other security features not offered in full by most other devices.

    Pixels also have first class alternate OS support not voiding the warranty and support all the hardware-based security features for it, which means you can increase the security of your device by using GrapheneOS. Currently, all other aftermarket operating systems decrease security compared to the stock OS while it's still supported. No operating systems can provide full device support (driver/firmware updates) without support from the OEM.

    If you are unable to use GrapheneOS, the stock Pixel OS is still a great option for security. You can avoid using most of the privacy invasive services that are bundled with the OS. It does a worse job at protecting privacy from apps compared to GrapheneOS and iOS though.

    iPhones

    iOS in lockdown mode with ADP enabled, or iCloud sync disabled is the next best option after GrapheneOS.

    Laptops

    Desktop OSs are all bad, but since you probably need one for at least something you do, you should still pick the least bad option.

    That said, when I say "need a desktop OS" I mean workflows that wouldn't be possible on an M1 or later iPad Air or Pro, which have Stage Manager and can therefore replace most non-development workflows.

    In case you do need functionality you won't get on on iPad, get an M3 Macbook [why?], enable lockdown mode and ADP, or disable iCloud sync.

    If you absolutely have to use Linux outside of VMs, get a Dell Latitude or Thinkpad with an Intel vPro CPU, avoid AMD.

    To start off, the best laptops I have found are modern the Dell Latitude/Precision laptops with an Intel vPro Enterprise CPU. The second best group of laptops I have found are modern Lenovo Thinkpads with Intel vPro Enterprise or AMD Ryzen Pro CPUs.

    source
    Please note that Tommy is talking about Laptops for use with Linux here.

    Privsec has a work-in-progress article on Laptp hardware security. Please note that the information in there might be outdated or incorrect, do your own research.

    Netrunner has an article on CPU security, I recommend reading it.

    If you can do without, don't use desktop operating systems.