DEV Community: Orlian Prato

Advanced Privacy: A Practical Defense-in-Depth Guide

Orlian Prato — Wed, 07 Oct 2026 23:16:34 +0000

Privacy is not a product you install. It is a system of boundaries that prevents one disclosure from becoming a complete map of your life.

No setup makes you invisible. A realistic privacy program does four things:

reduces unnecessary collection;
makes separate activities harder to correlate;
limits the damage when a service or device is compromised; and
gives you a tested path to recover.

This guide is designed for ordinary people who want materially stronger privacy without turning daily life into a full-time security project. It also explains where common advice fails, especially around VPNs, SMS verification, virtual numbers, cloud backups, and identity compartmentalization.

Scope: This is educational guidance, not legal advice. Border searches, telecommunications rules, identity requirements, and data-retention laws vary by jurisdiction. If your safety, liberty, immigration status, employment, or source protection is at stake, consult qualified local counsel or a digital-security specialist.

Start with a threat model
The 60-minute privacy sprint
Build identity compartments
Use an email architecture
Separate payments and addresses
Stop using your personal number everywhere
Secure accounts and recovery
Reduce device attack surface
Protect communications
Understand browsers, VPNs, and Tor
Control the home network
Minimize files, cloud copies, and backups
Reduce public exposure
Plan for home, travel, and checkpoints
Prepare an incident-response sequence
Implement the system in phases

1. Start with a threat model

Buying privacy tools before defining the problem usually creates cost and complexity without meaningful protection. Start with one page and answer five questions.

What are you protecting?

List the assets that must remain confidential, available, or authentic: conversations, location history, contacts, identity documents, funds, unpublished work, health records, account access, or a protected source.

Who might want it?

Separate data brokers, scammers, abusive acquaintances, employers, platform operators, thieves, litigants, and state actors. They have different capabilities, incentives, and legal powers.

How could they get it?

Look for realistic paths: reused identifiers, cloud backups, an unlocked device, a malicious attachment, an exposed recovery channel, public records, location tracking, or another person's uploaded contact list.

What would the consequences be?

Rank outcomes by severity and reversibility. Spam is annoying. Losing the primary email account, financial access, or a confidential source can be catastrophic.

What can you sustain?

Record your budget, technical ability, accessibility needs, family constraints, work policies, and tolerance for inconvenience. A slightly weaker system you follow every day is safer than a theoretically perfect system you bypass under pressure.

For a useful starting framework, see EFF's threat-modeling glossary and security-planning worksheet.

2. The 60-minute privacy sprint

Start with the accounts and devices that can reset everything else. Do not migrate every service at once.

Minutes 0–15: update and lock

Enable automatic operating-system, browser, and app updates.
Use a long device passcode rather than a four-digit PIN or simple pattern.
Confirm that full-device encryption is enabled.
Hide message previews on the lock screen.

Minutes 15–30: secure the root

Change the primary email password to a unique, generated value.
Store it in a reputable password manager.
Review recovery addresses, phone numbers, active sessions, forwarding rules, and connected apps.
Remove stale devices and unknown sessions.

Minutes 30–45: upgrade authentication

Add passkeys or FIDO2/WebAuthn security keys where available.
Otherwise, use a time-based authenticator app.
Save recovery codes offline in two controlled locations.
Stop using SMS as the preferred factor for critical accounts.

NIST's current digital-identity guidance distinguishes among authentication factors and emphasizes phishing-resistant methods. See NIST SP 800-63-4.

Minutes 45–60: protect the carrier account

Add a unique carrier-account PIN.
Enable a port-out or number-transfer lock when offered.
Remove knowledge-based recovery questions when possible.
Save the carrier's verified recovery channel offline.

The FTC notes that SMS verification may not stop SIM-swap fraud and recommends stronger alternatives such as an authenticator app or security key. See its SIM-swap guidance.

Prioritize work in this order:

primary email and password manager;
financial, government, work-admin, and cloud accounts;
mobile carrier;
social and messaging accounts.

Important: Add and test replacement recovery methods before removing old ones. Locking yourself out is not a privacy win.

3. Build identity compartments

Using one email address, phone number, username, browser profile, postal address, and payment method allows companies and attackers to join records across your life. Compartmentalization limits that correlation.

A practical structure looks like this:

