Let’s Talk Password Vaults

When “civilians” asks me what the most important thing they can do to protect the security of their home computers, I always answer the same way – make sure you patch and do so automatically! However, as Windows 10 finally has started defaulting to this behaviour (and they seem to be taking security way more seriously at Microsoft these days), my next favourite recommendation for folks is that they invest energy in a password vault.

For the uninitiated, a password vault is a piece of software that stores the passwords you use on various services and then encrypts them with a master password so that they are safe. “Since I use password123 as the password for all of the sites I visit, why would I need that”, you might be saying. Arrrrggggghhhh!!!!

You should use a unique, long, complex and randomly-generated password for every site you visit! How can anyone who is not superhuman do that? Well, it’s a bit circular but see above – a password vault. The good ones will even help you generate passwords and give you a health report on the ones you store in it, indicating that they might not be long enough, etc.

Ah, but my fellow paranoids might be thinking that this puts all of your eggs in one basket. And if you store them in the cloud (someone else’s computer) then OMG! Doomsday scenario! Well, I have a plan for that (no, I’m not secretly Elizabeth Warren)! Be all self-hosted with it!

So, how do I recommend setting things up? First things first, you need a place to store the password file. You could put it on your local hard drive but that would make it difficult to use it across your multiple devices (most everyone has a smart phone these days and you want to be as secure on that device as you are on your home computer). As I always recommend, put that file on a server in a country that has strong privacy laws and isn’t part of the dreaded Fourteen Eyes. Switzerland is a good choice and there are Swiss owned VPS providers who will give you a small virtual server for a reasonable monthly fee.

I recommend the open source project “NextCloud” as a good self-hosted service to run for this purpose. It is incredibly flexible and has a very active community around it creating all sorts of plugins, etc. You can buy space on a public NextCloud server but that would defeat the whole purpose of having the control of the server yourself and putting it in a country that is safer. There is a great tutorial on DigitalOcean for setting up NextCloud on an Ubuntu LTS release that I’d recommend you reference. While you are at it, take a look at their “initial Ubuntu server setup” for some other security recommendations. Add to it a LetsEncrypt certificate with automatic renewal set up and you have a pretty decent platform for storing your files.

OK. There are two ways you can get your password file to/from the server. You can either share it directly from your NextCloud server using WebDAV or you can just install the NextCloud desktop client software (available for pretty much every operating system) to sync a local folder with a folder on your NextCloud server. Typically I use the sync solution for desktops/laptops and the WebDAV solution for my mobile devices.

Now, you have a place to store files but what file are you going to store there? More specifically, what password vault software do I recommend if you want to go the self-hosted route. Well, I really really really like KeePassXC as my password vault software and file format of choice. It’s well-written, free, open source, what isn’t there to love about it!

To set it up, install the software on your desktop/laptop and create a new password database in your directory you are syncing to NextCloud. Make sure you pick a complex, random, long password that you can remember without writing it down as the master password for the vault. If you want to get even more secure, check out the Yubikey option for two factor authentication for your vault. You can also set up the browser extension for it if you want the convenience, but keep in mind it does increase your attack surface so you might just want to go old school and copy paste the credentials from the KeePassXC client software.

For Android and iOS, I use the app “Strongbox” and, as I mentioned above, use WebDAV over https as the way I read and write the file from my NextCloud server. The end result is that I have a single, secure password file that, even if my NextCloud server is compromised, is encrypted and would be a nightmare to try and hack your way into given the length, complexity and randomness of my master password.

KeePassXC has some really nice features you probably want to start leveraging right away. It has a great random password generator so that you can create crazy complex passwords that are unique for each service you use. In addition, it has a “Health Check” report that you can run to check up on your stable of credentials to make sure you aren’t re-using any of them or have some that are not complex enough.

In addition there is an integration with “HaveIBeenPwned” that allows you to check to see if any of the credentials you use have been exposed in a data breach. It does so by sending a secure, cryptographic hash of part of your password to the service so your risk is minimal other than your IP address being exposed to the service. All in all, I trust the author of the service and think it’s a great thing to do periodically.

