There’s a big caveat to this that I wrote about here some time ago. The first thing that I would add to this discussion though is that there is a third, mutually-exclusive category that is often neglected or conflated: anonymity.
When you unbox a new Pixel device, you have to give it internet access before the carrier OEM unlock toggle is available. Keeping in mind that Google is a data company that was propped up out of the Massive Digital Data Services (MDDS) initiative by CIA and NSA. The device in factory state, right out of the box begins harvesting data without any hesitation.
So for those who are aiming for any expectations of anonymity from Google in their personal OPSEC modeling with these devices, you should do everything possible for plausible deniability to limit its data collection activities until you have booted into GOS or whatever alternative de-Googled image build that you’re installing onto the device. This means countering for the:
- Front and rear facing cameras
- Geolocation data (GPS, WLAN, BT, cellular radios)
- Google also collects and stores infinitely the MAC addresses of all nearby devices and their signal strengths within proximity of the Pixel (the government is also privy to this data)
- Front facing thermal imaging sensor
- Fingerprint scanning module on the front display
That’s all required for getting the device reconfigured to allow for a non-factory image to be installed (GrapheneOS, Calyx, whatever).
I’m saying all of this as someone who has strong and unique background in this arena going back to the early 2000’s with skin in the game. I tell people that in order to take the right corrective measures for their technology posture, they must have an accurate understanding of the true adversarial landscape, and differentiate between security, privacy, and anonymity. We are not only dealing with technical problems, but also human behavioral issues that are challenging to fix, so correcting the overall posture requires a proper understanding of what those problems are in order to develop realistic expectations for the solutions identified.
The adversarial landscape for all of this is on orders of magnitude worse than most people could imagine, with big tech-gov at the forefront. There’s a lot of FUD on cyber-criminals , as it’s becoming very difficult for them to operate. The most successful are those who are operated by or in cooperation with state-level actors. Overall, I sense the landscape looks more like this:
The Venn diagram relationship of big tech > daddy gov are represented as a single circle, i.e. - they are one in the same adversarially to our privacy, anonimity, and ultimately our security. Similarly for telcos, and now thanks to the recent changes to FISA 702 -
“…any company or individual that provides ANY service whatsoever can be forced to assist in government surveillance, provides that they have access to the equipment on which communications are transmitted or stored”.
What I really want to stress is that it’s technologically impossible to expect perfect privacy, security, and anonymity with any smartphone, given the offensive capabilities in the hands of governments and the private sector partnership. Certainly not over any extended period of time. I’m not at all saying that a Pixel with GrapheneOS is futile, because it’s far worse to do nothing at all and allow Apple, Google, and everyone else making devices to harvest data from you, your thoughts and brainwaves, and those in close proximity to the devices. Rather, it can solve for a specific set of security and privacy-related problems and use cases (i.e., it’s a not a magic bullet solution).
You can expect a much higher degree of exploit mitigation using a GrapheneOS Pixel device with the default browser and base applications. The 3rd party apps are what tends to compromise security and privacy. Google Play Services is sandboxed in GrapheneOS, but I would never consider installing it to any device profiles. I just don’t need it, nor do I want it installed.
Session - it’s a fork of Signal that uses the Oxen network. It doesn’t require any phone or email registration. You can run it in “slow” notifcation mode so that it polls for new messages periodically and doesn’t require Google Play Services for push notifications. Biggest user experience caveat with Session on Android and Linux is the inability to send images or videos larger than 10MB. They somehow managed to implement data chunking in the iOS version, which doesn’t have that sending limitation.
PW managers - Personally not a fan of BW for serval reasons. KeePassDX setup with Argon2ID and a dedicated vault for the device with biometric unlock (backed by the Titan hardware security module) is solid and usable.
SIM swap attacks and the Efani MVNO - Efani is an MVNO like US Mobile, Cricket Wireless, et al. Their primary val-prop is mitigating SIM swap attacks on higher net worth individuals. The background on SIM swap attacks is this - there are many banks that use an absurdly insecure and antiquated 3rd party authentication service as a primary factor for customer identify verification. ALL that this 3rd party service really does behind the scenes is check the bank account holders name against the billing name tied to the mobile SIM card / IMSI associated with the phone number that is calling into the bank. They cannot and will not hide the identity of customers from court ordered subpoenas, but in the case of modern authoritarians- FISA grants the gov this visibility.
The reason this is an insecure authentication factor is because there have been instances where an attacker has either tricked the mobile provider, had someone on the inside, or directly breached their system to replace the subscriber’s SIM card with an eSIM on a device that they control - thus stealing your SIM card and mobile number.
An anecdote from my recent past, I opened a new checking account with a local / regional financial institution, I had an account-related issue that required customer support. The number that I had on my account was a VoIP DID, and the unhelpful robotic overseas customer service rep informed me that I could not be verified because the caller ID in the (CNAM) database did not match my name on the bank account. So I updated the VoIP DID entry and changed the caller ID arbitrarily to match, had them try again and it PASSED he authentication step. This kind of authentication is INEFFECTIVE and should NEVER be used by any financial institutions, and yet they’re somehow permitted to use it.
I’ll stop there!
.