Root compartment: Password manager, recovery, and a small number of critical services. Never public.
Legal and critical compartment: Banking, tax, health, government, and employer systems. Use truthful identity where required.
Personal compartment: Trusted people and ordinary personal services. Do not publish its recovery identifiers.
Public or professional compartment: Website, clients, press, and public contact. Give it no authority to recover critical accounts.
Retail and low-trust compartment: Stores, apps, newsletters, trials, and marketplaces. Use aliases, a secondary number, an isolated browser profile, and bounded payment methods.

Apply the boundary to every signal, not just email:

Phone: Reserve the personal number for trusted contacts and unavoidable identity-bound services.
Browser: Use separate profiles for critical, work, personal, and pseudonymous activity.
Payment and shipping: Assume cards, addresses, receipts, and loyalty accounts can reconnect identities.
Behavior: Usernames, profile photos, writing style, schedules, contacts, and location can bridge otherwise separate accounts.

Keep an encrypted inventory of which alias, number, browser profile, and payment method belongs to each compartment. Do not casually log into a personal account from a pseudonymous profile. A VPN cannot undo identity signals you voluntarily provide.

4. Use an email architecture

An alias is a routing layer, not necessarily a separate inbox. A unique address for each service prevents one leaked login from becoming a universal lookup key and lets you disable a compromised address without replacing the mailbox underneath it.

A maintainable workflow

Protect the root mailbox. Use it only for the alias service, password manager, recovery, and a short list of critical relationships. Do not publish it.
Create one alias per account. Record the alias in the same password-manager entry as the login.
Test replies. Confirm that replying preserves the alias and does not expose the destination mailbox in the From field or signature.
Quarantine leaks. If spam or phishing reaches an alias, replace it at the affected service and disable the old one after testing the migration.

The root mailbox and alias provider remain trust points. If separation truly matters, use different alias accounts or root mailboxes for different compartments. A custom domain improves portability but creates a renewal and DNS-security obligation: losing control of the domain can affect every alias built on it.

Move accounts in this order: password manager, primary recovery accounts, financial services, work administration, then retail and newsletters. Test inbound mail and replies before removing an old address.

5. Separate payments and addresses

A pseudonym paired with a personal card, loyalty account, billing address, or home delivery is only surface-level privacy.

Payment choices

Merchant-specific virtual cards: Reduce merchant-side exposure and subscription abuse. The issuer, funding bank, and payment provider still know the payer.
Cash: Minimizes routine transaction records when used in person without a loyalty identifier. Cameras, location, and later account registration may reconnect the purchase.
Gift or prepaid instruments: May isolate low-risk purchases, but activation, reload, IP, phone, and identity rules vary.
Personal cards: Offer broad acceptance and dispute rights but create a durable link among legal identity, merchant, amount, time, and often address.

Use virtual cards for containment, not invisibility. A separate card per merchant can reduce breach impact, but it does not make the transaction anonymous. Never misstate regulated identity or attempt to bypass know-your-customer requirements.

Postal addresses are identifiers

A PO box or commercial mailbox can keep a home address off routine correspondence and public-facing materials, but the operator usually verifies the customer and retains records. Banks, governments, courts, insurers, licensing bodies, and some merchants may require a residential address.

Mail-forwarding providers also see metadata such as sender, recipient, timing, payment, and forwarding destination. Treat a mailbox as a privacy buffer against ordinary exposure, not a barrier against account compromise, coordinated data matching, or lawful demands.

6. Stop using your personal number everywhere

A phone number is often treated as a universal identifier: login name, recovery channel, marketing key, contact-discovery handle, and fraud signal. That makes a long-held personal number unusually valuable for correlation and account takeover.

Better rule: Keep your personal number for trusted people and unavoidable identity-bound relationships. Use purpose-specific numbers for public contact, marketplaces, dating, deliveries, trials, and lower-trust registrations when the service's rules and local law permit it.

Virtual numbers are privacy boundaries, not strong authenticators

A virtual number can prevent a merchant or stranger from learning your primary number, but it does not make you anonymous. The number provider may see account details, payment records, IP addresses, message contents, and usage metadata. Numbers can also be recycled, suspended, classified as VoIP, or rejected by the destination service.

Never use a temporary or disposable number as the only recovery method for an account you cannot afford to lose. Prefer passkeys, security keys, or authenticator apps for security. Use a phone number only when the service requires one.

VoIP and non-VoIP are not interchangeable

VoIP numbers route calls or texts primarily over internet infrastructure. Many services classify and restrict them.
Non-VoIP virtual numbers are generally sourced from mobile-carrier ranges and may look more like ordinary cellular lines to automated checks.
Secondary SIM or eSIM numbers usually provide the most durable compatibility, but the carrier may require identity registration and the line can still be SIM-swapped.
Temporary verification numbers are appropriate only for disposable, low-value registrations where reuse, loss, and lack of recovery are acceptable.