Finally, I recommend taking a look at the security settings in your KeePassXC client or your Strongbox app. There is a feature that clears your clipboard and logs you out of the application after a period of inactivity. That’s literally the first thing I turn on when I install either of the applications because it keeps you from having your device stolen and being logged into the most secure thing you probably have.

All in all, I hope you enjoyed this post. I really do think that password vaults are an incredibly important development in the field of cybersecurity and would encourage everyone to use them, even if you want to go with a commercial one that you don’t have to self host.

Fast Follower – Even More Privacy Centric DNS!

After posting this blog entry, I had a number of people reach out to me to tell me that, while my configuration recommendations were good, there was something new in the DNScrypt protocol that I could take advantage of to make my DNS even more obfuscated – “Annonymized DNS”.

The way this protocol works is that you send your encrypted DNS request to a relay (which can’t decrypt it). The relay then sends the encrypted request to your resolver. The resolver decrypts the request, resolves it and sends the encrypted answer back to the relay. The relay (which can’t decrypt the answer either), sends the encrypted answer back to you where you can decrypt it and stick it in the cache.

If you followed all of that, the relay (even if it is evil and logging the heck out of everything you do) can’t know what your request is. It only passes it along. The resolver (again, it could be evil and logging stuff too) does know your request but doesn’t know that it is coming from you! It only knows that the request came from the relay.

This is a pretty cool thing when it comes to making your DNS resolution even more private!

To make this work with the setup (regardless of the operating system), you simply need to add one more section to your dnscrypt-proxy.toml configuration file:

[anonymized_dns]routes = [
{ server_name=’cs-ch’, via=[‘sdns://gRE1MS4xNTguMTY2Ljk3OjQ0Mw’] },
{ server_name=’faelix-ch-ipv4′, via=[‘sdns://gRMxODUuMjUzLjE1NC42Njo0MzQz’] },
{ server_name=’yofiji-se-ipv6′, via=[‘sdns://gS5bMmEwMjoxMjA1OjM0ZTc6OGUzMDpiMjZlOmJmZmY6ZmUxZDplMTliXTo4NDQz’] }

The server_name fields should be recognizable because they are the ones that you listed for your resolvers. The sdns mumbo-jumbo is the name of the relay you are asking to use for each one of them. They are published on this page. I’d recommend picking ones in countries you like and that are different providers from the resolvers. If you have an evil service provider that runs both a relay and a resolver, they could piece the traffic back together. If they are different entities, it is far less likely that they would.


Fixing an OpSec Hole…

As return readers of this blog know, I try pretty hard to maximize my privacy and security online and also share what I’ve learned with the readers. One (in retrospect) painfully obvious hole, however, in my operational security (OpSec for the cool kids) is that I use the same bloody username for most of my online accounts. It doesn’t take a data brokerage genius to figure out that all of these accounts are owned by the same person. Duh!

So if you are a creature of habit like I am and would like to improve your operational security, I thought this would be a helpful post. I’m going to outline just how to do this along with some tools that are pretty useful as well. First off, what’s the best way to come up with a new username for a service that won’t give away who you are? Turns out, there are a variety of websites that will generate readable, random usernames for you. One that I found particularly helpful was from LastPass, a password vault application.

Thus armed, it’s now down to the laborious process of figuring out if you can rename your account on a variety of services and, if not, deleting and recreating said account by hand. You might also want to consider deleting some of these accounts if you don’t use them any more. That will reduce your personal attack surface in the event that one of these services is breached.

Just for fun, I have a set of links below that I discovered that should save you some time if you frequent these sites / services. What’s surprising is how many of these services do not let you rename your account. For those, it’s best to delete it unless there are specific digital purchased tied to that account (damn you Steam!).

After you think you are done, do yourself a favour and do a DuckDuckGo search of your commonly-used username. You might find some accounts out there that you had forgotten about. Chances are, if you forgot them you probably don’t use them so take the opportunity to delete them and decrease your attack surface further.

How To: Privacy-centric DNS

For those who aren’t as technically minded, it’s worth talking about what happens when you type a URL into your web browser and how that impacts privacy. The first thing is that the string you type in, say https://mycoolsite.com needs to be turned into a numeric IP address. This is done using a protocol called “Domain Name Service” or DNS that is as old as the hills. When you get an IP address from your Internet Service Provider (ISP), it’s usually done using something called Dynamic Host Configuration Protocol, or DHCP. At the same time you get that IP address, the ISPs DHCP server will generally pass other configuration parameters such as your DNS server.

OK, so that’s the mechanics of it. What is the privacy implication. Well, ISPs like to make money. And while they make money from you by providing you with Internet service, they also like to make money other ways. One of those is selling information on you to data brokers and advertisers. Since they are turning your URLs into IP addresses using their servers, it’s a pretty easy thing for them to sell the URLs that you like to visit to those data brokers and advertisers. Given that they have to log this information in order to sell it, they can also turn it over to government agencies when they are either subpoenaed or (worst case) handed a national security letter which they can’t even disclose that they were given.

In other words, your ISP knows every web site you visit and happily tells other people about it that you might not want told. Let that sink in for a moment. All of the work you might (or might not <sigh>) do to stay private online goes out the window when you type that address into your URL. By the way, this also goes for your mobile service provider. When you are out and about (i.e. not on WiFi), your cell service provider is your ISP and they have all of that same power and information. Yikes, eh?

So, what can you do about it? Well, using some other regular DNS provider like Google (with the famous DNS server) or CloudFlare doesn’t really help because who trusts their motives? You could use a privacy-respecting DNS provider that doesn’t log their information and has a warrant canary (a mechanism where they regularly post on their website that they haven’t been issued a national security letter until they stop posting that – which means they have), but since the DNS protocol is as old as the hills, that traffic is sent unencrypted over the internet and an adversary could capture it anyhow.

What to do? Well, there is a clever multi-part solution that I’m going to outline here for Linux, OpenBSD (of course) and Windows. It involves running a local DNS resolver on your laptop or desktop machine (why let your ISP resolve them when you can do so yourself) and when your local resolver doesn’t know the answer, using a protocol called DNScrypt to send that DNS request in an encrypted fashion, upstream to a DNS server that doesn’t log and is privacy respecting. It’s not airtight (that upstream server could be lying about being privacy respecting or could get compromised and not even know it) but like most privacy and security, the goal isn’t to be perfect, it’s to make yourself a much harder target so that the bad guys look for easier sheep to fleece.


For my example in Linux, I’ll be using Ubuntu 20.10 as the target operating system and version so if you are on a different distribution, your mileage may vary but the building blocks will be the same. I based this how-to on a combination of a Reddit post that I found while searching DuckDuckGo (you REALLY should stop using Google and who uses Bing anyhow?), a great article on LinuxConfig that I found the same way and finally

First things first, you need to install the necessary open source tools:

# apt install dnscrypt-proxy dnsmasq

Next, add the line “dns=” to the [main] section in your local /etc/NetworkManager/NetworkManager.conf file. This tells NetworkManager to force the DNS manager to be the one installed locally (hence the “localhost” bit) on your machine.

After that is out of the way (please don’t reboot now because you won’t have the necessary other bits configured, please be patient <grin>), edit your local /etc/dnscrypt-proxy/dnscrypt-proxy.toml configuration file to set up the upstream server you want to use. I’d recommend taking a look at this list because 1) it’s from the documentation site for DNScrypt; and 2) it has a list of servers that are privacy respecting and don’t log connections. I’d also recommend refreshing your memory as to who the “Fourteen Eyes” nations are who do intelligence sharing with the US and try to pick a resolver that is in a country not on that list. Just sayin’…

Anyhow, add the following lines in the global section of the file:

listen_addresses = [‘′,'[::1]:53000’]
server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

I chose to use multiple servers in my configuration to make it resilient in case one of them happens to fail. I’m making the assumption (check my math on this) that the first two (the ones in Switzerland – my privacy-respecting country of choice) are the primary and the other one is there as a back-up in case the first two don’t respond.

Because I couldn’t get the “listen_addresses” bit working from the config file (I left it in there just in case), I also edited the /etc/systemd/system/sockets.target.wants/dnscrypt-proxy.socket file to specify the port I want this service running on. In the [Socket] section, I modified the two lines with the port 53000 setting that I have in the config file:


Now that we have DNScrypt set up, we need to set up the dnsmasq service to be our local, lightweight caching resolver that forwards its upstream resolution requests to DNScrypt. To do this, we need to edit it’s configuration file /etc/dnsmasq.conf and add the following lines (the default file has everything commented out so instead of searching for them and un-commenting them, I just slammed this at the end of the file):


After setting this up, there is a REALLY IMPORTANT STEP you need to do and that is to disable systemd-resolvd:

# sudo systemctl disable systemd-resolved

After you have done this, you should be able to reboot and resolve DNS names (easy test, go to a site you rarely visit in your browser). To verify that it is your privacy-respecting configuration that is doing this, try the following tests:

# sudo lsof -iTCP:53000 -sTCP:LISTEN

You should see several lines showing tha t the proxess “dnscrypt” running as user “_dnscrypt-proxy” is listening on this socket.

Next, check who is listening on port 53 (the “regular” DNS port):

# sudo lsof -iTCP:53 -STCP:LISTEN

You should see that the process ‘dnsmasq’ running as user ‘dnsmasq’ is listening on this socket. So far so good.

Now, use the ‘dig’ command to force the resolution of a URL that you don’t normally visit:

# dig -t A microsoft.com @

You should get a display of the IPs that match that URL. Finally, if you are really paranoid (and I am), verify that by turning off dnscrypt-proxy that you CANNOT resolve DNS queries:

# systemctl stop dnscrypt-proxy
# systemctl stop dnscrypt-proxy.socket
# dig -t A oracle.com @
# dig -t A oracle.com

This should fail to resolve things. Make sure you restart the two systemd services after you have verified this.

Congratulations. You have just significantly improved the privacy of your machine. Now go do this on all of your Linux systems.


I listed these sections in alphabetical order so don’t read into my choice of having “Linux” first as an indication that I don’t love me some OpenBSD! For this part, I used my coreboot+tianocore Thinkpad T440p running OpenBSD 6.8 off of a secondary drive (the primary drive had the fresh Windows 10 install on it for the Windows version of this how-to).

First things first, we need to install dnscrypt-proxy:

# pkg_add dnscrypt-proxy

The configuration file is logically /etc/dnscrypt-proxy.toml and you need to edit it and add our server_names and listen_addresses to it:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]
listen_addresses = [‘′,'[::1]:53000’]

Once you have that saved, you should enable the daemon using the following command:

# rcctl enable dnscrypt_proxy

Note the underscore instead of a dash there for the daemon name. Now start it up:

# rcctl start dnscrypt_proxy

To verify that the daemon is running and listening on our desired port, simply use netstat:

# netstat -an | grep LISTEN

You should see that there is a process listening on port 53000 in both localhost IPv4 and IPv6.

Now we need to get a local resolver running and forwarding to DNScrypt. Fortunately, OpenBSD has a really nice builtin one called unbound. Enable and start it using the following commands:

# rcctl enable unbound
# rcctl start unbound

Now we need to tweak our dhcp configuration (if you are not running a static IP address) to override any “suggested” name server from your dhcp server. To do that, edit the /etc/dhclient.conf file and add the line:

supersede domain-name-servers;

Restart your network with the following command:

# sh /etc/netstart

And then check your /etc/resolv.conf file to verify that the name server is in there along with no other.

Use the following commands to verify that your DNS resolution is working using unbound locally:

# dig -t A microsoft.com @
# dig -t A microsoft.com

Assuming that goes well, now we need to edit unbound’s configuration file to use localhost port 53000 for our upstream resolver. That file is in /var/unbound/etc/unbound.conf and you need to edit the forward-zone section to look like this:

name “.”

In addition, in the “server:” section of the file, you need to add the following line in order to get the forwarding working properly between the unbound daemon and the dnscrypt-proxy daemon. Without it, localhost will be ignored for queries:

do-not-query-localhost: no

Use the following commands to restart the service and validate that name resolution is working:

# rcctl restart unbound
# dig -t A oracle.com @
# dig -t A oracle.com

Now, to verify that you have unbound listening on port 53 and dnscrypt-proxy listening on port 53000, run the following:

# netstat -an | grep LISTEN

If you see listening processes on both the IPv4 and IPv6 ports, you should be good. Finally, to verify that the upstream requests are being forwarded to dnscrypt-proxy, stop its daemon and test using dig:

# rcctl stop dnscrypt_proxy


OK. Whew. I’m going to be a bit out of my depth on this one (I’m not a big-time Windows power user any more) but the Internet has some good stuff on it so here goes nothing. For my setup, I had a dead-fresh install of Windows 10 on my coreboot + tianocore Thinkpad T440p that I’m using. I figured that way no extra configuration would get in there that might mess things up.

I figured there are a lot of bad actors on the Internet who might post some bad info on how to set this up in such as way as to route all of your traffic to them (forgive me, I’m paranoid <grin>), so I thought the best place to go would be the GitHub repository for the DNScrypt-proxy project.

From there, I clicked the link to download the latest version of DNScrypt-proxy for Windows. Given that, I read the documentation on how to install the service myself, not using a possibly compromised “helper”. Also, this helps me learn where the files are and how to configure things which is always good. I’ll document my process here. From this point forward, assume that I’m running a PowerShell command prompt with the “run as Administrator” option.

I copied the contents of the “win64” directory to C:\Program Files\DNScrypt-proxy to start things off. Best to have it in a “standard” (I think) place. I then move to that as my current directory. Next, copy the example-dnscrypt-proxy.toml file to “dnscrypt-proxy.toml”:

PS > copy example-dnscrypt-proxy.toml dnscrypt-proxy.toml

Edit the file using notepad (I guess) to have the same server_names line that we had for the Linux install above:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

Now, let’s make sure everything is working by running ./dnscrypt-proxy from that PowerShell prompt:

PS > ./dnscrypt-proxy

You should see some diagnostic information finishing up with “dnscrypt-proxy is ready – live servers: 2” in your PowerShell prompt.

The instructions are a little off on the version of the page I was looking at (or maybe my Windows 10 fu is weak). Anyhow, I went old-school and went to my “Wi-Fi” settings in the UI and selected “Change adapter options” from the link on the right. I then went to my “Ethernet” and “Wi-Fi” icons, right clicked on them, selected “Properties” and then went to the “Internet Protocol Version 4 (TCP/IPv4)” item and clicked the “Properties” button.

For both adapters (Ethernet and Wi-Fi), I changed the page to “Use the following DNS server addresses” radio button and entered in the “Prefered DNS server” address and “” as the “Alternate DNS server” per the instructions. Just for shits and giggles I checked the “Validate settings upon exit” checkbox and hit OK. I didn’t get any error messages so I’m assuming it’s good.

I then repeated the process with the IPv6 properties, setting the “Preferred DNS Server” to “::1” (without the quotes) – the equivalent of localhost in IPv6 land. I also set the “Alternate DNS server” to “0:0:0:0:0:ffff:909:909” which is the IPv6 address of that server.

Back to the PowerShell prompt, I hit “Ctrl+C” to break out of the dnscrypt-proxy process that was running and executed the following command:

PS > ./dnscrypt-proxy -resolve example.com

This successfully verified that I was able to resolve the DNS query using my configuration file. Now for the fun part, installing the service. To do this, run the following command:

PS > ./dnscrypt-proxy -service install

If you don’t get any error messages, start the service:

PS > ./dnscrypt-proxy -service start

Assuming you are error free there, you actually have a working (without a local caching resolver) install of DNScrypt-proxy. The final step is to fiddle with a Windows 10 group policy setting for the Network Connect Status Indicator (NCSI) to prevent it from showing your network as “offline”.

To do this, run “gpedit.msc” to launch the Group Policy Editor. From there, drill down to:

Computer Configuration -> Administrative Templates -> Network .> Network Connectivity Status Indicator

In the right-hand pane, select the “Specify global DNS” policy and click the “Enabled” radio button. Now check the “Use global DNS” checkbox and hit OK.

At this point you should be safe to reboot and verify that things are working. After the reboot, bring up a “run as Administrator” PowerShell prompt and run the following command:

PS > netstat -a -b

You should see dnscrypt-proxy.exe listening on port 53 of the localhost IP address. Bring up a browser and hit a site you rarely visit to verify that you have name resolution working.

I don’t have the local cache part of this working on Windows yet but all I’m losing there is efficiency because I’m doing the DNS lookup each time I need to resolve something. All said, I think I improved the privacy of my Windows 10 install by a non-zero amount! 🙂


So what about mobile? That tends to be a platform that we all spend a lot of time on these days and I’d hate to leave it out. While my experience and expertise doesn’t allow me to truly test that this works like I can on desktop operating systems where I can use tcpdump, turn services on or off, etc. some sites that I trust lay down some recommendations that appear to be working when I test them. Therefore, use this at your own risk and do testing that you think makes sense for you and your threat model.

For iOS, I found the following link from PrivacyTools.IO (one of my favorite sites) that walks you through how to use an app on the iPhone to run dnscrypt-proxy as your local DNS resolver on iOS. Essentially, you need to install the app, click on the “edit” button in the toolbar when you launch it and add our standard “server_names” line below, then hit the checkmark button in the toolbar to save it:

server_names = [‘cs-ch’,’faelix-ch-ipv4′,’yofiji-se-ipv6′]

Then, you will want to click on the “hamburger button” in the toolbar on the left and turn on the “Connect On Demand” general option. After that I rebooted my phone just for good measure and I appear to be up and running.

For Android, I found an application on the Google Play store called Quad9Connect. It appears to use secure DNS to access servers but it lacks the fine-grained control I would like in order to specify which countries I want those DNS queries to be tunnelled through.

Another Android app that I have seen recommended on a variety of sites is InviZible Pro. This app allows you to have more control over your DNScrypt-proxy setup. The settings I’m running with are to turn off the Tor support, leave the DNSCrypt support on and set it to run at boot-time. I also turn on the “require_nolog” feature in the DNSCrypt Settings page. Finally, I go into the Network & Internet settings in Android, selecct VPN, select settings for InviZible Pro and enable “Always-on VPN”.

Save Me from the Data Brokers!

In looking back over my most recent posts on this blog, I’m noticing a pattern. I’m tending to focus on technical aspects of privacy and security and am leaning more towards the security side of things. Given that I want to be balanced in the information I share here at FunctionallyParanoid, I thought it would be a good time to start making a concerted effort to share some information that isn’t focused on installing operating systems or configuring software. In this post, I’m going to talk to you about the evil role of “data brokers” in the world today and what you can do to limit their nefarious impact on your life.

Data brokers are not a new invention of our modern computer age. They have been around for thousands of years. As long as a given piece of information had value to someone else, they work to maximize that value and monetize it to their benefit. For example, if you knew the location of an invading army, you could sell that location to the country being invaded, regardless of whether it was the twenty-first century or the first century. For that matter, you could then turn around and sell the fact that the element of surprise was lost to the invading army and suggest they take a different route for their invasion and so on. Nice work if you can get it, eh?

The modern data brokers also set themselves up to sell the same information multiple times. What they do is comb through tons of data – things like mailing lists for catalogues, marketing databases, etc. They then correlate that information and assemble a dossier on each person that they can tease out. Once they assemble that dossier, they can then sell it to firms that want to market to you, to people trying to track you down to collect on a debt, whatever. The information is for sale to the highest bidder.

Yes, there are some limitations to what they can do, but it really depends on where you live. For example, if you live in California, there is a new data privacy law that places some realistic limits on these firms; however, if you live in Montana, you are pretty much on your own. There really isn’t a lot of privacy protection at the federal level.

Given that, what can you do? Well, for one, you can work to either correct or delete the information that these data brokers have on you. While there are services you can pay to do this on your behalf, I thought I’d do this the old fashioned way and see how good a job I can do using a little elbow grease and trying my hand at getting my information deleted.

The first thing you need to do is get a list of who the data brokers are. That is surprisingly difficult to do in a canonical way. However, after a series of DuckDuckGo searches (of course I use them and not Google – I’m FunctionallyParanoid after all), I was able to come up with the following list. What I’ll do is keep this post in draft form as I go through the process of requesting that my information be deleted and add tips and additional information on each broker as I knock them out.

As a sidebar, there is a service called Blur that allows you to get a free email forwarder that masks your email address. Essentially you put in your “blur” email address and then the email actually comes to you but the sender doesn’t really know what your true email address is. Might not be a bad idea to use a service like this for the removal emails where they require confirmation. Just a thought.

Here we go…


This is one of the big ones. You need to navigate to their opt out page and wade through a plethora of text about why this is a bad idea and you really should love having your data sold all over the place without you knowing who gets it. You then have to fill out a form at the bottom of that screen where the difference between the text and the white background is about +1 on the RGB scale – in other words, it is nearly indecipherable. After you squint your way through that, you will get an email that requires you to click a link to ensure that the information is deleted. As with all of these, set a calendar reminder to check back and ensure that your information has truly been removed.


This broker seems to be the easiest to deal with and pretty quick in terms of deleting the information. Go to their opt out page and search for your information. Once you find your record or records (I found old addresses listing me with different middle initials), click on each one, supply an email address (yes, you have to do this because they require you to click a link in the email they send you to actually kick off the removal process), help Google or whoever identify busses or fire hydrants, and then wait for that email to show up. Once you click the link, they will begin the process and have you removed in 24-48 hours. Put a calendar reminder out there to check that you have been removed and see if there are any other records that need to be deleted.


Another big one. These folks have not only the ability to sell your data for offline purposes, they can do it online. And, they purport to be able to connect the two. Yikes! To get your data removed, go to their opt out page and fill it out. Just like with Axciom above, you have to wade through some text to get to the form. Again, don’t forget to set a calendar reminder to check back and ensure that the data has been deleted.


This one is probably the easiest of the bunch. You simply navigate to their opt out page, search for yourself and then request that they delete the information. As with all of these, put a calendar reminder in your calendar to ensure that the information has been deleted.


This one is a pain. You have to “join” their service (which to me seems to indicate that they have more accurate information on you) but you can obfuscate that information. Anyhow, once you join you can then search for your information and send an email to privacy@mylife.com to have them remove you. Include the URL from your search in the email and don’t forget to put a calendar reminder in to verify that it has been deleted.


Similar to the others, you first have to search for your record on their site. You then copy the URL from your browser’s address bar and paste it into the opt out form to have them remove your information. They will notify you when the information is removed. When they did, I actually checked and my information was NOT removed. An email to customer service corrected the issue and my information was removed.


This one is pretty similar to many of the others. Go to their search page and look for yourself. Once you find a record you wish to remove, click on it, save the URL from your browser’s address bar and supply it to their opt out page. As with all of these, you’ll have some email interaction with them and they will let you know you have started the process. I strongly recommend taking their timeframe for removal and putting a reminder in your calendar to check up on it and make sure the information is truly gone.


This one is more pernicious. They seem to have lots of different records of me that need to be deleted. The process is pretty straightforward, however. You go to their search page and look for your information. After you find your listing, if you are fortunate enough to see one with an arrow at the right, click on that and copy the resulting URL from the address bar. You can then go to their opt out page, provide the URL and go through the request process. Since this broker sources from public records, I can’t find a way to delete their “premium search” and they still list your personal information (such as home address) on their search pages. To get around this, I tried using their CCPA opt out form because my records can be found by searching an address in California.


To net this out, it’s a few minutes worth of work but the end result is that your data isn’t being monetized by some faceless corporation somewhere. If you then have good hygeine on your privacy, perhaps you can reduce your data footprint to keep from being an interesting target for these brokers. Either way, it is probably worth checking in on your status on these sites a couple of times a year or more.