Good Non-Default Settings
Below I've listed some of my personal settings I'd recommend choosing and my rationale behind them and why you may consider following suit.
Connection Settings
Since GrapheneOS is Free and Open Source Software (FOSS) that is publically audited to ensure privacy and security, and it's cryptographic signature is verified during each boot to ensure it is untampered, we assume that all software on-device is safe to use. This breaks down as soon as we introduce external data, either from USB connections or through radio connections like Cellular Data, WiFi, or Bluetooth. Since these are the most significant attack vectors in breaking the safety and trust we have just after our first boot, we must be careful when using such connections.
Network & Internet
Navigate to "Network & Internet" in the Settings app. Below are my recommended settings and why:
- eSIM support
- Switched on. eSIM data plans can be purchased non-KYC (Know Your Customer), paid with Monero at sites like silent.link. They are also not susceptible to physical SIM swapping attacks which can easily defeat SMS 2FA that many banking sites use.
- Airplane mode
- Switched on whenever WiFi is used. Bluetooth and Cellular Data signals are used as extremely effective location tracking tools. The iPhone network and others use Bluetooth Low Energy signals combined with GPS and Data to track all Bluetooth devices in range. If you're around people chances are you're being tracked if you have bluetooth on.
- VPN
- Unless there's a specific reason not to (i.e. logging into banking sites that block VPNs) one should always have a trusted VPN on at all times. A VPN tunnels all internet traffic, encrypted, to another server; basically replacing your Internet Service Provider. My recommendation is Mullvad VPN purchased with Monero. Make sure "Always-on VPN" and "Block connections without VPN" are checked to ensure no leaks. At least in the U.S., post-PATRIOT Act all ISPs and Cellular Providers monitor and analyze traffic and share this data with three letter agencies. Mullvad at least *CLAIMS* not to and that they run all their servers on RAM only. At the very least you're paying with Monero which isn't linked to you compared to paying with your credit card or bank account like for an ISP or Cell Service.
Exploit protection
Navigate to "Security & privacy" and then "Exploit protection"
- Turn off Wifi automatically
- Anything less than 5 minutes. This setting turns off WiFi after disconnection for a set time. Depending on how close you live to other internet access points you may want to shorten this time period. In short, every time you see a potential WiFi connection in settings, this means the phone has shared its MAC address (unique device identifier, although randomized with Graphene) to the network to learn about the nearby networks name (SSID). This is a tracking mechanism as almost all access points you encounter will be proprietary spyware. If you're out an about, there's no need for this attack vector to be open.
- Turn off Bluetooth automatically
- Same vein here though I'd recommend anything less than 5 minutes. Bluetooth works very similarly except that Bluetooth tracking is the primary mechanism that Apple's ubiquitous Find My network functions, and many others. Ideally you're not using any Bluetooth devices as they have a large attack surface, but if you insist, Bluetooth must only be turned on when needed and off when not.
Security Settings
Exploit protection
Navigate to "Security & privacy" and then "Exploit protection"
- Auto reboot
- Anything less than 12 hours. When the device is rebooted, the decryption keys are purged from memory which limits the only attack surface to the Titan chip in the hardware security part of the Google Pixel phone, which is strongly trusted by the GrapheneOS team. Similarly, hitting "lockdown" after holding down the power button will put the phone in a similar state.
- USB-C port
- Either Charging-only or Charging-only when locked. Unless you use devices like USB-C headphone adapters, keep this to charging-only. Transferring data is safer through protocols like Tor or LAN connections, both of which can be done easily through FOSS apps like LocalSend or OnionShare.
Device unlock
Navigate to "Security & privacy" and then "Device unlock"
- Screen lock
- Tap on "Screen lock" (not the cog icon to the right). I would only recommend a PIN of at least 6 characters, or a alphanumeric password that is unique the the device. Due to the Titan security chip of the Pixel you should not worry about making a super complex password, the real advantage of the password over PIN would be from hackers performing a shoulder surfing attack (literally watching you type in your PIN then unlocking your phone after).
- Screen lock settings
- Tap on the cog icon to the right of "Screen lock". Uncheck Auto-confirm unlock, it takes marginally more time to hit enter for a small security boost. I would highly recommend Scramble PIN input layout, this is a major hinderance to shoulder surfing attacks or cameras recording your passcode. Enhanced PIN privacy: Checked. Lock after screen timeout: 5 seconds or off. Power button instantly locks: On, why one would want this off is beyond me. Allow camera access when locked: Off, also a no brainer to me.
- Fingerprint Unlock
- This depends on your threat model whether or not to enable this at all. Fingerprints are stored in the secure hardware chip of the Pixel and only hashed data is given to GrapheneOS. That being said, if there's a secret backdoor that the government has with Google's hardware, they could potentially get this raw data. If you choose to enable Fingerprint Unlock, I would HIGHLY ADVISE not to enable "Use for screen unlocking". Fingerprint unlocks are not protected by the Constitution according to the courts (yeah that's where we're at with the "justice" system). Police officers can and will force you to unlock your phone. When fingerprint unlock is on, but not for lock screen, many apps still let you lock them with your fingerprint, increasing your security in the case of a compromised PIN, but with minimal inconvenience due to the speed of the Fingerprint Unlock.
- Duress password
- The duress password is a false password that wipes your user data upon entry. For most threat models this has little utility, and may even hurt you as such measures can easily be considered obstruction of justice if one were to be convicted of a crime. If targeted law enforcement attack is a part of your threat model, having anything illegal on your phone would be a very poor choice due to the reliance on the proprietary Google Titan chip, which is proprietary and thus capable of and likely to have secret backdoors.
General Phone Settings
These settings aren't related to privacy or security directly, please see if each fits in with your personal use case.
Battery
- Charging optimization
- Not a security feature but I'd recommend turning "Limit to 80%" to on to extend battery life. Unless you change batteries yourself, you would have to trust that a third party repair store isn't tampering with your phone.
How-To Install Apps
Below I will delve into the basics of Android app installation, and how to maintain different trusted models to minimize security risk.
Linking the Chain of Trust
Apps on Android are installed from compiled .apk files. These are binaries compiled from source code written for android. APK files can be malicious (malware) so it is important to ensure that they are from trusted sources. By default, GrapheneOS comes with only a handful of basic pre-installed apps, including the "App Store" app. Any app installed from the "App Store" app comes from a source that the GrapheneOS team has verified the integrity of, and all installs are verified after download to protect against an attacker hijacking your download connection (MITM Attack)
Upon opening the App Store, you'll find that there are only a handful of apps available. The most notable here is the Accrescent app which is a third party app store that the GrapheneOS team has verified the integrity of the binary available to download on the App Store. You also will note that there are a few Google apps available. At the time of writing these are: Android Auto, Google Play Store, Google Play Services, and Markup. I'd advise thinking carefully before installing these. Please read the rest of this section and do your own research on the potential dangers of proprietary (closed source) software, in particular, Google's software.
First download the Accrescent app from the App Store. Since we are trusting the bootloader verification and initial install of GrapheneOS, we are trusting that any app in the App Store is verified by the Graphene Team and thus the Accrescent download from the App Store is the real Accrescent App. To eliminate this trust, you can use the Auditor app (pre-installed or can be installed from the App Store) to make verify that your install is signed by Graphene. To eliminate the trust that GrapheneOS itself, signed by the Graphene Team, is not spyware/malware and that apps downloaded from the App Store are verified, a full code audit must be completed. This is out of the scope of this tutorial and thus the beginning of our trusted model that we're building from.
Accrescent will now appear in our installed app list which can be found by swiping up on the home screen. Accrescent is an app store that distributes apps that are signed by the developers of each app. Accrescent reduces risk of MITM attack by TLS pinning and other measures. For the scope of this tutorial we are trusting that apps installed from Accrescent are the apps that the developers themselves signed and compiled. (Please note that this is not to say that each app is trustworthy inherently, just that that trust is strictly limited to the app developer). To recap: we're assuming for the scope of this tutorial that our install is untampered with and signed by the Graphene team. This allows us to trust that the Accrescent install from the App Store is the true Accrescent app signed by the Accrescent team, and that any app installed from Accrescent is signed by that app's dev team. This chain of trust is vital to the security model of software distribution. The advantage of Free and Open Source Software is that this trust can become trustless when we personally verify each line of code. If we don't verify them personally, the trust is still broadened to not only trusting the developer, but also trusting anybody else claiming to have audited the code. This trust minimized model is directly opposed to the trust maximized model of the default Google Pixel OS, which is proprietary Google code on top of the Android Open Source Project. Or worse yet, the completely proprietary Apple iOS, in which both operating systems leave no room for auditability to create a trustless chain of software.
The Choice Between Security Models: FOSS Exclusive or Proprietary Accepting
At this point we have the choice between two security models for installing software: the FOSS only model, or accepting proprietary software and keeping to the chain of trust we've been linking along currently. I will try to explain the pros and cons and limitations of both here in an unbiased manner, then give my personal opinion after.
The Proprietary Accepting Model
The Proprietary Accepting Model is the default for GrapheneOS. In this model we're accepting the running of proprietary software when we wish to install software not found on Accrescent. In this model, Google Play Store is installed from the App Store, and an application is installed from the Google Play Store. The main advantage of this model is that the unbroken chain of trust we've been building on previously is maintained throughout (GrapheneOS verified boot -> Pre-installed App Store -> Google Play Store -> Desired App). The corollary advantage is the convenience and safety (if you accept proprietary software as outside of threat model) of this model. You simply can't make an error risking installing apps you don't intend to this way insofar as you trust the Google Play Store (a difficult proposition if you're more partial to the trust minimized model I've described above). On paper, if Google's claims of how they secure the Play Store are believed (they can't be verified due to the nature of proprietary software), this is the highest standard of security. If you're willing to trust Google, and are okay with nobody being able to publically verify their claims, then this is the superior security model.
If accepting the risks of proprietary software then the tutorial can essentially end here. Many apps downloaded from the Play Store will require Google Play Services to also be installed from the App Store to function. Take note to be careful about what permissions are granted to the sandboxed Google Play Services, they are not granted as many permissions as on default Pixel OS, but can still be very damaging to privacy if you grant too many permissions. Many apps from the Play Store may also not work with GrapheneOS specific settings like Hardened Memory Allocator. Be sure to tinker with such settings on apps that give trouble. Many users report certain banking apps refusing to launch due to missing device identifiers, so this is important to note as well. Other than these limitations, with Play Services and the Play Store you essentially have a hardened, more private Google Pixel, a great improvement over the default.
The FOSS Only Model
The FOSS Only Model is the default for other Android Open Source Project forks like CalyxOS. In this model, the user considers all proprietary software as being inherently untrustworthy and potential malware due to the unauditability of these source code. This model is the basis of the philosophy behind Linux distributions such as Debian and has its roots in the GNU project and Free Software Foundation. In this model, the responsibility of validating software relies on the user. This model involves installing applications through FOSS only repositories such as F-Droid or installing FOSS only .apk files directly from the developer, signed from the developer (or best yet, only .apk files compilied by the user from a verified source code, but that is much out of the scope of this tutorial).
In the situation where you've gone through the Accrescent app library and installed any apps that you find useful there, but have others in mind that can't be found I'd advise starting with F-Droid. To install F-Droid we'll first need to install the AppVerifier from the Accrescent store. Once that's been complete go to the Official F-Droid Site and download the APK. Now, before doing anything with the F-Droid.apk file, open AppVerifier and tap "Verify APK File". The Internal Database Status at the top should read "SUCCESS". Clicking on the i next to this should reveal that the app was validated against the F-Droid database. If it says "FAILURE" then try to redownload the APK, perhaps from the F-Droid github page. Once F-Droid is validated, you can open it with the file manager to install.
In the F-Droid app store you can find a multitude of apps that have had the source code reviewed by the F-Droid team and compiled and signed by F-Droid. This is a major departure from the developer signed model of the previous security model. F-Droid has had a good track record of enforcing removal of proprietary code from apps but is not without its fair share of criticism. The major criticism of F-Droid has to do with this shift of trust, you're ultimately placing the trust in F-Droid not to place malicious code before compilation. I'm of the opinion that this is a stronger trust tradeoff than trusting the developer directly primarily due to the incentive model. F-Droid has the incentive to ensure apps are 100% FOSS as this is how they've 'sold' their app repository and thus why people donate and support the project. The developer has incentive to ensure their apps are profitable to them, ideally through providing value thus providing a profit of virtue knowing they've done good for others, and hopefully recieving support through donations, but also are incentivised to introduce malicious code to ensure their apps are profitable. I'd say a vast majority would never entertain this temptation, but I believe it's stronger for the developer than F-Droid. This is also the philosophy behind Debian, Fedora, and Arch linux. Software packages are all reviewed and signed by the respective distributions and distributed to the user. The tradeoff here is clear and up to personal judgement, trust the developers collectively, or trust the F-Droid team.
For installing apps from F-Droid I recommend the following. First I'd advise installing F-Droid Basic from the F-Droid store if you don't need the extra features like local file sharing. This reduces the attack surface by shortening the code base of what is one of your most sensitive apps.
I'd also advise on installing Orbot before anything else. To do so add the Guardian Project F-Droid Repo to F-Droid by copying and pasting the desired repo link into the repository section in the F-Droid settings menu. Be sure to ensure that the Signing Key Fingerprint matches up with different sources on the internet in case that your specific connection to the website wasn't compromised. Once that repo is installed, install and launch Orbot. Orbot is a Tor network VPN and proxy. It allows you to either route all phone traffic through the Tor network, or allow apps like F-Droid to proxy traffic through the Tor network in the background. Routing all traffic through Tor will cause many apps to run slower or not at all as the Tor network may be blocked. For the purpose of this tutorial I advise opening Orbot and checking "Power User Mode" in the Orbot Settings. This allows it to run in the background without VPN model. Also be sure to hold down on the Orbot app icon in the app library and select "i app info". From here change "App battery usage" to "Unrestricted" or else it won't run consistently as a background proxy. Now enable "Use Tor" in the F-Droid settings and all F-Droid downloads should be routed through Tor. This makes Man In The Middle attacks much more difficult and makes it nearly impossible for your Internet Service Provider to know that you're even downloading apps from F-Droid in the first place and helps hide your identity from F-Droid.
Other apps like SimpleX can use the Orbot proxy. These apps don't have a simple checkmark to enable Tor routing. You'll have to tell it where the Orbot proxy is running. By default it's running on IP address 127.0.0.1 (aka localhost) on port 9050. Depending on the app you may need to type in 127.0.0.1:9050, 127.0.0.1 and 9050 separately, or maybe localhost and 9050.
For any apps not found in the default F-Droid repository (or the Guardian Project repository if you just installed Orbot) there might by an accompanying F-Droid repo similar to Orbot. Search terms like "'app name' fdroid" and instructions to install will likely be on the app's official site or Github repo. Be sure to always double check signing keys as even the correct domain can be intercepted and website contents changed on a per connection basis. Doing such research behind a trusted VPN (Mullvad, iVPN, etc.) paid with Monero or behind the Tor Browser offer greater resistance to this attack than if you were connecting just behind your ISP's IP address.
For apps that are neither found on Accrescent nor F-Droid, and also don't have an F-Droid repository there are still ways to maintain install integrity. Zapstore is an alternative to Accrescent or F-Droid that provides both Zapstore signed APKs and developer signed APKs. I personally only use them for their developer signed APKs as, from what I can tell, they don't review code as thoroughly as F-Droid, nor do they have a strict rule against proprietary code.
Another final option is to use Obtainium. To use Obtanium, first download it from F-Droid. Then, you must paste the github or other git repo site's project link into the app from whatever app you want to download. Search up "'app name' github". Obtanium will scan for downloadable APKs then prompt you to download and install them. If you've AppVerifier installed it will also prompt you to share the APK download with AppVerifier. ALWAYS DO THIS on first install. Ensure either successful verification with the AppVerifier Internal Database or copy the SHA256 Certificate from the Github or project website and tap "Verify from clipboard". Once verified proceed with the install. Subsequent updates from obtanium will ensure signature match with the initial install so it is crucial that apps are verified before install.
Finally if an APK is not found on any github pages and can't be installed via Obtanium then it is very likely that the app you're facing is not truly FOSS, or is still open source but the developers don't compile an official APK for whatever reason. This seriously should make you question the APKs you do recieve from the Play Store for the app vs what is found in the source code. Why not provide an APK at least on the git website if the APK on the Play Store is ostensibly compiled from the source code? In this case, your only means of secure install are either the Google Play Store or Aurora Store. The Aurora Store can be downloaded from F-Droid and is a FOSS frontend for the Google Play store. What you gain in privacy with the Aurora Store you lose by adding multiple trusted parties between you and the app you wish to download (F-Droid + Aurora Store + Google, instead of just Google with the Play Store). For this reason I'd advise thinking carefully about installing apps this way, I've only found a handful like this (Proton Calendar and Proton Drive to name two).
The Hybrid Model
If you consider yourself in the FOSS camp but have some services (banks are a primary example) in your life that require installation of a proprietary app, there is a solution built into GrapheneOS. I'd say first and foremost, however, if there is an option to use the website over installing a proprietary app, this is ALWAYS superior for privacy due to the almost unlimited means of tracking an app has access to compared to the limited sandbox of the browser. If you've determined that you need to access a specific feature only found on a proprietary app, please continue reading.
Even with sandboxed Google Play Services, if you have a mixture of FOSS and proprietary software installed on the same profile, many FOSS apps (Signal for instance) will use the Play Services push notification server for notifications instead of via a background service. When notificattions are sent via Google's push notifications server, a lot of metadata and data related to that notification is stored and linked to your identity. To resolve this, you can create a separate user profile just for proprietary software. This creates a strict divide between the two worlds such that your privacy cannot be jeapordized by the presense of proprietary software.
First open the Settings app and navigate to System and then Users. Tap the checkmark for "Allow user switch", this enables the multiple user profile system in GrapheneOS. Tap "Add user" and give it a name like "Untrusted Software", or even no name at all. From here, uncheck "Allow running in background" unless you have a good reason to keep this on, and ensure "Turn on phone calls & SMS" is turned off as well, once again unless you have a good reason to turn this on. Since we'll be installing apps from the Google Play Store in this profile keep "App installs and updates" set to "Enabled". Now you can switch to this user in the settings app, or from the control panel menu that's accessed by swiping down from the top of the screen.
Once you've switched to the profile, set up the device as you did the first time, and then follow my "Proprietary Accepting Model" section for best practices in installing proprietary software from the Google Play Store.
My Take On The Matter
I believe that the FOSS only model provides a much greater level of security and, particularly, privacy than accepting the proprietary Google Play Store. This is primarily because my threat model places Big Tech corporations and three letter agencies (you can come up with many off the dome I'm sure) at the top. There are means of minimizing risk to attacks that, while requiring more research and responsibility on the user side, can be achieved without increasing the risk of attacks from Google or any nation state as you do with the Play Store.
I also believe that permanently proprietary software is inherently immoral. Never before has any human creation had the means of it's function be impossible to inspect, learn from, or repair. In physical inventions, despite attempts at proprietary tools and parts, and reduced repairability, there is always the ability to dissect the item and inspect it. Software is unique among all types of invention due to stark difference between the source code and compiled binary. Anyone can pop the hood of a car and tear down the engine one by one. Even if the manufacturer attempts to use proprietary screw shapes, or intentionally makes components difficult to open, the physical means will always exist. This allows true competition, as good ideas cannot remain a secret, and can only be protected through legal means like patents and copyright. This is not so with software, in that while there can be some limited reverse engineering from binary to original source code, this process leads to a very low-level and difficult to parse output that is very different than the code used to create it. Nearly any amount of spyware and malware can be hidden therein (thus the sandboxing model of GrapheneOS, limiting the damage of such software) and there's no means of building on these proprietary binaries by third parties to make improvements or to build on the work of what came before. Proprietary software inherently creates a fractioned world in which developers constantly reinvent the wheel, creating unoptimized and convoluted solutions to problems solved decades before.
In summary, proprietary software deprives the user of their ability to properly consent to it's execution on their device since they are unable to verify every function it plans to perform. It inherently puts the integrity of your system, and your information, at risk. It also disincentivises optimization and efficiency in software design leading to bloated monstrocities like Windows or most modern Javascript websites. It leads to e-waste and centralizes power. When privacy, self sovereignty and personal security are of concern, FOSS offers a brighter path forward