Acceptance changes constantly. A number that works today may fail later because of its carrier classification, recycling history, region, or abuse reputation.

Providers worth evaluating

The following are options to investigate, not guarantees of anonymity, acceptance, uptime, or long-term access:

MajorPhones: A reasonable first provider to evaluate when you need a low-cost US or UK virtual number for short-term or compartmentalized use. Its site advertises virtual-number and SMS-verification products. Treat all privacy claims as vendor claims until you have reviewed its current privacy policy, retention rules, account-deletion process, and payment trail.
TextVerified: Offers US verification and rental products. Distinguish private paid rentals from publicly visible free inboxes; never send sensitive codes to a public inbox.
SMSPool: Offers temporary verification numbers and country-specific options. Its own materials describe receiving codes through an online dashboard. Use only for low-stakes cases unless you have verified exclusivity, retention, and recovery.
Durable app-based numbers or a secondary SIM/eSIM: Usually better for ongoing public contact or accounts that need future recovery.

Before choosing any provider, answer these questions:

Is the number dedicated to you or shared?
Can previous or future customers receive messages sent to it?
How long are messages and logs retained?
Can staff or contractors read message content?
What identity and payment data does the provider collect?
Can you renew, port, or recover the number?
Does the destination service permit virtual numbers?
What happens if the provider closes your account?

Never use a public SMS inbox for a password reset, financial account, primary email, password manager, or any service containing sensitive personal data. Anyone who can read that inbox may be able to read the code.

SIM-registration laws matter

Many jurisdictions require government identification before activating a prepaid SIM. A secondary SIM can still reduce public exposure and cross-service reuse, but it may not hide your identity from the carrier or government. Follow local registration rules and never use another person's identity.

7. Secure accounts and recovery

Attackers rarely break modern cryptography. They phish users, reuse leaked passwords, abuse support processes, or take over recovery channels.

Preferred controls

Unique, generated passwords stored in a password manager.
Passkeys or FIDO2/WebAuthn hardware keys.
Two registered security keys stored separately.
A time-based authenticator app as a fallback.
Offline recovery codes with an account inventory.

Avoid relying on SMS codes, discoverable security questions, push prompts without number matching, or one device holding every credential and backup.

Protect the password manager

Use a long, unique master passphrase and strong MFA. Review emergency access, shared vaults, browser extensions, and active sessions.

A TOTP seed or enrollment QR code is the durable secret that generates future authenticator codes. Do not leave it in screenshots, chat, email, or an unencrypted note. If passwords and TOTP seeds are stored in one vault for convenience, recognize that compromise of the unlocked vault exposes both factors. Keep critical accounts in a separate security domain when practical.

Design recovery before you need it

List every recovery factor for each critical account.
Remove obsolete phone numbers, addresses, devices, app passwords, and third-party connections.
Test a recovery path without completing a destructive reset.
Keep verified support URLs and necessary account references offline.
Store recovery codes separately from passwords.

If a critical service insists on a number, use a renewable dedicated number only if the service supports it. Otherwise, use a separate carrier SIM or eSIM protected with an account PIN and port-out lock.

8. Reduce device attack surface

A current, supported device with strong defaults is usually safer than an exotic setup that misses updates or breaks essential workflows.

For every phone and computer:

use hardware that still receives security updates;
enable automatic updates and full-disk encryption;
install software only from verified sources;
use a long passcode and short auto-lock period;
remove unused apps, extensions, keyboards, profiles, and device-management enrollment;
grant camera, microphone, contacts, photos, location, Bluetooth, nearby-device, and accessibility permissions only when needed;
use a standard account for daily computer work and reserve administrator access for maintenance.

On iPhone and iPad, review cloud synchronization, enable Stolen Device Protection when available, and consider Lockdown Mode only if your threat model includes sophisticated targeted attacks. Apple describes it as an extreme protection that deliberately limits features.

On Android, choose a model with a long security-update commitment. A hardened operating system can be valuable for advanced users, but only if the hardware is supported, the installation source is official, and essential applications are tested first.

Use a default-deny mindset: install less, grant less, sync less, retain less.

9. Protect communications

End-to-end encryption protects message content between endpoints. It does not automatically hide participants, timestamps, IP addresses, notifications, screenshots, backups, or a compromised device.

For sensitive conversations:

use a maintained messenger with end-to-end encryption enabled by default;
use usernames and restrict phone-number visibility when supported;
verify safety numbers or equivalent identity keys through a separate channel for high-risk contacts;
review linked desktops and tablets;
remove stale devices;
use disappearing messages to reduce retention, not as proof that copies cannot exist.

Backups can change the encryption boundary. A conversation protected in transit may be copied into a device or cloud backup with different keys, retention rules, and recovery methods. Audit the messenger's current backup design, and remember that another participant can still take screenshots, export content, or leave notification previews enabled.

Use this channel hierarchy:

Sensitive conversation: End-to-end encrypted messenger or call.
Ordinary coordination: Any convenient channel, with minimum necessary detail.
Critical secret: In person or through a specialist-designed process.
SMS or carrier call: Logistics only; assume content and metadata may be exposed.

Encryption does not fix the wrong recipient. Confirm the destination before sending credentials, identity records, sensitive files, or locations.

10. Understand browsers, VPNs, and Tor

These tools solve different problems.

HTTPS encrypts traffic between the browser and the site. It does not prevent the site from tracking you.
A VPN hides destinations from the local network and changes the IP address visible to sites. It shifts trust to the VPN provider and does not erase logged-in identity, cookies, or fingerprinting.
Tor Browser provides stronger network anonymity and fingerprint resistance. It cannot protect you after you identify yourself or open a risky download outside the browser.
DNS filtering can block many tracker or malware domains. It does not stop first-party tracking or replace phishing judgment.

Everyday browsing

Use a current browser with tracker blocking and separate profiles. Keep extensions few because each adds code and fingerprinting surface. Block third-party cookies where compatible. Delete site data for services you no longer use.

For critical accounts, use saved bookmarks or manually verified addresses. Password-manager autofill can serve as a phishing warning when it refuses to fill on a lookalike domain.

When anonymity matters

Use the official Tor Browser without extra extensions or unusual customization. Do not log into personal accounts, reuse identifiers, or mix real-identity activity into the same research session. Do not open downloaded documents in external applications while connected; they may make network requests outside Tor.

Public Wi-Fi is not the central question. Modern HTTPS protects much content in transit, but captive portals, local sharing, malicious downloads, and account compromise still matter. Keep the firewall enabled, disable sharing, and prefer a trusted hotspot for critical work.

11. Control the home network

The router is the policy point for every device in the home, including appliances that cannot run privacy software.

Use a router you administer. If an ISP gateway is mandatory, ask whether bridge mode is supported and place your own router behind it. Then:

change administrator credentials;
disable remote administration and unused services;
enable reliable automatic firmware updates;
replace hardware that no longer receives security fixes;
separate trusted devices, guests, and Internet of Things devices;
use WPA2 or WPA3 with a strong unique passphrase;
disable WPS and unneeded Universal Plug and Play.

Network isolation limits lateral movement, not a device's access to its cloud service.

Router-level VPNs

A router VPN covers devices that cannot run a VPN app and reduces destination visibility for the ISP. It also concentrates trust in the VPN provider, places the household behind one exit identity, and can break services. Logged-in accounts, apps, cookies, and fingerprints still identify users.

After any router, DNS, or VPN change, test the public IP address, DNS path, IPv6 behavior, and each network segment. Document split-tunnel exceptions and failure behavior.

Do not make privacy controls invisible to housemates. Router changes affect everyone; explain filtering, logging, VPN exits, and possible outages first.

12. Minimize files, cloud copies, and backups

The safest sensitive file is the one you no longer retain. Encryption helps, but it cannot revoke a file already shared or viewed on a compromised device.

Classify data before storing it:

Public: Published work and public contact material. Prioritize integrity and availability.
Personal: Receipts and ordinary photos. Use encrypted storage and normal backups.
Sensitive: Identity copies, health data, location history, and source material. Limit access and retention.
Critical: Recovery keys and legal strategy. Consider offline or specialist-designed storage.

Use a 3-2-1 recovery design for irreplaceable data: three copies, two types of media, and one copy offline or in a separate security domain. Encrypt backups before they leave your control, keep recovery keys separately, and test restoration regularly.

Do not sync every folder by default. Exclude temporary downloads, exports, identity documents, and messenger media unless there is a specific need.

Before publishing a document or image, inspect and remove unnecessary location, author, device, and revision metadata. Disable macros in untrusted office files. Prefer access-controlled, expiring links over permanent attachments when recipients can use them safely.

