Online Privacy and Security: Tracking, Leaks, Passwords and Phishing

Online privacy comes down to limiting what can be linked back to you: the trackers that join your visits into a profile, the IP address every server sees, the password reused across accounts and the phishing page that harvests it. Each exposure has a specific, cheap protection, and this guide explains how each works and which protections actually close it.

Privacy as linkability

The useful definition of online privacy is not secrecy but linkability. Every site you visit learns something: an IP address, a cookie, a fingerprint, an email address at sign-up. Individually, those facts are harmless. The harm comes when they can be joined, across sites and over time, into a single record that says this person, at this address, with these interests, reads these things and buys those. Advertising built the joining machinery; fraud, stalking and account takeover use it too. The protections in this guide all work by breaking a link: removing an identifier, making one unstable, or refusing to present it at all.

That framing also tells you what to expect from any single tool. A VPN breaks the IP link and nothing else. A tracker blocker breaks the cookie and pixel links but not the fingerprint. A password manager breaks the link between your accounts that a reused password creates. No one tool does everything, and the sections below take each link in turn.

Tracking: how visits become a profile

Tracking is the business of recognising the same browser across different sites. The guide to how online tracking works covers the full set of techniques and who buys the output; the main ones, in the order they were invented, are these.

Blocking requests

A content blocker compares every request the page makes against filter lists such as EasyList and EasyPrivacy and drops the ones that serve ads or trackers. It is the single most effective privacy measure a browser user can take, because most tracking is a request to a known tracker domain, and the lists know those domains. The ad and tracker blocker guide explains filter lists, cosmetic filtering that hides the spaces ads leave, and the change Chrome's Manifest V3 forced: blockers can no longer inspect each request with their own code and must instead declare static rules with a capped count, which weakens some blockers on Chrome and is why uBlock Origin's full version no longer runs there. The guide is also honest about what a blocker cannot do: it cannot stop tracking done by the site's own server, and it cannot stop fingerprinting.

Making identifiers short-lived

Blocking works on known trackers. For everything else, the second measure is to stop identifiers from persisting: delete cookies and site data when the last tab for a site closes, except for the handful of sites you choose to stay logged in to. The Cookie AutoDelete approach, and Firefox's built-in option to clear on close with exceptions, break the long-lived first-party identifiers that server-side tracking depends on. The automatic cookie deletion guide explains the set-up, the exception list you will need, and its limit: a fingerprint does not live in a cookie and survives deletion, which is why the browser security hub treats fingerprinting as a separate problem with a separate answer.

Signals sites must honour

Two headers ask sites not to track. DNT: 1, Do Not Track, was proposed in 2009, never gained legal force, and was ignored so universally that the W3C abandoned it and browsers began removing the setting. Sec-GPC: 1, Global Privacy Control, is the same idea with a legal basis: under California's CPRA regulations and a growing list of other state laws, a business that receives it must treat it as a request to opt out of sale and sharing of personal data. A browser that sends it emits this with every request:

GET / HTTP/2
Host: example.com
Sec-GPC: 1

Firefox, Brave and DuckDuckGo's browser send GPC natively; Chrome and Edge need an extension. The GPC check and the DNT check in the browser scan tell you which you are sending. The DNT versus GPC guide explains why one signal failed and the other has teeth, which jurisdictions back it and how to check whether a specific site is listening.

Your network address

Every server you contact sees your IP address; there is no way to receive a response without providing a return address. What the address reveals is less than people fear and more than they would like: your internet provider, a rough location, usually to the city, sometimes only to the region, and whether you are on a residential, business, mobile or data-centre connection. It does not reveal your name or street, and geolocation databases are wrong often enough that nobody should be located by IP alone. The IP address guide explains what the address gives away, how it is combined with cookies and logins to become identifying, and why it is a stable identifier at home and a shared one on mobile networks.

Three tools change what the server sees, and they are not interchangeable. A proxy forwards your requests from its address; it usually does not encrypt, and only the application configured to use it is covered. A VPN encrypts all traffic between your device and the VPN provider's server, so the local network sees only an encrypted tunnel and sites see the provider's address; the provider itself sees everything. Tor routes through three volunteer relays with layered encryption, so no single party sees both who you are and where you are going, at a real cost in speed. The VPN versus proxy versus Tor guide compares them on encryption, who can see what, speed, and the leaks that undo them: DNS queries going outside the tunnel, IPv6 traffic bypassing an IPv4-only VPN, and WebRTC enumerating your real address from inside the browser, which the WebRTC leak check tests for. The position the guide takes is that a VPN is worth having on networks you do not control, is not an anonymity tool, and should be tested rather than trusted.

Passwords: the credential that leaks

Most account takeovers do not involve guessing. They involve a password that leaked from one service being tried on every other service, automatically, at scale, which is called credential stuffing and works because people reuse passwords. Everything about password advice follows from how passwords are stored and cracked. A well-run service stores a slow hash, such as Argon2id or bcrypt, and an attacker who steals the database must guess candidates and hash each one; a badly-run service stores a fast hash or plain text and the whole list is usable immediately. Against a slow hash, length is what defeats guessing, which is why NIST SP 800-63B recommends long passwords, screening against breached lists and no forced periodic changes, and drops the composition rules that produced Summer2024!.

