Guide to Online Anonymity (by https://anonymousplanet.org/)

Use at your own risk. Please do not take this guide as a definitive truth for everything because it is not.
​

Spoiler: Table of Contents

• Introduction:
• Understanding some basics of how some information can lead back to you and how to mitigate some:
  • Your Network:
    • Your IP address:
    • Your DNS and IP requests:
    • Your RFID enabled devices:
    • The Wi-Fis and Bluetooth devices around you:
    • Malicious/Rogue Wi-Fi Access Points:
    • Your Anonymized Tor/VPN traffic:
    • Some Devices can be tracked even when offline:
  • Your Hardware Identifiers:
    • Your IMEI and IMSI (and by extension, your phone number):
    • Your Wi-Fi or Ethernet MAC address:
    • Your Bluetooth MAC address:
  • Your CPU:
  • Your Operating Systems and Apps telemetry services:
  • Your Smart devices in general:
  • Yourself:
    • Your Metadata including your Geo-Location:
    • Your Digital Fingerprint, Footprint, and Online Behavior:
    • Your Clues about your Real Life and OSINT:
    • Your Face, Voice, Biometrics and Pictures:
    • Phishing and Social Engineering:
  • Malware, exploits, and viruses:
    • Malware in your files/documents/e-mails:
    • Malware and Exploits in your apps and services:
    • Malicious USB devices:
    • Malware and backdoors in your Hardware Firmware and Operating System:
  • Your files, documents, pictures, and videos:
    • Properties and Metadata:
    • Watermarking:
    • Pixelized or Blurred Information:
  • Your Crypto currencies transactions:
  • Your Cloud backups/sync services:
  • Your Browser and Device Fingerprints:
  • Local Data Leaks and Forensics:
  • Bad Cryptography:
  • No logging but logging anyway policies:
  • Some Advanced targeted techniques:
  • Some bonus resources:
  • Notes:
• General Preparations:
  • Picking your route:
    • Timing limitations:
    • Budget/Material limitations:
    • Skills:
    • Adversaries (threats):
  • Steps for all routes:
    • Get an anonymous Phone number:
    • Get a USB key:
    • Find some safe places with decent public Wi-Fi:
  • The TAILS route:
    • Persistent Plausible Deniability using Whonix within TAILS:
  • Steps for all other routes:
    • Get a dedicated laptop for your sensitive activities:
    • Some laptop recommendations:
    • Bios/UEFI/Firmware Settings of your laptop:
    • Physically Tamper protect your laptop:
  • The Whonix route:
    • Picking your Host OS (the OS installed on your laptop):
    • Linux Host OS:
    • MacOS Host OS:
    • Windows Host OS:
    • Virtualbox on your Host OS:
    • Pick your connectivity method:
    • Get an anonymous VPN/Proxy:
    • Whonix:
    • Tor over VPN:
    • Whonix Virtual Machines:
    • Pick your guest workstation Virtual Machine:
    • Linux Virtual Machine (Whonix or Linux):
    • Windows 10 Virtual Machine:
    • Android Virtual Machine:
    • MacOS Virtual Machine:
    • KeepassXC:
    • VPN client installation (cash/Monero paid):
    • (Optional) allowing only the VMs to access the internet while cutting off the Host OS to prevent any leak:
    • Final step:
  • The Qubes Route:
    • Pick your connectivity method:
    • Get an anonymous VPN/Proxy:
    • Installation:
    • Lid Closure Behavior:
    • Connect to a Public Wi-Fi:
    • Update Qubes OS:
    • Hardening Qubes OS:
    • Setup the VPN ProxyVM:
    • Setup a safe Browser within Qube OS (optional but recommended):
    • Setup an Android VM:
    • KeePassXC:
• Creating your anonymous online identities:
  • Understanding the methods used to prevent anonymity and verify identity:
    • Captchas:
    • Phone verification:
    • E-Mail verification:
    • User details checking:
    • Proof of ID verification:
    • IP Filters:
    • Browser and Device Fingerprinting:
    • Human interaction:
    • User Moderation:
    • Behavioral Analysis:
    • Financial transactions:
    • Sign-in with some platform:
    • Live Face recognition and biometrics (again):
    • Manual reviews:
  • Getting Online:
    • Creating new identities:
    • The Real-Name System:
    • About paid services:
    • Overview:
    • How to share files or chat anonymously:
    • Redacting Documents/Pictures/Videos/Audio safely:
    • Communicating sensitive information to various known organizations:
    • Maintenance tasks:
• Backing-up your work securely:
  • Offline Backups:
    • Selected Files Backups:
    • Full Disk/System Backups:
  • Online Backups:
    • Files:
    • Information:
  • Synchronizing your files between devices Online:
• Covering your tracks:
  • Understanding HDD vs SSD:
    • Wear-Leveling.
    • Trim Operations:
    • Garbage Collection:
    • Conclusion:
  • How to securely wipe your whole Laptop/Drives if you want to erase everything:
    • Linux (all versions including Qubes OS):
    • Windows:
    • MacOS:
  • How to securely delete specific files/folders/data on your HDD/SSD and Thumb drives:
    • Windows:
    • Linux (non Qubes OS):
    • Linux (Qubes OS):
    • MacOS:
  • Some additional measures against forensics:
    • Removing Metadata from Files/Documents/Pictures:
    • TAILS:
    • Whonix:
    • MacOS:
    • Linux (Qubes OS):
    • Linux (non-Qubes):
    • Windows:
  • Removing some traces of your identities on search engines and various platforms:
    • Google:
    • Bing:
    • DuckDuckGo:
    • Yandex:
    • Qwant:
    • Yahoo Search:
    • Baidu:
    • Wikipedia:
    • Archive.today:
    • Internet Archive:
• Some low-tech old-school tricks:
  • Hidden communications in plain sight:
  • How to spot if someone has been searching your stuff:
• Some last OPSEC thoughts:
• If you think you got burned:
  • If you have some time:
  • If you have no time:
• A small final editorial note

 

[HEISENBERG]

Pick your guest workstation Virtual Machine:​

Using Whonix/Linux will require more skills on your side as these are Linux distributions. You will also encounter more difficulties if you intend to use specific software that might be harder to use on Whonix/Linux. Setting up a VPN over Tor on Whonix will also be more complicated than on Windows as well.

If you can use Tor:​

You can decide if you prefer to conduct your sensitive activities from the Whonix Workstation provided in the previous section (highly recommended) or from a Custom VM that will use the Whonix Gateway like the Whonix Workstation (less secure but might be required depending on what you intend to do).

If you cannot use Tor:​

If you cannot use Tor, you can use a Custom VM of your choice that will ideally use an anonymous VPN, if possible, to then connect to the Tor network. Or you could go with the risky route: See Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option

 

[HEISENBERG]

Linux Virtual Machine (Whonix or Linux):​

Whonix Workstation (recommended and preferred):​

Skip this step if you cannot use Tor.


Just use the provided Whonix Workstation VM. It is the safest and most secure way to go in this route.


It is also the only VM that will provide Stream Isolation pre-configured for most apps by default.


If you want additional software on the Workstation (such as another Browser), follow their guide here https://www.whonix.org/wiki/Install_Software [Archive.org]


Consider running Whonix in Live Mode if for extra malware protection, See https://www.whonix.org/wiki/Anti-Forensics_Precautions [Archive.org]


Do not forget to apply the VM hardening recommendations here: Virtualbox Hardening recommendations.


Consider using AppArmor on your Whonix Workstations by following this guide: https://www.whonix.org/wiki/AppArmor [Archive.org]

Linux (any distro):​

Be careful, any customization you make to the non-Whonix guest VMs (keyboard layout, language, time zone, screen resolution or other) could be used to fingerprint your VMs later. See https://www.whonix.org/wiki/VM_Fingerprinting [Archive.org]

If you can use Tor (natively or over a VPN):​

Use the Linux Distro of your choice. Personally, I would recommend Ubuntu or Fedora for convenience but any other would work too. Be sure to not enable any telemetry.


Refer to this tutorial https://www.whonix.org/wiki/Other_Operating_Systems [Archive.org] for detailed instructions.


Consider hardening the VM as recommended in Hardening Linux.

If you cannot use Tor:​

Use the Linux Distro of your choice. Personally, I would recommend Ubuntu or Fedora for convenience but any other would work too. Be sure to not enable any telemetry. You could go with the risky route: See Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option

Choose a browser within the VM:​

This time, I will recommend Brave browser.


See why here: Appendix V: What browser to use in your Guest VM/Disposable VM


See Appendix V1: Hardening your Browsers as well.

Windows 10 Virtual Machine:​

Be careful, any customization you make to the non-Whonix guest VMs (keyboard layout, language, time zone, screen resolution or other) could be used to fingerprint your VMs later. See https://www.whonix.org/wiki/VM_Fingerprinting [Archive.org]

Windows 10 ISO download:​

Go with the Official Windows 10 Pro VM and harden it yourself: see Appendix C: Windows Installation Media Creation and go with the ISO route.


There is also another option you might hear about which is Windows AME (Ameliorated) from the https://ameliorated.info/ [Archive.org] project which is a special Windows 10 build stripped from all telemetry/advertising and update components. I do not recommend this option due to the insecure nature of that release lacking the latest updates/patches and lacking the ability to update completely. I do believe the project general idea is good but it is just too insecure/risky and also contains unnecessary software picked by the dev.

If you can use Tor (natively or over a VPN):​

Refer to this tutorial https://www.whonix.org/wiki/Other_Operating_Systems [Archive.org] for detailed instructions.

Install:​

• Shutdown the Whonix Gateway VM (this will prevent Windows from sending out telemetry and allow you to create a local account).
• Open Virtualbox
• Select Machine > New > Select Windows 10 64bit
• Allocate a minimum amount of 2048MB but ideally 4096MB if your Ram allows it
• Create a Virtual Disk using the VDI format and select Dynamically Allocated
• Keep the disk size at 50GB (this is a maximum; it should not reach that much)
• Select the VM and click Settings, Go into the Network Tab
• Select “Internal Network” in the “Attached to” Field and select Whonix.
• Go into the Storage Tab, Select the Empty CD and click the icon next to SATA Port 1
• Click on “Choose a disk file” and select the Windows ISO you previously downloaded
• Click ok and start the VM
• Virtualbox will prompt you to select a Starting disk (the ISO file), select it and click Start
• Follow the Steps in Appendix A: Windows Installation
• Start the Whonix Gateway VM

Network Settings:​

• Go back into Settings then Network & Internet
• Click Properties (Below Ethernet)
• Edit IP settings:
• Enable IPv4 and set the following:
  
  • IP address 10.152.152.50 (increase this IP by 1 for any other VM)
  • Subnet prefix length 18 (255.255.192.0)
  • Gateway 10.152.152.10 (this is the Whonix Gateway)
  • DNS 10.152.152.10 (this is again the Whonix Gateway)
  • Save
• Windows might prompt you if you want to be “discoverable” on this network. Click NO.

Every time you will power on this VM in the future, make sure you change its Ethernet Mac Address before each boot. You can do this in Virtualbox > Settings > Network > Advanced > Click the refresh button next to the MAC address. You can only do this while the VM is powered off.

If you cannot use Tor:​

See Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option

Install:​

• Open Virtualbox
• Select Machine > New > Select Windows 10 64bit
• Allocate a minimum amount of 2048MB but ideally 4096MB if your Ram allows it
• Create a Virtual Disk using the VDI format and select Dynamically Allocated
• Keep the disk size at 50GB (this is a maximum; it should not reach that much)
• Go into the Storage Tab, Select the Empty CD and click the icon next to SATA Port 1
• Click on “Choose a disk file” and select the Windows ISO you previously downloaded
• Click ok and start the VM
• Virtualbox will prompt you to select a Starting disk (the ISO file), select it and click Start
• Follow the Steps in Appendix A: Windows Installation

Network Settings:​

• Windows will prompt you if you want to be “discoverable” on this network. Click NO.

Every time you will power on this VM in the future, make sure you change its Ethernet Mac Address before each boot. You can do this in Virtualbox > Settings > Network > Advanced > Click the refresh button next to the MAC address. You can only do this while the VM is powered off.

Choose a browser within the VM:​

This time, I will recommend Brave browser.


See why here: Appendix V: What browser to use in your Guest VM/Disposable VM


See Appendix V1: Hardening your Browsers as well.

Additional Privacy settings in Windows 10:​

See Appendix B: Windows Additional Privacy Settings

Android Virtual Machine:​

Because sometimes you want to run mobile Apps anonymously too. You can also set-up an Android VM for this purpose. As in other cases, ideally this VM will also be sitting behind the Whonix Gateway for Tor network connectivity. But this can also be set-up as VPN over Tor over VPN

If you can use Tor (natively or over a VPN):​

Later in the VM settings during creation, go into Network and select Internal Network, Whonix.


Then on Android itself:

• Select Wi-Fi
• Select VirtWifi to connect
• Go into the advanced Wi-Fi properties
• Switch from DHCP to Static
  
  • IP address 10.152.152.50 (increase this IP by 1 for any other VM)
  • Subnet prefix length 18 (255.255.192.0)
  • Gateway 10.152.152.10 (this is the Whonix Gateway)
  • DNS 10.152.152.10 (this is again the Whonix Gateway)

If you cannot use Tor:​

Just use the tutorials as is and see Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option

Installation:​

Basically, follow the tutorial here: https://www.android-x86.org/documentation/virtualbox.html [Archive.org]

• Download the appropriate ISO file, personally, I recommend the CM 14.1 (based on old Android 7 “Nougat”) as it was the snappier in my tests.
• Create a New VM.
• Select Linux and Linux 2.6 / 3.x / 4.x 64 Bit.
• In System:
  
  • Allocate at least 2048MB (2GB) memory
  • Uncheck the Floppy drive
  • In the Processor Tab, select at least 1 or more CPUs
  • Enable PAE/NX
• In Display Settings, Change the adapter to VBoxVGA
• In Audio Settings, Change to Intel HD Audio
• Start the VM
• Select Advanced if you want persistence, Live if you want a disposable Boot (and skip the next steps).
• Select Auto Install on Selected Hard Disk
• Select Run Android
• Setup as you wish (disable all prompts for data collections). I recommend using the TaskBar Home.
• Go into Settings, Android-x86 Options and disable all collection.
• Connect to VirtWifi Wi-Fi Network (see the above section if you are behind Whonix and want to use Tor)

You are now done and can now install any Android app.

 

[HEISENBERG]

MacOS Virtual Machine:​

Yes, you can actually run MacOS within Virtualbox (on Windows/Linux/MacOS host systems) if you really want to use MacOS. You can run any version of MacOS you want.

If you can use Tor (natively or over a VPN):​

During the following tutorials, before starting the MacOS VM, make sure you do put the MacOS VMs on the Whonix Network.

• Select the VM and click Settings, Go into the Network Tab
• Select “Internal Network” in the “Attached to” Field and select Whonix

Afterward, and during the install, you will need to input an IP address manually to connect through the Whonix Gateway.


Use these settings when prompted in the MacOS installation process:

• IP address 10.152.152.50 (increase this IP by 1 for any other VM)
• Subnet prefix length 18 (255.255.192.0)
• Gateway 10.152.152.10 (this is the Whonix Gateway)
• DNS 10.152.152.10 (this is again the Whonix Gateway)

If you cannot use Tor:​

Just use the tutorials as is and see Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option

Installation:​

• Windows Host OS:
  
  • Virtualbox Catalina Tutorial: https://www.wikigain.com/install-macos-catalina-on-virtualbox-on-windows/ [Archive.org]
  • Virtualbox Big Sur Tutorial: https://www.wikigain.com/how-to-install-macos-big-sur-on-virtualbox-on-windows-pc/ [Archive.org]
• MacOS Host OS:
  
  • Just use the same tutorials as above but execute the various commands in terminal. It should work without issue.
• Linux Host OS:
  
  • Just use the same tutorials as above but execute the various commands in terminal. It should work without issue.

There are some drawbacks with running MacOS on Virtual Machines. The main one is that they do not actually have a serial number (0 by default) and you will be unable to log-in into any Apple provided service (iCloud, iMessage…) without a genuine ID. You can set such IDs using this script: https://github.com/myspaghetti/macos-virtualbox [Archive.org] but keep in mind randomly generated IDs will not work and using the ID of someone else will break their Terms of Services and could count as impersonation (and therefore could be illegal).


Note: I also ran in multiple issues with running these on AMD processors. This can be fixed so here is the configuration I used which worked fine with Catalina and Big Sur which will tell Virtualbox to emulate an Intel Processor instead:

• VBoxManage modifyvm "MacOSCatalina" ---cpuidset 00000001 000106e5 00100800 0098e3fd bfebfbff
• VBoxManage setextradata "MacOSCatalina" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "MacBookPro15,1"
• VBoxManage setextradata "MacOSCatalina" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-551B86E5744E2388"
• VBoxManage setextradata "MacOSCatalina" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"
• VBoxManage setextradata "MacOSCatalina" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1
• VBoxManage modifyvm "MacOSCatalina" --cpu-profile "Intel Core i7-6700K"
• VBoxManage setextradata "MacOSCatalina" VBoxInternal2/EfiGraphicsResolution 1920x1080

Hardening MacOS:​

Refer to Hardening MacOS.

Choose a browser within the VM:​

This time, I will recommend Brave browser.


See why here: Appendix V: What browser to use in your Guest VM/Disposable VM


See Appendix V1: Hardening your Browsers as well.

 

[HEISENBERG]

KeepassXC:​

You will need something to store your data (logins/passwords, identities and TOTP information).


For this purpose, I strongly recommend KeePassXC because of their integrated TOTP feature. This is the ability to create entries for 2FA316 authentication with the authenticator feature.


Remember this should ideally be installed on your Guest VM and not on your Host OS. You should never do any sensitive activities from your Host OS.


Here are the tutorials:

• Tails: KeePassXC is integrated by default
• Whonix: https://www.whonix.org/wiki/KeePassXC [Archive.org]
• Linux:
  
  • Download from https://keepassxc.org/download/ [Archive.org]
  • Follow the tutorial here https://keepassxc.org/docs/KeePassXC_GettingStarted.html#_linux [Archive.org]
• Windows:
  
  • Download from https://keepassxc.org/download/ [Archive.org]
  • Follow the tutorial here https://KeePassXC.org/docs/KeePassXC_GettingStarted.html#_microsoft_windows [Archive.org]
• MacOS:
  
  • Download from https://keepassxc.org/download/ [Archive.org]
  • Follow the tutorial here https://keepassxc.org/docs/KeePassXC_GettingStarted.html#_macos [Archive.org]

Test that KeePassXC is working before going to next step.

 

[HEISENBERG]

VPN client installation (cash/Monero paid):​

If you decided to not use a cash-paid VPN and just want to use Tor, skip this step.


If you cannot use a VPN at all in a hostile environment, skip this step.


Otherwise, see Appendix R: Installing a VPN on your VM or Host OS to install a VPN client on your client VM.


This should conclude the Route and you should now be ready.

About VPN Client Data Mining/Leaks:​

You might be asking yourself if those VPN clients are trustworthy not to leak any information about your local environment to the VPN provider when using them in the “VPN over Tor” context.


This is a valid concern but should be taken with a grain of salt.


Remember that all VPN activities are happening from a sandboxed VM on an internal network behind a Network Gateway (the Whonix Gateway). It does not matter much if the VPN client leaves some identifiers on your guest VM. The guest VM is still sandboxed and walled-off from the Host OS. The attack surface is pretty small IMHO especially when using the reputable and recommended VPN providers within the guides (iVPN, Mullvad, ProtonVPN and maybe Safing.io).


At best, the VPN client would know your local IP (internal IP) and some randomized identifies but should not be able to get anything from the Host OS. And in theory, the VPN client should not send any telemetry back to the VPN provider. If your VPN client does this or ask this. You should consider changing provider.

 

[HEISENBERG]

(Optional) Allowing only the VMs to access the internet while cutting off the Host OS to prevent any leak:​

This step will allow you to configure your Host OS so that only the Whonix Gateway VM will have access to the internet. This will therefore prevent any “leak” from your Host OS while letting the Whonix Gateway establish the tor connectivity. The other VMs (Whonix Workstation or any other VM you installed behind it will not be affected)


There are three ways to do this:

• The Lazy Way (not really recommended): not supported by Whonix and might have some security implication as you will expose the Whonix Gateway VM to the Public Wi-Fi network. I would advise against this unless you are in a hurry or very lazy.
  
  • This method will not work with Wi-Fi captive portals requiring any registration to connect.
• The Better Way (see further down): still not supported by Whonix but it will not expose the Whonix Gateway VM to the Public Wi-Fi network. This should keep things in check in terms of security.
• The Best Way: Using an external USB Wi-Fi dongle and just disabling Wi-Fi on the Host OS/Computer.

The Lazy Way (not supported by Whonix but it will work if you are in a hurry, see further for the better way):​

This way is not supported by the Whonix project but I will go ahead and give this option anyway. IMHO this is helpful to prevent your Host OS from leaking any information while you are using the Whonix VMs.


Note that this option as-is will only work on Wi-Fis without a captive portal (where you must enter some information to unlock access).


The illustration below shows the result of this step:

Configuration of the Whonix Gateway VM:​

For this to work we will need to change some configuration on the Whonix Gateway VM. Mainly we will need to add a DHCP client to the Whonix Gateway to receive IP addresses from the network. To do those change the Host OS will still have to have internet access allowed for now.


So here is how:

• Be sure to have your Host OS connected to a safe Wi-Fi.
• Through VirtualBox, start the Whonix Gateway VM
• Start a Terminal on the VM
• Install a DHCP client on the Whonix Gateway VM using the following command:
  
  • sudo apt install dhcpcd5
• Now edit the Whonix Gateway VM network configuration using the following command:
  
  • sudo nano /etc/network/interfaces.d/30_non-qubes-whonix
• Within the file change the following lines:
  
  • # auto eth0 to auto eth0
  • # iface eth0 inet dhcp to iface eth0 inet dhcp
  • iface eth0 inet static to # iface eth0 inet static
  • address 10.0.2.15 to # address 10.0.2.15
  • netmask 255.255.255.0 to # netmask 255.255.255.0
  • gateway 10.0.2.2 to # gateway 10.0.2.2
• Save (using Ctrl+X and confirm with Y) and power off the VM from the top left menu
• Go in to the VirtualBox Application and select the Whonix Gateway VM
• Click Settings
• Click the Network Tab
• For Adapter 1, change the “Attached To” value from “NAT” to “Bridged Adapter”
• As “Name”, select your Wi-Fi network Adapter
• Click OK and you are done with the VM configuration part

Configuration of the Host OS:​

Now we must block internet access from your Host OS while still allowing the VM to connect. This will be done by connecting to a Wi-Fi with the Host OS but without assigning itself an IP address. The VM will then use your Wi-fi association to get an IP address.

Windows Host OS:​

The goal here is to associate to a Wi-Fi network without having an internet connection. We will achieve this by deleting the Gateway from the connection after you are connected.

• First connect to the safe Wi-Fi of your choice
• Open an administrative command prompt (right click on Command Prompt and Run as Administrator)
• Run the following command: route delete 0.0.0.0 (this deletes the Gateway from your IP configuration)
• You are done, your Host OS will now be unable to access the internet while still connected to the Wi-Fi
  
  • Note that this will reset at each disconnect/reconnection to a network and you will have to delete the route again. This is not permanent.
• You can now start the Whonix Gateway VM which should now obtain an IP automatically from the Wi-Fi network and should provide Network to the other VMs behind (Whonix Workstation or other).
• And finally, after that you can start the Whonix Workstation VM (or any other VM you configured to work behind the Whonix Gateway VM) and it should be connected to the internet through Tor.

Linux Host OS:​

The goal here is to associate to a Wi-Fi network without having an internet connection. We will achieve this by deleting the Gateway from the connection after you are connected.

• First connect to the safe Wi-Fi of your choice
• Open a Terminal
• Run the following command: sudo ip route del default (this deletes the Gateway from your IP configuration)
• You are done, your Host OS will now be unable to access the internet while still connected to the Wi-Fi
  
  • Note that this will reset at each disconnect/reconnection to a network and you will have to delete the route again. This is not permanent.
• You can now start the Whonix Gateway VM which should now obtain an IP automatically from the Wi-Fi network and should provide Network to the other VMs behind (Whonix Workstation or other).
• And finally, after that you can start the Whonix Workstation VM (or any other VM you configured to work behind the Whonix Gateway VM) and it should be connected to the internet through Tor.

MacOS Host OS:​

The goal here is to associate to a Wi-Fi network without having an internet connection. We will achieve this by deleting the Gateway from the connection after you are connected.

• First connect to the safe Wi-Fi of your choice
• Open a Terminal
• Run the following command: sudo route delete default (this deletes the Gateway from your IP configuration)
• You are done, your Host OS will now be unable to access the internet while still connected to the Wi-Fi
  
  • Note that this will reset at each disconnect/reconnection to a network and you will have to delete the route again. This is not permanent.
• You can now start the Whonix Gateway VM which should now obtain an IP automatically from the Wi-Fi network and should provide Network to the other VMs behind (Whonix Workstation or other).
• And finally, after that you can start the Whonix Workstation VM (or any other VM you configured to work behind the Whonix Gateway VM) and it should be connected to the internet through Tor.

The Better Way (recommended):​

This way will not go against Whonix recommendations (as it will not expose the Whonix Gateway to the Host OS) and will have the advantage of allowing connections not only to open Wi-Fis but also to the ones with a Captive Portal where you need to enter some information to access the internet.


Yet this will still not be supported by the Whonix project but I think it is fine as the main concern for the previous Lazy Way is to have the Whonix Gateway VM exposed to the Host Network and it will not be the case here.


This option will require an additional VM between the Host OS and the Whonix Gateway to act as a Network Bridge.


For this purpose, I will recommend the use of a lightweight Linux Distro. Any will do but the easiest IMHO will be an Ubuntu based and I would recommend the lightweight XUbuntu as it will be extremely easy to configure this setup.


Why XUbuntu and not Ubuntu or KUbuntu? Because XUbuntu uses XFCE desktop environment which is lightweight and this VM will only serve as a proxy and nothing else.


Of course, you can also achieve this with any other Linux distro if you so decide you do not like XUbuntu.


This is how it will look at the end:

 

[HEISENBERG]

Installing XUbuntu VM:​

Make sure you are connected to a safe Wi-Fi for this operation.


First you will need to download the latest XUbuntu Stable release ISO from https://xubuntu.org/download/


When you are done with the download, it is time to create a new VM.

• Start VirtualBox Manager
• Create a new VM and name it as you want, for example “XUbuntu Bridge”
• Select type “Linux”
• Select Version “Ubuntu (64-bit)”
• Leave other options to default and click Create
• On the next screen, leave the default options and click Create
• Select the newly create VM and click Settings
• Select Network
• For Adapter 1, Switch to Bridged Mode and pick your Wi-Fi adapter in the Name
• Select Adapter 2 and enable it
• Attach it to “Internal Network” and name it “XUbuntu Bridge”
• Select Storage
• Select the Empty CD drive
• On the right side, Click the CD icon and select “Choose a disk file”
• Select the ISO of XUbuntu you previously downloaded and Click Ok
• Start the VM
• Select Start XUbuntu
• Select Install XUbuntu
• Pick your Keyboard Layout and click Continue
• Select Minimal Installation and Download Updates while install XUbuntu
• Select Erase Disk and install XUbuntu and click Install Now
• Select the Time Zone of your choice and click Continue
• Pick some random names unrelated to you (my favorite username is “NoSuchAccount”)
• Pick a password and require password to login
• Click Continue and wait for the install to finish and Restart
• When you are done rebooting, log-in
• Click the upper right connection icon (it looks like 2 rotating spheres)
• Click Edit Connections
• Select Wired Connection 2 (Adapter 2 previously configured in VirtualBox settings)
• Select the IPv4 Tab
• Change the Method to “Shared to other computers” and click Save
• You are now done setting up the XUbuntu Bridge VM

Configuring the Whonix Gateway VM:​

By default, the Whonix Gateway has no DHCP client and will require one to get an IP from a shared network you configured earlier.

• Through VirtualBox, start the Whonix Gateway VM
• Start a Terminal on the VM
• Install a DHCP client on the Whonix Gateway VM using the following command:
  
  • sudo apt install dhcpcd5
• Now edit the Whonix Gateway VM network configuration using the following command:
  
  • sudo nano /etc/network/interfaces.d/30_non-qubes-whonix
• Within the file change the following lines:
  
  • # auto eth0 to auto eth0
  • # iface eth0 inet dhcp to iface eth0 inet dhcp
  • iface eth0 inet static to # iface eth0 inet static
  • address 10.0.2.15 to # address 10.0.2.15
  • netmask 255.255.255.0 to # netmask 255.255.255.0
  • gateway 10.0.2.2 to # gateway 10.0.2.2
• Save (using Ctrl+X and confirm with Y) and power off the VM from the top left menu
• Go in to the VirtualBox Application and select the Whonix Gateway VM
• Click Settings
• Click the Network Tab
• For Adapter 1, change the “Attached To” value from “NAT” to “Internal Network”
• As “Name”, select the internal network “XUbuntu Bridge” you created earlier and click OK
• Reboot the Whonix Gateway VM
• From the upper left Menu, select System, Tor Control Panel, and check that you are connected (you should be)
• You are done configuring the Whonix Gateway VM

Configuration of the Host OS:​

Now we must block internet access from your Host OS while still allowing the XUbuntu Bridge VM to connect. This will be done by connecting to a Wi-Fi with the Host OS but without assigning itself a gateway address. The VM will then use your Wi-fi association to get an IP address.


If necessary, from the XUbuntu Bridge VM, you will be able to launch a Browser to enter information into any captive/registration portal on the Wi-Fi network.


Only the XUbuntu Bridge VM should be able to access the internet. The Host OS will be limited to local traffic only.

Windows Host OS:​

The goal here is to associate to a Wi-Fi network without having an internet connection. We will achieve this by deleting the Gateway from the connection after you are connected.

• First connect to the safe Wi-Fi of your choice
• Open an administrative command prompt (right click on Command Prompt and Run as Administrator)
• Run the following command: route delete 0.0.0.0 (this deletes the Gateway from your IP configuration)
• You are done, your Host OS will now be unable to access the internet while still connected to the Wi-Fi
  
  • Note that this will reset at each disconnect/reconnection to a network and you will have to delete the route again. This is not permanent.
• You can now start the XUbuntu Bridge VM which should now obtain an IP automatically from the Wi-Fi network and should provide Network to the other VMs behind (Whonix Workstation or other).
• If Necessary, you can use the XUbuntu Bridge VM Browser to fill in any information on any captive/registration portal to access the Wi-Fi.
• After that you can start the Whonix Gateway VM which should obtain the Internet Connection from the XUbuntu Bridge VM.
• And finally, after that you can start the Whonix Workstation VM (or any other VM you configured to work behind the Whonix Gateway VM) and it should be connected to the internet through Tor.

Linux Host OS:​

The goal here is to associate to a Wi-Fi network without having an internet connection. We will achieve this by deleting the Gateway from the connection after you are connected.

• First connect to the safe Wi-Fi of your choice
• Open a Terminal
• Run the following command: sudo ip route del default (this deletes the Gateway from your IP configuration)
• You are done, your Host OS will now be unable to access the internet while still connected to the Wi-Fi
  
  • Note that this will reset at each disconnect/reconnection to a network and you will have to delete the route again. This is not permanent.
• You can now start the XUbuntu Bridge VM which should now obtain an IP automatically from the Wi-Fi network and should provide Network to the other VMs behind (Whonix Workstation or other).
• If Necessary, you can use the XUbuntu Bridge VM Browser to fill in any information on any captive/registration portal to access the Wi-Fi.
• After that you can start the Whonix Gateway VM which should obtain the Internet Connection from the XUbuntu Bridge VM.
• And finally, after that you can start the Whonix Workstation VM (or any other VM you configured to work behind the Whonix Gateway VM) and it should be connected to the internet through Tor.

MacOS Host OS:​

The goal here is to associate to a Wi-Fi network without having an internet connection. We will achieve this by deleting the Gateway from the connection after you are connected.

• First connect to the safe Wi-Fi of your choice
• Open a Terminal
• Run the following command: sudo route delete default (this deletes the Gateway from your IP configuration)
• You are done, your Host OS will now be unable to access the internet while still connected to the Wi-Fi
  
  • Note that this will reset at each disconnect/reconnection to a network and you will have to delete the route again. This is not permanent.
• You can now start the XUbuntu Bridge VM which should now obtain an IP automatically from the Wi-Fi network and should provide Network to the other VMs behind (Whonix Workstation or other).
• If Necessary, you can use the XUbuntu Bridge VM Browser to fill in any information on any captive/registration portal to access the Wi-Fi.
• After that you can start the Whonix Gateway VM which should obtain the Internet Connection from the XUbuntu Bridge VM.
• And finally, after that you can start the Whonix Workstation VM (or any other VM you configured to work behind the Whonix Gateway VM) and it should be connected to the internet through Tor.

The best way:​

This way will not go against Whonix recommendations (as it will not expose the Whonix Gateway to the Host OS) and will have the advantage of allowing connections not only to open Wi-Fis but also to the ones with a Captive Portal where you need to enter some information to access the internet. Yet this will still not be supported by the Whonix project but I think it is fine as the main concern for the previous Lazy Way is to have the Whonix Gateway VM exposed to the Host Network and it will not be the case here. This option is the best because the network will be completely disabled on the Host OS from booting up.


This option will require an additional VM between the Host OS and the Whonix Gateway to act as a Network Bridge and to connect to the Wi-Fi network. This option requires a working USB Wi-Fi Dongle that will be passed-through to a bridge VM.


For this purpose, I will recommend the use of a lightweight Linux Distro. Any will do but the easiest IMHO will be an Ubuntu based and I would recommend the lightweight XUbuntu as it will be extremely easy to configure this setup.


Why XUbuntu and not Ubuntu or KUbuntu? Because XUbuntu uses XFCE desktop environment which is lightweight and this VM will only serve as a proxy and nothing else.


Of course, you can also achieve this with any other Linux distro if you so decide you do not like XUbuntu.


This is how it will look at the end:

Configuration of the Host OS:​

• Disable Networking on your Host OS completely (Turn off the on-board Wi-Fi completely)
• Plug-in and install your USB Wi-Fi Dongle. Connect it to a safe Public Wi-Fi. This should be easy and automatically installed by any recent OS (Windows 10, MacOS, Linux).

Configuring the Whonix Gateway VM:​

By default, the Whonix Gateway has no DHCP client and will require one to get an IP from a shared network you will configure later, on a Bridge VM.

• Through VirtualBox, start the Whonix Gateway VM
• Start a Terminal on the VM
• Install a DHCP client on the Whonix Gateway VM using the following command:
  
  • sudo apt install dhcpcd5
• Now edit the Whonix Gateway VM network configuration using the following command:
  
  • sudo nano /etc/network/interfaces.d/30_non-qubes-whonix
• Within the file change the following lines:
  
  • # auto eth0 to auto eth0
  • # iface eth0 inet dhcp to iface eth0 inet dhcp
  • iface eth0 inet static to # iface eth0 inet static
  • address 10.0.2.15 to # address 10.0.2.15
  • netmask 255.255.255.0 to # netmask 255.255.255.0
  • gateway 10.0.2.2 to # gateway 10.0.2.2
• Save (using Ctrl+X and confirm with Y) and power off the VM from the top left menu

Installing XUbuntu VM:​

Make sure you are connected to a safe Wi-Fi for this operation.


First you will need to download the latest XUbuntu Stable release ISO from https://xubuntu.org/download/


When you are done with the download, it is time to create a new VM.

• Disconnect your Host OS from the Wi-Fi you previously connected to with the dongle and forget the network.
• Start VirtualBox Manager
• Create a new VM and name it as you want, for example “XUbuntu Bridge”
• Select type “Linux”
• Select Version “Ubuntu (64-bit)”
• Leave other options to default and click Create
• On the next screen, leave the default options and click Create
• Select the newly create VM and click Settings
• Select Network
• For Adapter 1, Attach it to “Internal Network” and name it “XUbuntu Bridge”
• Select Storage
• Select the Empty CD drive
• On the right side, Click the CD icon and select “Choose a disk file”
• Select the ISO of XUbuntu you previously downloaded and Click Ok
• Select the USB Tab
• On the right side, click the USB icon with a + sign (the second from the top)
• Select the Wi-Fi Adapter Dongle from the list and make sure it is checked (leave the USB options to default)
• Start the VM
• Select Start XUbuntu
• Select Install XUbuntu
• Pick your Keyboard Layout and click Continue
• Select Minimal Installation and do not check the Download Updates during install option
• Select Erase Disk and install XUbuntu and click Install Now
• Select the Time Zone of your choice and click Continue
• Pick some random names unrelated to you (my favorite username is “NoSuchAccount”)
• Pick a password and require password to login
• Click Continue and wait for the install to finish and Restart
• When you are done rebooting, log-in
• Click the upper right connection icon (it looks like 2 rotating spheres)
• Click Edit Connections
• Select Wired Connection 1 (normally there should only be one)
• Select the IPv4 Tab
• Change the Method to “Shared to other computers” and click Save
• Again, click the upper right connection icon
• Connect to the safe Wi-Fi of your choice and if necessary, input the necessary information into a Captive Portal.
• You are now done setting up the XUbuntu Bridge VM

At this stage your Host OS should have no network at all and your XUbuntu VM should have a fully working Wi-Fi connection and this Wi-Fi connection will be shared to the Internal Network “XUbuntu Bridge”.

Additional configuration the Whonix Gateway VM:​

Now it is time to configure the Whonix Gateway VM to get access from the shared network from the bridge VM we just made on the previous step.

• Go in to the VirtualBox Application and select the Whonix Gateway VM
• Click Settings
• Click the Network Tab
• For Adapter 1, change the “Attached To” value from “NAT” to “Internal Network”
• As “Name”, select the internal network “XUbuntu Bridge” you created earlier and click OK
• Reboot the Whonix Gateway VM
• From the upper left Menu, select System, Tor Control Panel, and check that you are connected (you should be)
• You are done configuring the Whonix Gateway VM

At this stage, your Whonix Gateway VM should be getting the internet access from the XUbuntu Bridge VM which in turn is getting internet access from the Wi-Fi Dongle and sharing it. Your Host OS should have no network connectivity at all.


All the VMs behind the Whonix Gateway should now work fine without additional configuration.

Final step:​

Take a post-install VirtualBox snapshot of your VMs.


You are done and can now skip the rest to go to the Getting Online part.

 

[HEISENBERG]

The Qubes Route:​

As they say on their own website, Qubes OS is a reasonably secure, free, open-source and security-oriented operating system for single-user desktop computing. Qubes OS leverages and extensively uses Xen-based virtualization to allow for the creation and management of isolated compartments called qubes.


Qubes OS is not a Linux distribution but a Xen distribution. It is different from Linux distributions because it will make extensive use of Virtualization and Compartmentalization so that any app will run in a different VM (qube). As a bonus, Qubes OS integrates Whonix by default and allows for increased privacy and anonymity. It is highly recommended that you document yourself over Qubes OS principles prior to going this route. Here are some recommended resources:

• Qubes OS Introduction, https://www.qubes-os.org/intro/ [Archive.org]
• Qubes OS Video Tours, https://www.qubes-os.org/video-tours/ [Archive.org]
• Qubes OS Getting Started, https://www.qubes-os.org/doc/getting-started/ [Archive.org]
• YouTube, Life Behind the Tinfoil: A Look at Qubes and Copperhead - Konstantin Ryabitsev, The Linux Foundation
  [Invidious]
• YouTube, I used the reasonably-secure Qubes OS for 6 months and survived - Matty McFatty [@themattymcfatty]
  [Invidious]
• YouTube, Qubes OS: How it works, and a demo of this VM-centric OS
  [Invidious]

This OS is recommended by prominent figures such as Edward Snowden and Privacytools.io.


Qubes is the best option in this guide for people who are more comfortable with Linux and tech in general. But it has some downsides such as the lack of OS wide plausible deniability, its hardware requirements, and its hardware compatibility. While you can run this on 4GB of RAM as per their requirements, the recommended RAM is 16GB. I would advise against using Qubes OS if you have less than 8GB of RAM. If you want a comfortable experience, you should have 16GB, if you want a very good experience, you should have 24GB or 32GB.


The reason for this RAM requirement is that each app will run in a different VM and each of those VM will require and allocate a certain amount of memory that will not be available for other apps. If you are running native Windows apps within Qubes OS qubes, the ram overhead will be significant.


You should also check their hardware compatibility here https://www.qubes-os.org/hcl/ [Archive.org] before proceeding. Your mileage might vary and you might experience several issues with regards to hardware compatibility that you will have to troubleshoot and solve yourself.


I think that if you can afford it and are comfortable with the idea of using Linux, you should go with this route as it is probably the best one in terms of security and privacy. The only disadvantage of this route is that it does not provide a way to enable OS wide plausible deniability unlike the Whonix route.

 

[HEISENBERG]

Pick your connectivity method:​

There are 7 possibilities within this route:

• Recommended and preferred:
  
  • Use Tor alone (User > Tor > Internet)
  • Use VPN over Tor (User > Tor > VPN > Internet) in specific cases
• Possible if required by context:
  
  • Use VPN over Tor over VPN (User > VPN > Tor > VPN > Internet)
  • Use Tor over VPN (User > VPN > Tor > Internet)
• Not recommended and risky:
  
  • Use VPN alone (User > VPN > Internet)
  • Use VPN over VPN (User > VPN > VPN > Internet)
• Not recommended and highly risky (but possible)
  
  • No VPN and no Tor (User > Internet)

Tor only:​

This is the preferred and most recommended solution.

With this solution, all your network goes through Tor and it should be sufficient to guarantee your anonymity in most cases.


There is one main drawback tho: Some services block/ban Tor Exit nodes outright and will not allow account creations from those.


To mitigate this, you might have to consider the next option: VPN over Tor but consider some risks associated with it explained in the next section.

VPN/Proxy over Tor:​

This solution can bring some benefits in some specific cases vs using Tor only where accessing the destination service would be impossible from a Tor Exit node. This is because many services will just outright ban, hinder, or block Tor (see https://gitlab.torproject.org/legacy/trac/-/wikis/org/doc/ListOfServicesBlockingTor [Archive.org]).


As you can see in this illustration, if your cash (preferred)/Monero paid VPN/Proxy is compromised by an adversary (despite their privacy statement and no-logging policies), they will only find an anonymous cash/Monero paid VPN account connecting to their services from a Tor Exit node.

If an adversary somehow manages to compromise the Tor network too, they will only reveal the IP of a random public Wi-Fi that is not tied to your identity.


If an adversary somehow compromises your VM OS (with a malware or exploit for instance), they will be trapped within the internal Network of Whonix and should be unable to reveal the IP of the public Wi-Fi.


This solution however has one main drawback to consider: Interference with Tor Stream Isolation.


Stream isolation is a mitigation technique used to prevent some correlation attacks by having different Tor Circuits for each application. Here is an illustration to show what stream isolation is:

(Illustration from Marcelo Martins, https://stakey.club/en/decred-via-tor-network/ [Archive.org])


VPN/Proxy over Tor falls on the right-side meaning using a VPN/Proxy over Tor forces Tor to use one circuit for all activities instead of multiple circuits for each. This means that using a VPN/Proxy over Tor can somewhat reduce the effectiveness of Tor in some cases and should therefore be used only for some specific cases:

• When your destination service does not allow Tor Exit nodes.
• When you do not mind using a shared Tor circuit for various services. Like for instance for using various authenticated services.

You should however consider not using this method when your aim is just to browse random various unauthenticated websites as you will not benefit from Stream Isolation and this could make correlation attacks easier for an adversary between each of your sessions (see Your Anonymized Tor/VPN traffic).


More information at:

• https://www.whonix.org/wiki/Stream_Isolation [Archive.org]
• https://tails.boum.org/contribute/design/stream_isolation/ [Archive.org]
• https://www.whonix.org/wiki/Tunnels/Introduction#Comparison_Table [Archive.org]

Tor over VPN:​

You might be wondering: Well, what about using Tor over VPN instead of VPN over Tor? Well, I would not necessarily it:

• Disadvantages
  
  • Your VPN provider is just another ISP that will then know your origin IP and will be able to de-anonymize you if required. We do not trust them. I prefer a situation where your VPN provider does not know who you are. It does not add much in terms of anonymity.
  • This would result in you connecting to various services using the IP of a Tor Exit Node which are banned/flagged in many places. It does not help in terms of convenience.
• Advantages:
  
  • The main advantage really is that if you are in a hostile environment where Tor access is impossible/dangerous/suspicious but VPN is okay.
  • This method also does not break Tor Stream isolation.

Note, if you’re having issues accessing the Tor Network due to blocking/censorship, you could try using Tor Bridges (see Tor Documentation https://2019.www.torproject.org/docs/bridges [Archive.org] and Whonix Documentation https://www.whonix.org/wiki/Bridges [Archive.org]).


It is also possible to consider VPN over Tor over VPN (User > VPN > Tor > VPN > Internet) using two cash/Monero paid VPNs instead. This means that you will connect the Host OS to a first VPN from your Public Wi-Fi, then Whonix will connect to Tor and finally your VM will connect to a second VPN over Tor over VPN (see https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor [Archive.org]).


This will of course have a significant performance impact and might be quite slow but I think Tor is necessary somewhere for achieving reasonable anonymity.


Achieving this technically is easy within this route, you need two separate anonymous VPN accounts and must connect to the first VPN from the Host OS and follow the route.


Conclusion: Only do this if you think using Tor alone is risky/impossible but VPNs are okay. Or just because you can and so why not.

VPN only:​

This route will not be explained nor recommended.


If you can use VPNs then you should be able to add a Tor layer over it. And if you can use Tor, then you can add an anonymous VPN over Tor to get the preferred solution.


Just using a VPN or even a VPN over VPN makes no sense as those can be traced back to you over time. One of the VPN providers will know your real origin IP (even if it is in a safe public space) and even if you add one over it, the second one will still know you were using that other first VPN service. This will only slightly delay your de-anonymization. Yes, it is an added layer … but it is a persistent centralized added layer and you can be de-anonymized over time. This is just chaining 3 ISPs that are all subject to lawful requests.


For more info, please see the following references:

• https://www.whonix.org/wiki/Compari..._VPN_Services#Tor_and_VPN_Services_Comparison [Archive.org]
• https://www.whonix.org/wiki/Why_does_Whonix_use_Tor [Archive.org]
• https://www.researchgate.net/public...communication_VPN_and_Tor_a_comparative_study [Archive.org]
• https://gist.github.com/joepie91/5a9909939e6ce7d09e29#file-vpn-md [Archive.org]
• https://schub.wtf/blog/2019/04/08/very-precarious-narrative.html [Archive.org]

In the context of this guide, Tor is required somewhere to achieve reasonable and safe anonymity and you should use it if you can.

No VPN/Tor:​

If you cannot use VPN nor Tor where you are, you probably are in a very hostile environment where surveillance and control is very high.


Just do not, it is not worth it and too risky IMHO. You can be de-anonymized almost instantly by any motivated adversary that could get to your physical location in a matter of minutes.


Do not forget to check back on Adversaries (threats) and Appendix S: Check your network for surveillance/censorship using OONI.


If you have absolutely no other option and still want to do something, see Appendix P: Accessing the internet as safely as possible when Tor/VPN is not an option (at your own risk).

Conclusion:​

• If your intent is to create persistent shared and authenticated identities on various services where access from Tor is hard, I recommend the VPN over Tor option (or VPN over Tor over VPN if needed). It might be a little less secure against correlation attacks due to breaking Tor Stream isolation but provides much better convenience in accessing online resources than just using Tor. It is an “acceptable” trade-off IMHP if you are careful enough with your identity.
• If your intent however is just to browse random services anonymously without creating specific shared identities, using tor friendly services; or if you do not want to accept that trade-off in the previous option. Then I recommend using the Tor Only route to keep the full benefits of Stream Isolation (or Tor over VPN if you need to).
• If cost is an issue, I recommend the Tor Only option if possible.
• If both Tor and VPN access are impossible or dangerous then you have no choice but to rely on Public wi-fis safely. See Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option

For more information, you can also see the discussions here that could help decide yourself:

• Tor Project: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorPlusVPN [Archive.org]
• Tails Documentation:
  
  • https://gitlab.tails.boum.org/tails/blueprints/-/wikis/vpn_support/ [Archive.org]
  • https://tails.boum.org/support/faq/index.en.html#index20h2 [Archive.org]
• Whonix Documentation (in this order):
  
  • https://www.whonix.org/wiki/Tunnels/Introduction [Archive.org]
  • https://www.whonix.org/wiki/Tunnels/Connecting_to_Tor_before_a_VPN [Archive.org]
  • https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor [Archive.org]
• Some papers on the matter:
  
  • https://www.researchgate.net/public...communication_VPN_and_Tor_a_comparative_study [Archive.org]

 

[HEISENBERG]

Get an anonymous VPN/Proxy:​

Skip this step if you want to use Tor only or VPN is not an option.


See Appendix O: Get an anonymous VPN/Proxy

Installation:​

We will follow the instructions from their own guide https://www.qubes-os.org/doc/installation-guide/ [Archive.org]:


Secure Boot is not supported as per their FAQ: https://www.qubes-os.org/faq/#is-secure-boot-supported [Archive.org] so it should be disabled in the BIOS/UEFI settings.

• Download the latest Qubes OS installation ISO according to their hardware compatibility list.
• Prepare an USB key with the Qubes OS ISO file
• Install Qubes OS according to the installation guide:
  
  • If you want to use Tor or VPN over Tor: Check the “Enabling system and template updates over the Tor anonymity network using Whonix” during the last step. This will force all Qubes OS updates to go through Tor. While this will significantly reduce your update speed, it will increase your anonymity from the start. (If you are having issues connecting to Tor due to censorship or blocking, consider using Tor Bridges as recommended earlier. Just follow the tutorial provided here: https://www.whonix.org/wiki/Bridges [Archive.org])
  • If you want to use Tor over VPN or cannot use any of those, leave it unchecked.
• If you cannot use Tor at all, there is also no point in installing Whonix. So, you should disable Whonix installation within the Software Selection Menu.

Lid Closure Behavior:​

Unfortunately, Qubes OS does not support hibernation which is IMHO an issue regarding cold-boot attacks. To mitigate those, I highly recommend that you configure Qubes OS to shut down on any power action (power button, lid closure). You can do set this from the XFCE Power Manager. Do not use the sleep features.

Connect to a Public Wi-Fi:​

Remember this should be done from a safe place (see Find some safe places with decent public Wi-Fi and Appendix Q: Using long range Antenna to connect to Public Wi-Fis from a safe distance).

• In the upper right corner, Left click the network icon and note the Wi-Fi SSID you want to connect to
• Now right click the network icon and select Edit Connections
• Add one using the + sign
• Select Wi-Fi
• Enter the SSID of the desired network you noted before (if required)
• Select Cloned Mac Address
• Select Random to randomize your Mac Address
  
  • Warning: This setting should work in most cases but can be unreliable on some network adapters. Please refer to this documentation if you want to be sure: https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/anonymizing-your-mac-address.md [Archive.org]
• Save
• Now again Left click the connection account and connect to the desired Wi-Fi
• If this is an Open Wi-Fi requiring registration: You will have to start a browser to register
  
  • After you are connected, Start a Disposable Fedora Firefox Browser
  • Go into the upper left Menu
  • Select Disposable, Fedora, Firefox
  • Open Firefox and register (anonymously) into the Wi-Fi

Update Qubes OS:​

After you are connected to a Wi-Fi you need to update Qubes OS and Whonix. It is important that you keep Qubes OS always updated before conducting any sensitive activities. Especially your Browser VMs. Normally, Qubes OS will warn you about updates in the upper right corner with a gear icon. As this might take a while in this case due to using Tor, you can force the process by doing the following:

• Click the upper left Applications icon
• Select System Tools
• Select Qubes Update and Launch it
• Check the “Enable updates for qubes without known available updates”
• Select all the Qubes
• Click Next and update
• If you checked the Tor option during install, wait patiently as this might take a while over Tor

Hardening Qubes OS:​

Disclaimer: This section is under construction and will be worked on heavily in the next releases. This section is for more advanced users.

Application Sandboxing:​

While Qubes OS is already sandboxing everything by design, it is also useful to consider sandboxing apps themselves using AppArmor or SELinux.

AppArmor:​

“AppArmor is a Mandatory Access Control framework. When enabled, AppArmor confines programs according to a set of rules that specify what files a given program can access. This proactive approach helps protect the system against both known and unknown vulnerabilities” (Debian.org).


Basically, AppArmor is an application sandboxing system. By default, it is not enabled but supported by Qubes OS.

• About the Fedora VMs:
  
  • Fedora does not really use AppArmor but rather SELinux so see next section for that.
• About the Debian VMs:
  
  • Head out and read https://wiki.debian.org/AppArmor [Archive.org]
• About any other Linux VM:
  
  • Head out and read:
    
    • https://wiki.archlinux.org/title/AppArmor [Archive.org]
    • https://wiki.debian.org/AppArmor [Archive.org]
• About the Whonix VMs, you should consider enabling it and using it, especially on the Whonix VMs of Qubes OS:
  
  • First you should head out and read https://www.whonix.org/wiki/AppArmor [Archive.org]
  • Secondly you should head out again and read https://www.whonix.org/wiki/Qubes/AppArmor [Archive.org]

SELinux:​

SELinux is similar to AppArmor. The differences between SELinux and AppArmor are technical details we will not get into.


Here is a good explanation of what it is:

[Invidious]


In this guide and the context of Qubes OS, it is important to mention it as it is the recommended method by Fedora which is one of the default systems on Qubes OS.


So, head out and read https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/ [Archive.org]


You could make use of SELinux on your Fedora Templates. But this is up to you. Again, this is for advanced users.

 

[HEISENBERG]

Setup the VPN ProxyVM:​

Skip this step if you do not want to use a VPN and just use Tor only or if VPN is not an option either.


This tutorial should also work with any OpenVPN provider (Mullvad, IVPN, Safing.io or ProtonVPN for instance).


This is based on the tutorial provided by Qubes OS themselves (https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md [Archive.org]). If you are familiar with this process, you can follow their tutorial. Here is mine:

Create the ProxyVM:​

• Click the Applications icon (upper left corner)
• Click Create Qubes VM
• Name and label as you wish: I suggest “VPNGatewayVM”
• Select Type: Standalone Qube copied from a template
• Select Template: debian-10
• Select Networking:
  
  • Select sys-whonix if you want to do VPN over Tor / Tor only (recommended)
  • Select sys-firewall if you want to do Tor over VPN / No Tor or VPN / Just VPN
• Advanced: Check provides network
• Check “Start qube automatically on boot”
• Create the VM
• Test your Connectivity:
  
  • If you are going for VPN over Tor, Test the VM connectivity to Tor by launching a Browser within the ProxyVM and going to https://check.torproject.org [Archive.org] (It should say you are connected to Tor)
  • If you are going for Tor over VPN, Test the VM connectivity to the internet by launching a Browser within the ProxyVM and access any website.

Download the VPN configuration from your cash/Monero paid VPN provider:​

If you can use Tor:​

Using Tor browser (be careful not to use any Clearnet Browser for this), download the necessary OpenVPN configuration files for Linux from your VPN provider.


This can be done by using the Qubes OS integrated Tor Browser by accessing the Applications icon (upper left corner) and selecting the Disposable Tor Browser application.

If you cannot use Tor:​

Launch a browser from a DisposableVM and download the necessary OpenVPN configuration files for Linux from your VPN provider. See Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option.


When you are done downloading the configuration files within the Disposable Browser (usually a zip file), copy them to your ProxyVM VPN Gateway machine (using right click on the file and send to another AppVM).

Configure the ProxyVM:​

Skip this step if you are not going to use a VPN

• Click the upper left corner
• Select the VPN VM you just created
• Open the Files of the VPN VM
• Go into “Qubesincoming” > dispXXXX (This was your Disposable Browser VM)
• Double Click your downloaded zip file containing your OpenVPN configuration files to unzip it
• Now select the VPN VM again and start a terminal
• Install OpenVPN with the following command sudo apt-get install openvpn
• Copy all the OpenVPN configuration files provided by your VPN provider in /etc/openvpn/
• For all the OpenVPN configuration files (for each location):
  
  • Edit each file using sudo nano configfile (do not forget sudo to edit file within /etc)
  • Change the protocol from “udp” to “tcp” (Tor does not support UDP)
  • Change the port to a supported (by your VPN provider) TCP port (like 80 or 443)
  • Save and exit each file
• Edit the OpenVPN config file (/etc/default/openvpn) by typing sudo nano /etc/default/openvpn (because I do not like vi editor)
  
  • Change #AUTOSTART="all" to AUTOSTART="all" (in other words, remove the “#”)
  • Save and Exit
• Edit the Qubes firewall rules file (/rw/config/qubes-firewall-user-script) by typing “sudo nano /rw/config/qubes-firewall-user-script”
  
  • Add the following lines (without the quotes and remarks in parentheses)
    
    • virtualif=10.137.0.17

• vpndns1=10.8.0.1

• vpndns2=10.14.0.1

• iptables -F OUTPUT
• iptables -I FORWARD -o eth0 -j DROP
• iptables -I FORWARD -i eth0 -j DROP
• ip6tables -I FORWARD -o eth0 -j DROP
• ip6tables -I FORWARD -i eth0 -j DROP

• iptables -A OUTPUT -d 10.8.0.1 -j ACCEPT
• iptables -A OUTPUT -d 10.14.0.1 -j ACCEPT

• iptables -F PR-QBS -t nat
• iptables -A PR-QBS -t nat -d $virtualif -p udp --dport 53 -j DNAT --to $vpndns1
• iptables -A PR-QBS -t nat -d $virtualif -p tcp --dport 53 -j DNAT --to $vpndns1
• iptables -A PR-QBS -t nat -d $virtualif -p udp --dport 53 -j DNAT --to $vpndns2
• iptables -A PR-QBS -t nat -d $virtualif -p tcp --dport 53 -j DNAT --to $vpndns2

• Restart the ProxyVM by typing “sudo reboot”
• Test the ProxyVM VPN connectivity by starting a Browser within it and going to your VPN provider test page. It should now say you are connected to a VPN:
  
  • Mullvad: https://mullvad.net/en/check/ [Archive.org]
  • IVPN: https://www.ivpn.net/ [Archive.org] (check the top banner)
  • ProtonVPN: Follow their instructions here https://protonvpn.com/support/vpn-ip-change/ [Archive.org]

VPN over Tor:​

Setup a disposable Browser Qube for VPN over Tor use:​

• Within the Applications Menu (upper left corner), Select the Disposable Fedora VM
• Go into Qube Settings
• Click Clone qube and name it (like “VPNoverTor”)
• Again, within the Application Menu, Select the Clone you just created
• Go into Qube Settings
• Change the Networking to your ProxyVPN created earlier
• Click OK
• Start a Browser within the Whonix Workstation
• Check that you have VPN connectivity and it should work

You should now have a Disposable Browser VM that works with your cash/Monero paid VPN over Tor.

Tor Over VPN:​

Reconfigure your Whonix Gateway VM to use your ProxyVM as NetVM instead of sys-firewall.

• Within the Applications Menu (upper left corner), Select the sys-whonix VM.
• Go into Qube Settings
• Change the Networking NetVM to your ProxyVPN created earlier instead of sys-firewall
• Click OK
• Create a Whonix Workstation Disposable VM (follow this tutorial https://www.whonix.org/wiki/Qubes/DisposableVM [Archive.org])
• Launch a browser from the VM and Check that you have VPN connectivity and it should work.

Alternatively, you can also create any other type of disposable VM (but probably less secure than the Whonix one):

• Within the Applications Menu (upper left corner), Select the Disposable Fedora VM
• Go into Qube Settings
• Click Clone qube and name it (like “TorOverVPN”)
• Again, within the Application Menu, Select the Clone you just created
• Go into Qube Settings
• Change the Networking to your sys-whonix created earlier
• Click OK
• Start a Browser within the VM
• Check that you have VPN connectivity and it should work

You should now have a Disposable Browser VM that works with Tor over a cash/Monero paid VPN.

Any other combination? (VPN over Tor over VPN for instance)​

By now you should understand how easy it is to route traffic from one VM to the other with Qubes.


You can create several ProxyVMs for VPN accesses and keep the Whonix one for Tor. You just need to change the NetVM settings of the various VMs to change the layout.


You could have:

• One VPN ProxyVM for the base Qubes OS connection
• Use the sys-whonix VM (Whonix Gateway) getting its network from the first ProxyVM
• A second VPN ProxyVM getting network from sys-whonix
• Disposable VMs getting their NetVM from the second ProxyVM

This would result in User > VPN > Tor > VPN > Internet (VPN over Tor over VPN). Experiment for yourself. Qubes OS is great for these things.

 

[HEISENBERG]

Setup a safe Browser within Qubes OS (optional but recommended):​

Fedora Disposable VM:​

See: Appendix V: What browser to use in your Guest VM/Disposable VM


Within the Applications Menu (upper left), Select the Fedora-30 template

• Go into Qube Settings
• Clone the VM and name it “fedora-30-brave” (this VM template will have Brave)
• Again, go into the Applications Menu and select the clone you just created
• Go into Qube Settings
• Change its network to the ProxyVPN and Apply
• Launch a terminal from the VM

If you want to use Brave: apply the instructions from https://brave.com/linux/ [Archive.org] (Fedora 28+ section) and run the following commands:

• sudo dnf install dnf-plugins-core
• sudo dnf config-manager --add-repo https://brave-browser-rpm-release.s3.brave.com/x86_64/
• sudo rpm --import https://brave-browser-rpm-release.s3.brave.com/brave-core.asc
• sudo dnf install brave-browser

You should also consider hardening your browser: see Appendix V1: Hardening your Browsers.

Whonix Disposable VM:​

Edit the Whonix Disposable VM template and follow instructions here https://www.whonix.org/wiki/Install_Software [Archive.org]

 

[HEISENBERG]

Setup an Android VM:​

Because sometimes you want to run mobile Apps anonymously too. You can also set-up an Android VM for this purpose. As in other cases, ideally this VM will also be sitting behind the Whonix Gateway for Tor network connectivity. But this can also be set-up as VPN over Tor over VPN.


Since the x86 Android does not work “well” with Qubes OS. I will instead recommend using AnBox.io which works “well enough” with Qubes OS.

If you can use Tor (natively or over a VPN):​

Later in the Qubes settings during creation:

• Select Networking
• Change to sys-Whonix to put it behind the Whonix Gateway (over Tor).

If you cannot use Tor:​

Just use the tutorials as is. See Appendix P: Accessing the internet as safely as possible when Tor and VPNs are not an option.

Installation:​

Basically, follow the tutorial here:

• Click the Applications icon (upper left corner)
• Click Create Qubes VM
• Name and label as you wish: I suggest “Android Box”
• Select Type: Standalone Qube copied from a template
• Select Template: debian-10
• Select Networking:
  
  • Select sys-whonix if you want to do VPN over Tor / Tor only (recommended)
  • Select sys-firewall if you want to do Tor over VPN / No Tor or VPN / Just VPN
• Start the Qube and open a Terminal

Now you will have to follow the instructions from here: https://github.com/anbox/anbox-modules [Archive.org]

• Start by closing the AnBox Modules repository by running:
  
  • git clone https://github.com/anbox/anbox-modules.git
  • Go into the clone directory
  • Run ./INSTALL.sh (or follow the manual instructions on the tutorial)
• Reboot the machine
• Open a new terminal
• Install Snap by running:
  
  • sudo apt install snapd

Now we will follow their other tutorial from here: https://github.com/anbox/anbox/blob/master/docs/install.md [Archive.org]

• Install AnBox by running:
  
  • snap install --devmode --beta anbox
• To update AnBox later, run:
  
  • snap refresh --beta --devmode anbox
• Reboot the machine
• Open a terminal again and start the emulator by running:
  
  • anbox.appmgr

This should pop-up an Android interface. Sometimes it will crash and you might have to run it twice to make it work.


If you want to install apps on this emulator:

• Install ADB by running:
  
  • sudo apt install android-tools-adb
• First start Anbox (run anbox.appmgr)
• Grab the APK of any app you want to install
• Now install any APK by running:
  
  • adb install my-app.apk

That’s it, you should now have an Android Qube over Tor (or anything else) capable of running pretty much any App you can sideload with ADB. This is, for now and IMHO, the easiest way to get Android emulation on Qubes OS.

​

 

[HEISENBERG]

KeePassXC:​

You will need something to store your data (logins/passwords, identities and TOTP information).


For this purpose, I strongly recommend KeePassXC because of their integrated TOTP feature. This is the ability to create entries for 2FA authentication with the authenticator feature.


In the context of Qubes OS you should probably store your sensitive information within the Domain-vault qube.

• First click the Applications icon (upper left) and select the Domain: Vault qube.
• Click Qubes Settings
• Temporarily enable network by changing the network to your VPN ProxyVM you created earlier
• Open a terminal within the Domain: Vault qube
• Type: sudo dnf install keepassxc and wait for it to install
• Close the terminal and disable network by changing back the network to (none)
• Go back into the Domain: Vault Qube Settings and into the Applications tab
• Click Refresh
• Add KeePassXC to the Selected tab
• Launch KeePassXC within the Domain: Vault qube

You are done and can now skip the rest to go to the “Creating your anonymous online identities” part.

​

 

[HEISENBERG]

Creating your anonymous online identities:​

Understanding the methods used to prevent anonymity and verify identity:​

Captchas:​

(Illustration by xkcd.com, licensed under CC BY-NC 2.5)


Captcha stands for “Completely Automated Public Turing test to tell Computers and Humans Apart” are Turing tests puzzles you need to complete before accessing a form/website. You will mostly encounter those provided by Google (reCaptcha service) and Cloudflare (hCaptcha). hCaptcha is used on 15% of the internet by their own metrics.


They are designed to separate bots from humans but are also clearly used to deter anonymous and private users from accessing services.


If you frequently use VPNs or Tor, you will quickly encounter many captchas everywhere. Quite often when using Tor, even if you succeed in solving all the puzzles (sometimes dozens in a row), you will still be denied after solving the puzzles.


See https://gitlab.torproject.org/legacy/trac/-/wikis/org/doc/ListOfServicesBlockingTor [Archive.org]


While most people think those puzzles are only about solving a little puzzle, it is important to understand that it is much more complex and that modern Captchas uses advanced machine learning and risk analysis algorithms to check if you are human:

• They check your browser, cookies and browsing history using Browser fingerprinting.
• They track your cursor movements (speed, accuracy) and use algorithms to determine if it is “human/organic”.
• They track your behavior before/during/after the tests to ensure you are “human”.

It is also very likely that those platforms could already reliably identify you based on the unique way you interact with those puzzles. This could work despite obfuscation of your IP address / Browser and clearing all cookies.


You will often experience several in a row (sometimes endlessly) and sometimes very difficult ones involving reading undecipherable characters or identifying various objects on endless pictures sets. You will also have more captchas if you use an ad blocking system (uBlock for example) or if your account was flagged for any reason for using VPNs or Tor previously.


You will also have (in my experience) more Captchas (Google’s reCaptcha) if you do not use a Chromium based browser. But this can be mitigated by using Chromium based browsers such as Brave or Ungoogled-Chromium. There is also a Browser extension called Buster that could help you those https://github.com/dessant/buster [Archive.org].


As for Cloudflare (hCaptcha), you could also use their Accessibility solution here (https://www.hcaptcha.com/accessibility [Archive.org]) which would allow you to sign-up (with your anonymous identity created later) and set a cookie within your Browser that would allow you to bypass their captchas. Another solution to mitigate hCaptcha would be to use their own solution called “Privacy Pass” https://privacypass.github.io/ [Archive.org] in the form of a Browser extension you could install in your VM Browser.


You should therefore deal with those carefully and force yourself to alter the way you are solving them (speed/movement/accuracy/…) as to prevent “Captcha Fingerprinting”.


Fortunately, as far as I am aware, these are not yet officially/publicly used to de-anonymize users for third parties.

 

[HEISENBERG]

Phone verification:​

Phone verification is advertised by most platforms to verify you are human. But do not be fooled, the main reason for phone verification is not only to check if you are human but also to be able to de-anonymize you if needed.


Most platforms (including the privacy-oriented ones such as Signal/Telegram/ProtonMail will require a phone number to register and most countries now make it mandatory to submit a proof of ID to register336.

E-Mail verification:​

E-Mail verification is what used to be enough but is not anymore in most cases. What is important to know is that open e-mail providers (disposable e-mail providers for instance) are flagged as much as open proxies (like Tor).


Most platforms will not allow you to register using an “anonymous” or disposable e-mail. As they will not allow you to register using an IP address from the Tor network.


The key thing to this is that it is becoming increasingly difficult to sign-up for a free e-mail account anywhere without providing (you guessed it) … a mobile phone number. That same mobile phone number that can be used conveniently to track you down in most places.


If you want to avoid communicating your anonymous e-mail address to various parties. I would strongly suggest considering using e-mail aliasing services such as:

• https://anonaddy.com/
• https://simplelogin.io/

These services will allow to create random aliases for your anonymous e-mail (on ProtonMail or example) and could increase your general privacy if you do not want to disclose that e-mail for any purpose. They are both recommended by privacytools.Io


It is possible that those services (ProtonMail for instance) might require you to provide an e-mail address for registration. In that case, I would recommend you create an e-mail address from these providers:

• Disroot https://disroot.org
• RiseUp https://riseup.net [Tor Mirror]
• Autistici https://autistici.org

Keep in mind that those do not provide a zero-access design where only you can access your e-mail.

User details checking:​

Obviously, Reddit does not do this (yet) but Facebook most likely does and will look for “suspicious” things in your details (which could include face recognition).


Some examples:

• IP address from a country different than your profile country?
• Age in the profile not matching the picture age?
• Ethnicity in the profile not matching the picture ethnicity?
• Language not matching the country language?
• Unknown in anyone else contacts? (Meaning nobody else knows you?)
• Locking down privacy settings after signing-up?
• Name that does not match the correct ethnicity/language/country?

 

[HEISENBERG]

Proof of ID verification:​

The deal-breaker in most cases. As far as I know, only Facebook and LinkedIn (outside of financial services) have requested such verifications which involves sending pictures of some form of identification (passport, national ID card, driver license …). The only way to do this would involve creating fake official documents (forgery) using some decent Photoshop skills and this might be illegal in most places.


Therefore, this is a line I am not going to help you cross within this guide. Some services are offering such services online but I think they most likely are bad actors and are most likely overstepping their boundaries.


In many countries, only law enforcement, some very specific processes (such as GDPR request) and some well-regulated financial services are authorized to request a proof of identification. So, the legality of asking such documents is debatable and I think such platforms should not be allowed to require those.


In few countries (like Germany), this practice is illegal and online platforms such as Facebook or LinkedIn are legally bound to allow you use a pseudonym and remain anonymous.

 

[HEISENBERG]

IP Filters:​

As stated previously in this guide, many platforms will apply filters on the IPs of the users. Tor exit nodes are publicly listed and VPN exit servers are “well known”. There are many commercial and free services providing the ability to block those IPs with ease (hi Cloudflare).


Many platforms’ operators and administrators do not want traffic from these IPs as they often drive a lot of unlawful/malicious/unprofitable traffic to their platforms. Usually using the same excuses:

• Unlawful because “Think of the children” or “Terrorists”.
• Malicious because “Russian trolls”.
• Unprofitable because “Well it’s noise in the data we sell to advertisers” (AdSense, Facebook Ads …). Yet we still pay traffic for them so let us just deny them all instead.

Fortunately, those systems are not “perfect’ and you will (still) be able to get around those restrictions by switching identities (in the case of Tor) and looking trying to access the website each time until you find an Exit Node that is not blacklisted (yet).


Sometimes some platforms will allow you to log-in with a Tor IP but not sign-up (See https://gitlab.torproject.org/legacy/trac/-/wikis/org/doc/ListOfServicesBlockingTor [Archive.org]). Obviously, those platforms will keep a convenient permanent log of the IP you used during sign-up. And some will keep such logs indefinitely including all the IPs you used to logging in (hi Facebook).


The tolerance is much higher with VPNs as they are not considered “open proxies” but that will not stop many platforms from making them hard to use by forcing increasingly difficult captchas on most VPN users.


For this reason, this guide recommends the use of VPN over Tor (and not Tor over VPN).

​

 

[HEISENBERG]

Browser and Device Fingerprinting:​

Browser and Device Fingerprinting are usually integrated into the Captcha services but also in other various services.


Many platforms (like Google) will check your browser for various capabilities and settings and block Browsers they do not like. This is one of the reasons I recommend using Chromium based Browsers such as Brave Browser over Tor Browser within this VM.


Here are some of the things they check within recent browsers:

• User Agent: This is your Browser name and Version.
• HTTP_ACCEPT Headers: This is the type of content your Browser can handle.
• Time Zone and Time Zone Offset: Your time zone.
• Screen Size and Color Depth: The resolution of your screen.
• System Fonts: The typing fonts installed on your system.
• Cookies support: If your Browser supports cookies or not.
• Hash of Canvas fingerprint and Hash of WebGL fingerprint: These are generated unique IDs based on your graphic rendering capabilities.
• WebGL Vendor & Renderer: Name of your Video card
• Do-Not-Track enabled or not: Well yes, they can use your DNT information to track you
• Language: The language of your Browser
• Platform: The Operating System you are using
• Touch Support: If your system supports touch (such as a phone/tablet or touchscreen enabled laptop)
• Ad Blocking use: If your browser block ads
• AudioContext fingerprint: Like the Canvas and WebGL fingerprints these will fingerprint your audio capabilities.
• CPU: What kind of CPU you are using and how many of them
• Memory: How much memory you have in your System
• Browser Permissions: Is your browser allowing some things like geolocation or microphone/webcam access.
• …

Here are two services you can use to check your browser Fingerprinting:

• https://coveryourtracks.eff.org/
• https://amiunique.org
• https://browserleaks.com/

Chances are you will find your browser fingerprint unique no matter what you do.

​

 

[HEISENBERG]

Human interaction:​

Some platforms will add this as a bonus step and require you to have an actual human interaction with a customer care representative. Usually by e-mail but sometimes by chat/phone. They will want to verify that you exist by asking you to reply to an e-mail/chat/phone call.


It is annoying but very easy to deal with in our case. We are not making bots. This guide is for humans making human accounts.

User Moderation:​

Many platforms will delegate and rely on their own users to moderate the others and their content. These are the “report” features that you will find on most platforms.


Getting reported thousands of times does not matter when you are Donald Trump or Kim Kardashian but if you as a sole “friendless” anonymous user gets reported even once, you might get suspended/flagged/banned instantly.

Behavioral Analysis:​

See Your Digital Fingerprint, Footprint, and Online Behavior.