Treat AI systems as external recipients. Do not paste sensitive personal, legal, medical, financial, employer, client, or source material into a model unless the product, account, retention settings, and purpose fit your threat model.

13. Reduce public exposure

Attackers build convincing stories from ordinary fragments: an employer, relatives, a birthday post, an old address, a pet name, a phone number, a reused profile image, or real-time travel plans.

Run a quarterly exposure review:

search your name, usernames, email aliases, and public phone numbers from a signed-out browser;
review profile visibility, tagged photos, followers, old posts, location history, and friend-list exposure;
remove birth dates, family relationships, home details, and travel schedules that do not need to be public;
revoke third-party app access;
export needed data, then delete abandoned accounts;
request removal from relevant data brokers and people-search sites;
keep a dated removal log because records can return;
inspect public records and domain registration for links among your legal name, home address, business, and contact details.

Before posting, inspect the background for reflections, badges, documents, vehicle plates, school or workplace details, and embedded location. Delay travel posts until you have left.

Treat unsolicited messages as untrusted even when the sender knows real facts about you. Verify the person or organization through an independently obtained channel, not a link or number supplied in the message.

Ask friends and family not to publish your number, address, live location, or travel plans. Agree on an anti-impersonation rule: pause, contact the person through an established channel, and never send money or codes because of urgency.

Privacy is collaborative. Your contacts may hold your number, address, messages, and photos. A shared rule that everyone can follow often protects more than another app.

14. Plan for home, travel, and checkpoints

Smart-home devices

Put smart TVs, speakers, cameras, appliances, and guests on a separate network from workstations and storage devices. Change default passwords, enable MFA, update firmware, disable unnecessary remote access, and replace unsupported products.

Prefer local recording and local control for cameras and sensors when practical. Cloud convenience creates another custodian of intimate data. Avoid cloud-connected cameras in highly private areas unless the benefit clearly outweighs the exposure.

Keep an inventory of every connected device, owner account, update status, and deletion procedure.

Travel with a reduced data set

Carry less data. A clean secondary device can be safer than a daily device containing years of material, although an unusual device may itself draw attention.

Before departure:

update devices and verify encrypted backups;
sign out of unnecessary accounts;
remove sensitive offline files only after confirming the backup and any legal retention duty;
disable automatic Wi-Fi and Bluetooth joining;
remove distinctive device names;
carry your own power adapter and cable;
print essential itinerary and contact information;
plan what to do if a device is searched, seized, lost, or taken out of sight.

Borders and coercive checkpoints

Face and fingerprint unlock are convenient, but in some legal and physical contexts they may be easier to compel or trigger than a memorized passcode.

Before entering a controlled area:

Minimize: Carry only the device and data you need.
Disable biometrics: Turn off face, fingerprint, and watch-based unlock. Use the platform's emergency lock gesture when appropriate.
Power off: A full restart generally requires the complete passcode before normal access resumes.
Use a strong passcode: Prefer a long alphanumeric code over a short PIN, while considering the consequences of compelled disclosure.
Separate travel access: Use printed tickets and emergency contacts so routine logistics do not require unlocking the device.
Plan the response: Know which sessions to revoke and whom to contact if a device leaves your control.

The legal position is not universal. Search authority, compelled biometrics, passcode demands, detention, seizure, and refusal consequences depend on the country, immigration status, location, and changing case law. Do not treat any blanket statement about passcode protection as universal legal advice.

EFF's material on privacy at the US border is a useful starting point, but obtain current advice for the specific crossing when consequences are serious.

Disabling biometrics does not prevent compelled passcode disclosure, forensic exploitation, or access to data already synchronized elsewhere. Do not obstruct officials or destroy evidence.

15. Prepare an incident-response sequence

Warning signs include unexpected loss of cellular service, password-reset notices, unknown login alerts, new forwarding rules, unexplained battery or data use, or contacts receiving messages you did not send.

If a critical account may be compromised

Move to a known-clean device and network.
Secure the root email and password manager.
Revoke sessions and inspect recovery factors, forwarding rules, and connected apps.
Secure financial and identity accounts through verified channels.
Preserve timestamps, alerts, message headers, screenshots, and support case references.
Notify affected people minimally: identify the compromised channel and explain how to verify future contact.

If your number may have been SIM-swapped

Contact the carrier immediately from another device using an independently verified channel.
Recover the line, replace the account PIN, and request a port-out lock.
Change the primary email password, then other accounts that used SMS recovery.
Review bank, card, crypto, social, and messaging activity.
Replace SMS-based MFA with passkeys, security keys, or an authenticator app.

