Skip to main content

Make your next privacy change a useful one.

Start with a question about your own habits. Change one thing you can maintain, understand what it protects, and check the exceptions.

Take the personal privacy checklist →

Separate sync from website logins.

A browser account can sync history, passwords, tabs, or other data, depending on the service and your settings. Signing into a website is a different action. Turning off browser sync does not stop a website from recognizing the account you use there.

Open your browser’s account settings and review each synced category. For sensitive activity, consider an unsynced profile with clear account boundaries. If sync is useful to you, weigh that convenience against who can access the synced data and how it is encrypted.

Read the Chrome evaluation →

Make stored identifiers deliberate.

Review third-party cookie controls and the sites allowed to keep data. Automatic clearing can shorten the lifetime of identifiers, but can also sign you out or remove local preferences. Add exceptions only where you need them.

Containers isolate cookies and logins between contexts; they do not automatically erase the data inside each container or change your device’s fingerprint. Mozilla’s Multi-Account Containers documentation explains the boundary. Our fingerprinting overview explains recognition without cookies.

Give each context a purpose.

Start with two profiles: everyday activity and one activity you want to keep separate. Decide which accounts, extensions, and bookmarks belong in each. Avoid signing into the same identifying account across both when the goal is separation.

Profiles separate local browsing state, not necessarily your IP address, fingerprint, or identity. Containers provide a narrower boundary within a profile. Read Mozilla’s profile guidance, and review the extensions you carry into each context.

Know who resolves your lookups.

DNS translates a domain name into an address. DNS over HTTPS or TLS encrypts the path to the resolver; it does not hide the queries from that resolver. A VPN may carry DNS inside its tunnel, while a browser may have its own resolver and fallback rules.

Check the secure DNS setting in your browser or operating system. Review the resolver’s retention policy, then check what happens when the VPN disconnects. Mozilla documents Firefox’s DNS protection levels. Our VPN routing guide explains why coverage matters. Encrypted DNS alone does not conceal every destination from a network observer.

Protect the connection. Check the destination.

HTTPS encrypts content between your browser and the website even on public Wi-Fi. It does not tell you that the site itself is honest. Verify the hotspot name and important website addresses, disable automatic joining, and never bypass certificate warnings or install a certificate or device profile just because a portal asks.

A trusted VPN can reduce the hotspot operator’s visibility into covered traffic; a hotspot from your own phone is another option. Complete any necessary portal connection before relying on the VPN, then confirm the tunnel is connected. See the FTC’s public Wi-Fi guidance and what a VPN changes.

Keep support and permissions in the picture.

Check whether the phone still receives security updates. Review background location, contacts, microphone, camera, advertising settings, and apps you no longer use. On iOS, review tracking requests and iCloud settings; on Android, review Google account activity as well as app permissions.

A privacy-focused OS can reduce platform access, but removing Google services alone does not establish security. GrapheneOS documents its supported-device requirements and sandboxed Google Play model. Keep a supported device maintained before chasing a label. Accounts, carriers, and the apps you choose remain part of the privacy picture.

Plan the migration before moving the mailbox.

Review connected apps, recovery methods, forwarding rules, and old aliases first. If you want to limit provider access to stored mail, compare providers designed around encrypted storage. Start with a few important accounts, update recovery addresses, and keep the old mailbox available until dependencies are understood.

Encryption in transit is different from end-to-end encryption. Proton explains what it encrypts and what remains visible; ordinary external correspondence is not automatically end-to-end encrypted. Free mail is not proof that message contents fund advertising: Google announced the end of Gmail-content ad personalization in 2017. Evaluate current access, retention, and business practices instead.

Protect the accounts that recover everything else.

Give primary email a unique password in a trusted manager, or use a supported passkey. Add multifactor authentication where available. Work outward to banking, cloud storage, social accounts, and other important services. Keep recovery codes somewhere you can reach if your usual device is lost.

Passkeys and security keys can resist phishing; authenticator codes add protection but can still be phished. SMS is weaker than these options, but better than no second factor. CISA’s MFA guidance provides a starting point. Do not remove a working recovery method until its replacement is ready.

Check the conversation, not just the app.

Use end-to-end encryption for important conversations and review linked devices, backups, and contact verification. Signal is designed around private messaging. WhatsApp and Messenger support end-to-end encrypted personal conversations, but provider metadata, backups, and nonstandard chat types still deserve review. Meta documents Messenger’s encryption rollout.

Telegram’s ordinary cloud chats are not end-to-end encrypted; its technical FAQ distinguishes them from Secret Chats. SMS gives the carrier access to message contents. When another app falls back to SMS, its normal encryption may no longer apply.