Tor is great at reducing tracking done by ad companies. I use Facebook and Reddit (a big chunk of my social media activity) exclusively over Tor.
Step 1, block all Facebook and Reddit domains and subdomains at the DNS level. This is not to prevent visiting the cleartext websites (I could just, you know, not visit them), it’s to block the Like buttons and Reddit share icons embedded in normal websites from tracking my browsing activity.
Step 2, bookmark the Reddit and Facebook onion sites in Tor Browser.
These are faster and more secure than visiting reddit.com and facebook.com in Tor Browser (hidden services require fewer hops and have no exit node), and since they’re official means of accessing their respective sites, you’re less likely to get treated as a bot or banned for suspicious activity.
How well does this work? Pretty well, if the ads I get are any indication. Facebook and Reddit ads used to be highly correlated to my general browsing activity. When I first started doing this, I would still log in without Tor occasionally, and instantly ads would start matching my browsing activity again. Now that I’ve used these sites exclusively over Tor for years, the ads are either entirely random or based solely on my activity within the respective sites (which is exactly what I want), or they expose a privacy leak from something other than IP address or cookies (for example, it’s clear from the ads I get that my bank sells my credit card purchase history to Facebook, which has made me more open to using cash).
As long as Tor Browser isn’t illegal or dangerous to possess in your jurisdiction, I highly recommend downloading it and using it for mainstream sites that provide onion services. I wish more sites would provide them!
Once you’ve had the PIN scramble turned on for a while, it becomes second nature. I enter my GrapheneOS scrambled PIN about as quickly as the unscrambled PIN on my non‐GrapheneOS work phone. But it’s more of a defense against figuring out my PIN from the finger marks on my screen.
In environments where shoulder surfing is a concern, I prefer to use the multiple profiles feature: log out of my main profile (which is actually a secondary profile) to completely evict its keys from memory, and switch to a burner secondary profile containing no personal data, which unlocks with my fingerprint for convenience.
Cell signal is terrible for privacy, uniquely identifying each individual’s location at all times. Though Wifi can also be tracked, it at least is possible to use anonymously with MAC randomization as is the default on many phones. (Leaving aside countries like Switzerland which outlaw wifi without mandatory registration.)
I browse social media sites like Facebook and Reddit using their onion services. I was sick of seeing ads pop up that were clearly based on tracking my general browsing activity through IP correlation, tracking pixels and embedded “like” buttons. So now I block all cleartext Facebook/Reddit traffic completely.
Using Tor this way doesn’t anonymize me—on Facebook at least, I’m logged in under my own account—but it limits the profile Meta builds on me to the union of what it directly observes on Facebook and what it can purchase through data brokers. Ever since I started doing this, I’ve noticed a huge drop in relevance in my Facebook ads, so apparently it’s working. When the ads become suddenly relevant again (which has happened a few times), it exposes an information leak: usually a credit card purchase that Meta must have obtained from either my bank or the shop vendor and tied to my identity.
Using a VPN could theoretically provide the same benefit, but in practice Facebook tended to temporarily lock my account when using a VPN and Reddit blocks VPN traffic completely. So I stick to the onion services, which are run by the websites themselves and so are less likely to be treated as malicious traffic.
If you use these platforms, I recommend bookmarking their onion sites in Tor Browser and using it as your primary interface to them for a while. Then, if you don’t find it too inconvenient, start blocking the non‐onion versions of the sites on your network.
(P.S.: You shouldn’t trust the links I just posted; I could have posted fake ones! I recommend double‐checking against https://github.com/alecmuffett/real-world-onion-sites which links to proofs of onion site ownership under their usual domain names.)
For games, the equivalent level of ownership comes from DRM‐free digital purchases. That means buying games from platforms like GOG, Itch, and Zoom Platform, and then backing them up. Steam is distantly behind in terms of user ownership—their installers are always DRM‐locked, but some games can be run DRM‐free after that—and Xbox, PlayStation and Nintendo aren’t even on the same planet due to their hideous DRM and online service tie‐ins.
An SSH key can be freely reused to log in to multiple SSH servers without compromise. Passwords should never be reused between multiple servers, because the other end could log it.
An SSH key can be stored in an agent, which provides some minor security benefits, and more importantly, adds a whole lot of convenience.
An SSH key can be tied to a Yubikey out of the box, providing strong 2FA.
I recently bought a 2024 Toyota RAV4. Throughout the purchasing process, I kept an eagle eye out for any data collection that I might accidentally opt into. This way I avoided a free trial of Toyota Safety Connect, which tracks the location of your vehicle at all times (with the justification that it can thus be located if stolen).
Incidentally, I took a peek at my sales rep’s computer screen and saw that Toyota kept a log of every interaction with me, whether initiated by me or the sales rep, including recordings and transcriptions of every phone call. This isn’t really surprising but it was certainly interesting to see. (The rep also surreptitiously looked through my own paperwork folder when I was distracted, and later made some innocuous remarks based on financial information I kept there.)
Per the instructions, I pressed the SOS button to turn off the data transmission. The voice on the other end agreed to do so, but the necessary first step was to install the Toyota app. This, apparently, is how Toyota verifies that I own the vehicle and have permission to disable data collection.
I didn’t have or want the app, so I asked if there was some other way to prove that I owned the vehicle. Could the dealership do this? The agent said yes. So I went back to the dealership, and asked the receptionist whom I could talk to to disable data collection without using the app. After expressing visible surprise and confusion and asking other people for help, she concluded that she had no idea who could do that, and gave me a Toyota phone number to call.
I called this line, and after explaining, was redirected to the multimedia unit team. The rep seemed helpful, and after thirty minutes of him researching, he said he might have some instructions I could follow, and only needed to confirm that he was authorized to give them to me. After a five minute wait, he backtracked, and said I had no other option except to install the app.
Defeated, I installed the app. My phone number was a mandatory field; I tried using a fake one, but linking the app to my car required entering the same phone number on the car’s entertainment system, which would text me a code that authenticated me to the car, so I had to use a real number. I believe the app also checked my physical location against the physical location transmitted to the car before finally granting access.
Finally, I opted out of data collection through the app. I was met with a notice: if I ever removed my VIN number from my Toyota app, the vehicle would automatically begin transmitting data again. So obviously the car is still constantly connected to Toyota!
The article suggests pulling the fuse of the Data Communication Module (which contains the cell modem used for transmission). This is a good idea, but there are some extra complications. First, as the article mentions, the microphone is routed through the DCM and pulling the fuse kills it—but the passenger‐side speakers are also routed through the DCM, and lose sound if the fuse is pulled. Second, the DCM has its own internal battery, and will continue to transmit data until the battery dies, even with the fuse pulled.
So my recommendation is not to pull the fuse, but to disconnect the DCM completely, and jump the audio wires to restore your passenger‐side speakers.
Soon enough, I expect the DCM will be integrated rather than an independent module. Who knows how we’ll disable data transmission then.
100% of the spam I’ve gotten over Signal in the past few years (two messages) has been from cryptocurrency scammers, exactly the sort of people who would have $5 in cryptocurrency many times over to create new accounts with.
I run OpenSMTPD, mostly because of how simple it is to configure but also how its privilege separated design has reduced the impact of bugs when they happen. (See Qualys’s sometimes complimentary comments in their OpenSMTPD vulnerability writeups.)
It’s really important to use a distro that you understand well and are comfortable keeping secure and up to date. For me that’s OpenBSD; for you it might be something else.
For security reasons, I recommend keeping the server setups simple, minimal, and isolated as much as possible. I have three machines: the sending server, the receiving server, and the VPS.
The VPS is the only machine directly accessible from the Internet, so it is locked down as much as possible: it forwards incoming port 25 over a WireGuard tunnel to the receiving server, it forwards traffic from a second WireGuard tunnel (from the sending server) to the Internet, and that’s it. No other services, and all other incoming and outcoming ports are blocked with the firewall. The SPF settings in my DNS list only this VPS’s IP address as a trusted sender, and the MX settings point to the VPS too.
The receiving server runs on a Raspberry Pi. Since it’s almost directly accessible from the Internet over port 25, this one’s heavily locked down too. It’s firewalled from making Internet connections except those relevant to mail receipt (incoming port 25, reverse DNS lookup, DMARC lookups, etc.). It delivers to a Maildir.
The sending server is an Intel NUC actually running two VMs, only one of which is for sending. The second VM is the viewing VM. It periodically rsyncs new mails from the receiving server to a Maildir. I interface with the Maildir directly by logging in with SSH and using command-line tools like mblaze and notmuch. This machine also runs Dovecot as an IMAP server backed by the Maildir; the IMAP is used by my phone, Thunderbird, and my self-hosted webmail (Roundcube).
The other VM, the sending VM, is what I point my mail clients’ outgoing SMTP settings to. It listens for outgoing mails from my LAN (requiring TLS client certificates for authentication), and sends them to the destination server, but with the traffic routed through the VPS so it looks like they came from there rather than a residential connection.
What I described is what I ran for a while, but over time I’ve added additional complexity for the sake of higher uptime. That’s not really necessary, since downtime was already rare and SMTP handles outages of a few hours gracefully, but like the progressive steps in my previous comment, after several months I was comfortable with my setup and wanted to push it further. Now there are two VPSes from different providers (mitigating downtime at one datacenter and the risk of being tied to one VPS provider), port forwarding to two MXes on my LAN. I’m planning to get a second ISP at home, so a VPS can have an alternate path to its MX if one ISP is down.
I’ve run my own email server for five years now. It’s surprisingly approachable when done piecemeal. I broke it into several pieces.
1. Switched from the GMail web interface and app to open source IMAP clients on phone and PC.
2. Switched away from gmail.com to my own domain, using Google as the provider. This was the hardest part, because I had to change my email address everywhere! It also meant setting up DMARC and SPF records for the domain.
3. Set up a VPS running an SMTP server in a MX configuration. At first I had the server relay over a VPN to a second machine in my house, but later I moved to port forwarding over the tunnel, so the VPS provider never sees the contents of my emails (as long as they’re encrypted). Of course, STARTTLS is subject to downgrade attacks, but this can be reduced somewhat with MTA-STS and DANE. And Google still saw my outgoing emails (but I receive way more private emails than I send, personally).
4. I wanted to remove the last vestige of Google, and also to hard-fail if the recipient doesn't support TLS, so I finally set up a sending SMTP server on my LAN, which routes outgoing mail through a VPN tunnel so it looks like it’s coming from the VPS instead of my home IP. The first few furtive emails I sent went straight to Google’s spam box, but the recipients marked them “not spam,” and I stopped having trouble with that. I can also send to Microsoft addresses. It’s reliable enough that I get replies whenever I expect them. Very rarely, it goes to spam, and I have to follow up with the recipient to mark it not spam—but this is very rare, and surprisingly, happens at about the frequency that it happened when I was using Google to send my mail. Really!
I took these steps months and sometimes years apart. Long enough to be 100% comfortable to move on to the next step, but I could just as easily have been satisfied and stopped at any point, and it would have been better than total dependence on the cloud. Overall maintenance effort is about inline with the other servers I run (DNS, HTTP, Minecraft).
Running your own mail is not for everybody, but “no longer practically possible” is a defeatist, demotivating overstatement.
You’ve given me something to think about. Luckily, I only have to amend my mental model a bit, to assume giving a permission to any vendor’s app is to give that permission to every app from that vendor. In most cases where that would be a problem, I already run such apps under a separate user profile, which fully prevents IPC.
According to the GrapheneOS FAQ: “As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs.”
> phone number
I don’t think it has access to this.
> location
You can turn off location permissions. Spoofing location (so the app doesn’t know it has no permission) is a planned feature but with no ETA.
> sensor data
You can turn off sensor permissions alongside other app permissions. This is another toggle present in GrapheneOS but not stock Android.
Yes, if the worry is that an app could offload data via the network, then turning off the network only provides a privacy benefit if the network stays off. That’s why the recommendation is to run Google apps in an isolated user profile, so they have no opportunity to collect data in the first place.
GrapheneOS allows disabling network for a particular app, alongside the other permission settings. As a rule, I’ll give an app either file permissions or network permissions, but almost never both.
A lot of apps are perfectly usable without file access by sharing a file to them from the file manager.
GrapheneOS also has “Contact Scopes,” so you can grant an app contacts access (so it thinks) but it’s actually a subset or blank list of contacts.
Another feature that’s commonly recommended is using multiple profiles. I often see people use this to run Google apps in an environment isolated from the rest of their data.
Step 1, block all Facebook and Reddit domains and subdomains at the DNS level. This is not to prevent visiting the cleartext websites (I could just, you know, not visit them), it’s to block the Like buttons and Reddit share icons embedded in normal websites from tracking my browsing activity.
Step 2, bookmark the Reddit and Facebook onion sites in Tor Browser.
https://www.reddittorjg6rue252oqsxryoxengawnmo46qy4kyii5wtqn... ; proof: https://www.reddit.com/r/redditsecurity/comments/yd6hqg/redd...
https://www.facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg... ; proof: https://www.facebook.com/onion-service
These are faster and more secure than visiting reddit.com and facebook.com in Tor Browser (hidden services require fewer hops and have no exit node), and since they’re official means of accessing their respective sites, you’re less likely to get treated as a bot or banned for suspicious activity.
How well does this work? Pretty well, if the ads I get are any indication. Facebook and Reddit ads used to be highly correlated to my general browsing activity. When I first started doing this, I would still log in without Tor occasionally, and instantly ads would start matching my browsing activity again. Now that I’ve used these sites exclusively over Tor for years, the ads are either entirely random or based solely on my activity within the respective sites (which is exactly what I want), or they expose a privacy leak from something other than IP address or cookies (for example, it’s clear from the ads I get that my bank sells my credit card purchase history to Facebook, which has made me more open to using cash).
As long as Tor Browser isn’t illegal or dangerous to possess in your jurisdiction, I highly recommend downloading it and using it for mainstream sites that provide onion services. I wish more sites would provide them!