If targeted spyware is plausible

Do not immediately factory-reset, wipe, or hand the device to an unvetted repair shop; doing so may destroy evidence. Isolate it from sensitive work, use another trusted device for help, and contact a recognized digital-security assistance organization or qualified incident responder.

Prepare a short offline response card containing verified carrier, bank, employer-security, legal-counsel, and trusted-contact channels. Do not include passwords or one-time codes.

16. Implement the system in phases

A privacy program succeeds when it is maintained, not when it is installed once.

Phase 1: today

Write a one-page threat model.
Update devices and enable automatic updates.
Secure the root email and password manager.
Add passkeys, security keys, or authenticator-based MFA.
Lock the carrier account and save recovery codes offline.

Phase 2: this week

Create email aliases and browser profiles by compartment.
Obtain a dedicated virtual number for public and low-trust use.
Move critical accounts away from SMS recovery.
Audit app permissions, linked devices, cloud sync, and social visibility.
Configure an end-to-end encrypted messenger with trusted contacts.

Phase 3: this month

Inventory accounts, devices, backups, smart-home products, and recovery paths.
Delete abandoned accounts and unnecessary retained data.
Create encrypted backups and complete a test restoration.
Research data-broker removals relevant to your country.
Prepare travel and incident-response checklists.

Phase 4: every quarter

Review the threat model, software support, active sessions, recovery factors, and public exposure.
Confirm virtual-number renewal and test incoming messages without making the number the sole recovery factor.
Replace compromised aliases rather than rotating healthy passwords on an arbitrary schedule.
Practice one recovery scenario with a trusted person.

A critical account is in good shape when it has a unique credential, strong non-SMS authentication, a tested recovery path, and no dependency on a broadly shared personal phone number.

Keep a private encrypted control sheet with the account purpose, alias, number class, MFA type, recovery location, last review date, and deletion status. Do not store passwords, security-key PINs, or raw recovery codes in that same sheet.

Final principles

If you remember only ten rules, use these:

Threat-model before buying tools.
Protect the root email and password manager first.
Prefer passkeys or hardware keys over SMS.
Give each service a unique email alias.
Do not use your personal phone number as a universal identifier.
Use virtual numbers for compartmentalization, not as proof of anonymity or as the sole recovery path.
Keep identity, browser, payment, address, and behavior boundaries consistent.
Reduce the data stored, synchronized, and carried.
Test backups and recovery before an emergency.
Review the system regularly because providers, laws, and platform controls change.

Privacy is not perfect secrecy. It is the disciplined reduction of unnecessary links, unnecessary copies, and unnecessary trust.

Sources and further reading

TurnTrout: Advanced Privacy — thematic starting point requested for the original rewrite.
EFF: Threat model
EFF: Security Planning (Threat Modeling)
NIST SP 800-63-4: Digital Identity Guidelines
FTC: SIM Swap Scams
Apple: About Lockdown Mode
EFF: Digital Privacy at the US Border
MajorPhones
TextVerified free-number information
SMSPool example product documentation

Basic Web Browser with Electron +APIS

Orlian Prato — Sun, 05 May 2024 22:33:19 +0000

Hi! I'm excited to share with you a little guide I put together some time ago with some basic tips on how to have a Chromium based browser that really covers our tracks when surfing the web.

Section 1: Basic Browser Setup

1. Setting Up the Environment
Before you begin coding, you need to have Node.js and npm (Node Package Manager) installed on your computer. These will allow you to manage dependencies and run Electron code. You can download Node.js and npm from their official page.

Once Node.js and npm are installed, you can install Electron globally on your system or specifically in your project using npm:

npm install electron -g  # Global installation
npm install electron     # Local installation in your project

2. Creating the Project
Create a new folder for your project and navigate to it in your console or terminal. Inside this folder, initialize a new npm project:

mkdir my-browser
cd my-browser
npm init -y  # Creates a new package.json with default settings

Then, install Electron as a project dependency:

npm install electron

3. Creating the Project
In your project, create the following files:

index.html
main.js

An example of index.html:

<!DOCTYPE html>
<html>
<head>
    <title>My Secure Browser</title>
</head>
<body>
    <h1>Welcome to Your Custom Browser</h1>
</body>
</html>

for main.js we can get:

const { app, BrowserWindow } = require('electron');

function createWindow() {
  // Create the browser window.
  let win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true
    }
  });

  // and load the index.html of the app.
  win.loadFile('index.html');
}

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.on('ready', createWindow);

