cubesnooper
Joined 4 years ago
Joined 4 years ago
Before using VPSes, I hosted from my home IP directly. This has serious privacy downsides: from your IP address, it’s mostly trivial to find out who you are (e.g., by seeing your IP has port 443 open and checking the domain names of your TLS certificates), and from your domain name, it’s trivial to find out where you live (by way of the ISP whose IP address your domain points to). Using a VPN for general browsing helps with the first point but not the second. There’s also the threat of DDOS (if your server gets attacked you lose access to the Internet entirely, and then you’re really in trouble). Also, residential ISPs are rare and people who need a static IP (or even a non‐CGNAT IP) are not reliably catered to; VPS companies have plenty of competition and having a publicly accessible IP address is the default.
Once I started running VPSes, I ran many services directly on the VPS. Over the years, I’ve migrated everything to physical hardware in my house (or a secure offsite location), for privacy and performance reasons. I can add as much storage and RAM as I want. Incoming connections are port‐forwarded over WireGuard to my LAN, so the VPS provider can only gather metadata from encrypted connections. Unfortunately the game servers mostly don’t support TLS; I’d prefer to hide them behind a VPN, but that would be too difficult for the players.
I actually use three VPSes, each in a different datacenter. VPS downtime (that’s not caused by me) is pretty rare, but happens periodically, and is almost entirely due to maintenance being performed in the datacenter. Email and DNS both support redundancy.
My VPSes are from different providers, too. One time an OS bug caused high CPU usage for an extended time, and the provider nearly terminated my account on suspicion of crypto mining. If a particular company ever drops me or goes out of business, I can just change a few DNS records and firewall rules and be back in business.
The vast majority of my downtime has been from power outages at home and the residential ISP going down (it's crazy how often that happens, I had no idea until I started measuring it). So I got a second residential ISP. If one route goes down, the VPSes port forward over the other, or over a third route to my offsite LAN.
Each service runs in a separate VM. Some might consider that overkill, but I like how simple it is to move VMs between hosts. Services run as unprivileged non‐root users with no ability to initiate outgoing connections.
Services for which I’m the only user stay entirely within the LAN. I do have extrnal access to the LAN, three ways: WireGuard, SSH, and HTTP proxy. The proxy is a last resort, but it’s been a lifesaver when I was stuck for a week at a conference whose wifi blocked SSH and WireGuard (in fact, everything but HTTPS and DNS).
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!
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.
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.
https://old.reddittorjg6rue252oqsxryoxengawnmo46qy4kyii5wtqn...
https://www.facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg...
(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.)
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.
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.)
After I drove the vehicle home, I noticed this sticker on the console: https://www.toyotanation.com/attachments/venza-cellularwarni...
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.
In eight years, I’ve seen zero servers that refused STARTTLS, and only two invalid certificates. In both cases, the certificates were from a valid CA and weren’t expired, but the hostname was wrong. Both were due to outdated DNS records, one of which was fixed as soon as I reported it, and the other resolved itself after a few months.