The Password Strength & Breach Checker answers two questions without receiving the password. The breach check uses the k-anonymity model from Have I Been Pwned's Pwned Passwords service: your browser hashes the password with SHA-1 and sends only the first five hexadecimal characters of the hash; the server returns every known-breached hash suffix in that range, typically several hundred, and the comparison happens locally.

password:   correct horse battery staple
SHA-1:      BFD3617727EEA615E0B40A5E0C1D8B4F9B4AF8B9
sent:       GET /range/BFD36
compared:   17727EEA615E0B40A5E0C1D8B4F9B4AF8B9 against ~500 returned suffixes

A breached result means the exact password is in a public leak and should be considered known to every attacker; a weak or pattern result means a cracking rig would reach it quickly even if it has not leaked yet. The password security guide explains storage, cracking, why a passphrase beats a mangled word, and what a manager changes: with unique random passwords per site, a breach at one service compromises one account. The browser password manager guide in the browser cluster covers whether the manager built into your browser is enough.

Second factors: not all are equal

A second factor means a stolen password is not enough on its own, and it blocks the credential-stuffing attack outright. But the methods differ enormously in what else they survive.

The decisive column is the phishing one. A code typed into a fake login page is relayed to the real site within seconds by the attacker's proxy, and SMS and TOTP codes cannot tell the difference. A FIDO2 key or a passkey signs a challenge that includes the origin, so a credential registered for accounts.example.com simply will not answer accounts-example.com. The two-factor authentication guide ranks the methods, explains SIM swapping and push fatigue, and recommends passkeys or a hardware key for email and financial accounts, an authenticator app everywhere else, and SMS only where nothing else is offered, because SMS is still far better than nothing.

Phishing: where credentials are harvested

Phishing works because a page can look exactly like the real one and because the message arrives with a reason to hurry. Neither the look nor the urgency is evidence of anything. The evidence is the URL, and specifically the registrable domain, which is read from the right-hand end:

https://accounts.google.com.security-alert-verify.com/signin
        |__________________| |____________________|
          subdomain (anyone       registrable domain:
          can set this)           security-alert-verify.com

https://xn--pypal-4ve.com/        -> displays as paypaI.com or with an accented letter
https://bit.ly/3xYz9Q             -> destination unknown until followed
https://198.51.100.7/login        -> no domain at all

The Phishing URL Checker performs that reading and several more before you click: it isolates the registrable domain, checks it against known brands for lookalikes, decodes punycode, flags a brand name in the subdomain or path, follows the redirect chain through any shortener to the real destination, notes a recently registered domain, and reports whether the landing page presents a login form. The how to spot phishing guide teaches the same checks for when you do not have the tool open, and the pressure tactics in the message itself: a deadline, a threat, a reward, a request to keep it quiet. It takes the view that the best single habit is never to log in from a link in a message; open the site from a bookmark and look for the notification there. That habit defeats the entire category regardless of how good the fake is.

After a breach

Breach notifications are routine and the correct response is mostly about order. The data breach response guide lays out the first hour, day and week; the compressed version:

1. Change the password on the breached service, and on every other service where you used the same or a similar password. If you cannot list those, that is the reason to adopt a manager today.
2. Turn on a second factor on the accounts that matter most: email first, because email resets everything else; then banking, then anything holding a card.
3. Check what leaked. A password hash is different from a plain password, and a name and email are different from a card number or identity document. The notice usually says; the guide explains what each combination enables.
4. Expect follow-up phishing that references the breach. Attackers know you are anxious and know which service to imitate. Apply the URL rules above with extra suspicion for a month.
5. For financial or identity data, place a fraud alert or credit freeze where your jurisdiction offers one, and watch statements.

Data brokers: the profile you never agreed to

Everything above concerns data you gave, or your browser gave, to sites you visited. Data brokers assemble a different record from public registries, purchase histories, loyalty programmes, app location data and the tracking already described, then sell it to marketers, background-check services and anyone who pays. In the European Union and the United Kingdom, the GDPR gives you a right to access and erasure; in California and a growing number of US states, you have a right to opt out and, increasingly, a single deletion request mechanism. Elsewhere it is broker by broker. The data broker removal guide lists where the data comes from, the rights you have by region, and a removal process that is realistic about the fact that profiles get rebuilt and that removal is maintenance, not a one-off.

A realistic order of operations

Privacy advice fails when it is presented as a list of forty equal items. These are the changes ranked by exposure removed per minute spent, and most people can do the first five in an evening.

1. Install a password manager and let it generate a unique password for each site as you log in over the next month. Run the breach check on the handful of passwords you reuse most and retire them first.
2. Add a passkey or hardware key to your email account, and an authenticator app to every account that offers one.
3. Install a reputable content blocker with the default privacy lists, and block third-party cookies in the browser.
4. Send Global Privacy Control, natively or with an extension.
5. Adopt the rule: never log in from a link in a message. Bookmark the sites that matter.
6. Set cookies to clear on close with exceptions for the sites you live in.
7. Use a VPN on networks you do not control, and test it for WebRTC and DNS leaks after setting it up.
8. Send opt-out requests to the major data brokers and put a reminder to repeat it in a year.

None of this makes you invisible, and invisibility is the wrong goal. The goal is to stop being the easiest target in whatever list you are on, and to make the profile that exists about you incomplete, stale and hard to join to the real you. That is achievable, it is mostly free, and the tools to check your work are a click away.