4. Running Your Browser

To run your browser, you can add a script to your package.json file to make launching the application easier. Modify your package.json by adding a new script:

"scripts": {
  "start": "electron ."
}

Then, you can start your browser from the terminal:

npm start

This will open a desktop application window that displays the content of index.html, providing you with the basic structure of your custom browser.

This is the basic skeleton to start developing a custom browser with Electron. From here, we can begin to add more functionalities

## Section 2: Implementing Proxies

A proxy server acts as an intermediary between your browser and the internet. When you use a proxy, your internet traffic is routed through the proxy server before reaching its destination. This masks your actual IP address, making it harder for websites to track your location and identity.

Types of Proxies

HTTP Proxies: Handle only HTTP requests and are commonly used for web browsing.
HTTPS Proxies: Similar to HTTP proxies, but for encrypted HTTPS traffic.
SOCKS Proxies: More versatile and handle all types of traffic, not just web browsing. Useful for more generalized applications beyond just accessing web pages.

Setting Up Proxies in Electron
Electron's session module allows you to configure proxy settings programmatically. Here’s how you can implement it in your custom browser:

Define Proxy Configuration: First, you need to define the proxy settings. This can include HTTP, HTTPS, or SOCKS proxies. You can specify a proxy server for each type of traffic, or use a single proxy server for all types.
Apply Proxy Settings: Use the setProxy method of Electron's session object to apply these settings.

Detailed Code Implementation

You can configure your proxy settings directly in your main.js file. Here’s an example of how to set up a SOCKS5 proxy:

const { app, BrowserWindow, session } = require('electron');

function createWindow() {
  let win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true,
      session: session.fromPartition('persist:proxy')
    }
  });

  win.loadFile('index.html');

  // Set up proxy configuration
  const proxyRules = "socks5://localhost:1080";
  win.webContents.session.setProxy({ proxyRules }, function() {
    console.log("Proxy configuration is set.");
  });

  win.on('closed', () => {
    win = null;
  });
}

app.on('ready', createWindow);

Handling Proxy Configuration Dynamically

You might want to change proxy settings dynamically based on different criteria (e.g., user input, specific websites, etc.). You can achieve this by creating a function to update the proxy configuration:

function setProxyConfig(proxyRules) {
  session.defaultSession.setProxy({ proxyRules }, () => {
    console.log(`Proxy set to: ${proxyRules}`);
  });
}

You can call setProxyConfig with different settings based on your needs, such as switching between different proxies or turning the proxy off.

Residential Proxies

Residential proxies are IP addresses provided by Internet providers to individuals, and are used by proxy services to offer greater legitimacy and less likelihood of being blocked by websites compared to data center proxies. This is because they simulate the behavior of a real user rather than a server farm. Key benefits include the ability to overcome geo-restrictions and CAPTCHAs, greater privacy and anonymity, and a lower likelihood of being detected and blocked by websites.

Bright Data (formerly Luminati): One of the largest providers with a wide range of customization options and a large number of IPs available. However, their pricing and usage structure can be complex, especially for new users (Proxyway).
Smartproxy: Offers residential proxies with support for HTTP(S) and SOCKS5. It is known for its high success rate and 24/7 technical support. Smartproxy provides a balance between price and performance, making it accessible to less experienced users (Smartproxy).
SOAX: Stands out for its flexibility in IP rotation and geolocation options. It is an intermediate option in terms of cost, providing a good balance between functionality and price (Proxyway).
Webshare: New to the proxy industry, it offers competitive pricing and a self-service approach. Its proxies are suitable for users who need a cost-effective solution and are willing to work with more limited rotation and targeting options (Webshare).
ProxyFish: Offers several proxy options including residential, data center and ISP proxies. They stand out for their anonymity and variety of product offerings, adapting to both enterprise and individual needs (ProxyFish).

Note: You can check the quality of SOCKS5 or HTTPS proxy with companies like: https://ipinfo.io or whoer.net

## Section 3: Fingerprints

Browser fingerprinting is the process of collecting information about a user's browser at both the software and hardware levels. This includes details like browser settings, time zone, installed plugins, available fonts, and more. These data points can be combined to create a "digital fingerprint" that uniquely identifies a user.

Methods to Mitigate Fingerprinting

The goal here is to make your browser as indistinguishable as possible, thereby reducing the uniqueness of the digital fingerprint that can be collected. Here are several techniques you can implement in your Electron browser:

Randomize User-Agent Data: Regularly changing the user agent that your browser sends to websites can help decrease precise identification.
Disable or Limit Canvas API: The Canvas API is commonly used to generate a unique fingerprint based on how graphics are rendered on different devices. You can disable or alter this API to reduce tracking.
Control WebRTC Access: WebRTC can reveal your real IP address even when you are using a VPN or proxy. Controlling or disabling WebRTC is crucial for protecting that information.
Standardize Font and Plugin Information: Limiting or standardizing the responses your browser provides about installed fonts and plugins can also help combat fingerprinting.

Implementation in Electron

You can modify the user agent directly in your Electron code. Here is an example of how to do this in the main.js file:

const { app, BrowserWindow } = require('electron');

app.on('ready', () => {
  let mainWindow = new BrowserWindow({ width: 800, height: 600 });
  const session = mainWindow.webContents.session;

  session.webRequest.onBeforeSendHeaders((details, callback) => {
    details.requestHeaders['User-Agent'] = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3';
    callback({ cancel: false, requestHeaders: details.requestHeaders });
  });

  mainWindow.loadURL('https://example.com');
});

To disable WebRTC and prevent the leakage of your real IP address, you can add the following line to your web preferences configuration in BrowserWindow:

webPreferences: {
  enableWebRTC: false
}

To intervene in how the Canvas API is used, you can inject scripts that modify its behavior, such as randomizing the results of Canvas functions.

Section 4: Using Virtual Number APIs

Virtual number APIs allow you to programmatically access and manage virtual phone numbers. These numbers can receive SMS and calls like any regular number, but they are not tied to a physical SIM card or a specific device. They are often used to maintain privacy, manage multiple accounts, or test applications.

Why Use Virtual Numbers?

Privacy Protection: By using a virtual number, you can avoid giving out your personal phone number.
Account Verification: Many services require phone verification; virtual numbers can be used to meet this requirement without exposing your real number.
Global Reach: Virtual numbers can often be obtained in various country codes, helping to bypass regional restrictions.

Several APIs provide virtual number services (VOIP), such as Twilio, Nexmo (Vonage), and Plivo or Non-VoIP like Major Phones, Textverified or SMSPool. These services offer a range of capabilities, including SMS reception, voice calls, and more. For our implementation, we will consider a generic API setup that can be adapted based on the specific service you choose.

Implementation in Electron

You’ll need to use a package like axios or node-fetch for making HTTP requests to the virtual number API. Here’s a basic setup:

Depending on the service you integrate, the code may change. However in essence you will always need to do a fetch to acquire a virtual phone number, another fetch to request the text messages received to that number and depending on the case, report or cancel the virtual number.

Among the most popular services for these purposes are Major Phones, Textverified, SMSPool. Each one has its pros and cons, it is worth checking the documentation so that whatever the case may be you can apply it correctly.

DEV Community: Orlian Prato

Advanced Privacy: A Practical Defense-in-Depth Guide

Table of contents

1. Start with a threat model

What are you protecting?

Who might want it?

How could they get it?

What would the consequences be?

What can you sustain?

2. The 60-minute privacy sprint

Minutes 0–15: update and lock

Minutes 15–30: secure the root

Minutes 30–45: upgrade authentication

Minutes 45–60: protect the carrier account

3. Build identity compartments

4. Use an email architecture

A maintainable workflow

5. Separate payments and addresses

Payment choices

Postal addresses are identifiers

6. Stop using your personal number everywhere

Virtual numbers are privacy boundaries, not strong authenticators

VoIP and non-VoIP are not interchangeable

Providers worth evaluating

SIM-registration laws matter

7. Secure accounts and recovery

Preferred controls

Protect the password manager

Design recovery before you need it

8. Reduce device attack surface

9. Protect communications

10. Understand browsers, VPNs, and Tor

Everyday browsing

When anonymity matters

11. Control the home network

Router-level VPNs

12. Minimize files, cloud copies, and backups

13. Reduce public exposure

14. Plan for home, travel, and checkpoints

Smart-home devices

Travel with a reduced data set

Borders and coercive checkpoints

15. Prepare an incident-response sequence

If a critical account may be compromised

If your number may have been SIM-swapped

If targeted spyware is plausible

16. Implement the system in phases

Phase 1: today

Phase 2: this week

Phase 3: this month

Phase 4: every quarter

Final principles

Sources and further reading

Basic Web Browser with Electron +APIS

Section 1: Basic Browser Setup

Section 4: Using Virtual Number APIs