How to improve browser security and privacy in Chrome and other browsers

Browsers are one of the main ways people access email, cloud platforms, banking, online documents, support portals, and day to day websites. Because of that, browser privacy and security are not only about blocking obvious threats. They also affect what websites can learn about the browser, what permissions a site receives, what downloads are allowed, and how much information may be exposed during normal browsing.

This guide explains how browser protections work in Chrome and other browsers, what they help reduce, where their limits remain, and why browser fingerprinting, extension visibility, and device telemetry deserve more attention. It is designed as an explanatory guide first, with practical checks later in the page.

This matters because browsers often sit in the middle of a wider security chain involving DNS, online accounts, cloud services, downloaded content, and user decisions.

The sections below cover the main browser security and privacy topics discussed in this guide. Use the links to jump to the part most relevant to your question.

• How browsers expose information to websites
• What can go wrong even when the browser is updated
• Why browser extensions can affect both security and privacy
• A documented example of browser extension and device data collection
• How browser protections help
• What Secure DNS and DNS filtering do
• How Secure DNS, HTTPS and a VPN protect different parts of browsing
• What browser protections do not do
• Why session cookies matter after sign in
• Practical browser security and privacy checks
• Why this matters for real accounts and services
• Periodic review is still necessary
• FAQ
• Need help with something covered in this guide?
• Further Guidance and Support

When a browser opens a website, it does more than simply display a page. It exchanges technical information needed to render content, run scripts, store site data, handle language preferences, manage permissions, and connect to other services involved in the page. Some of that behaviour is normal and necessary. Without it, many websites would not function properly.

The important point is that privacy is not only about obvious tracking banners or visible cookies. A browser can reveal information through its settings, supported features, storage behaviour, screen related details, language choices, time zone, and installed components. Even when a browser is updated and working normally, websites can still observe parts of the environment they are interacting with.

Some of these signals exist for compatibility and performance reasons rather than tracking alone. The privacy concern begins when those signals are combined, stored, or used to make one browser more distinctive than another.

Keeping a browser updated is essential. Security updates correct vulnerabilities and software errors that have been identified and for which fixes are available. However, being fully updated does not mean that a browser contains no vulnerabilities or that every weakness already has an effective fix.

Browsers are complex applications. They process website code, scripts, media, downloads, extensions, stored sessions, permissions and connections to other services. A vulnerability may exist before it is publicly identified, a fix may still be under development, or an attacker may learn how to exploit a weakness before every affected device has been protected.

A useful way to think about this is:

Browser is fully updated
↓
Known fixes available to that browser have been applied
↓
Browser still processes complex websites, scripts and data
↓
Unknown or not yet fixed weaknesses may still exist
↓
Other security layers still matter

Updating therefore reduces risk, but it does not create a guarantee that the browser cannot be compromised.

There are also risks that do not require a browser vulnerability at all. An updated browser can still allow unnecessary permissions, carry too many extensions, expose a distinctive combination of browser signals, or permit more data collection than expected.

A browser may also open a convincing phishing page, unsafe download, fake support page or misleading sign in request while functioning exactly as designed. Unsafe pages can arrive through search results, advertisements, shared links, cloud platforms, document sharing services, hosted files or other apparently familiar services.

In those situations, nothing necessarily needs to be technically wrong with the browser. The risk may come from a page, prompt, download, permission request, login form or support instruction being trusted too quickly.

This is why browser security cannot be judged only by whether the browser is patched. Updates are an important layer, but browser settings, website behaviour, extensions, DNS protection, endpoint protection, identity controls and the security of the device underneath the browser all remain relevant.

Browser extensions are often discussed only as a security issue. That is still important. Unnecessary, poorly maintained, or untrusted extensions can widen attack surface, read page content, interact with websites, and introduce new weaknesses.

But extensions can also affect privacy in a different way. A large or unusual extension set can make a browser more distinctive. In practical terms, that means the browser may stand out more from other users. Even when an extension is not malicious, its presence may still contribute to how identifiable the browser becomes. That is one reason why a smaller, more deliberate extension set is usually better than treating the browser as a place to install every convenience tool available.

Extensions can also introduce trust questions around who maintains them, what permissions they request, how often they are updated, and whether they still need the access they were originally granted.

Extensions are not the only way broad browser or account access can be granted. Some modern incidents have involved trusted third party tools being given extensive permissions to read data, interact with accounts, or connect to cloud services more widely than expected. Once that access is approved, the problem is no longer limited to what the browser itself exposes. It can become an account, identity, or wider business risk, especially where browser sessions, stored credentials, or connected services are involved.

For that reason, extension safety is not only about whether an add on looks useful or popular. It is also about what permissions it requests, whether those permissions are proportionate to its purpose, and whether similar access could be avoided entirely by using the browser without unnecessary add ons. Periodic review remains important because extensions and connected tools can accumulate quietly over time.

A documented example from 2026 comes from a public report that raised concerns about claims that a LinkedIn related script checked for 6,236 Chrome extensions and gathered device related details such as CPU core count, available memory, screen resolution, time zone, language settings, battery status, and storage related information. The same report also says LinkedIn stated that such checks were used to detect scraping related extensions rather than to infer sensitive information.

This example is useful because it shows why browser privacy is broader than cookies alone. Extension visibility and device characteristics can contribute to a wider browser fingerprint, even where the underlying browser is operating normally and no obvious malware is present.

Modern browsers include controls that affect how websites connect, what content is allowed to run, what permissions a site receives, and whether suspicious behaviour is blocked or limited. These controls do not make browsing risk free, but they can reduce exposure and make some deceptive or unsafe behaviour less effective.

In practical terms, browser protections may include safe browsing or phishing protection, secure connection warnings, site permission controls, download scanning, password and passkey support, privacy settings, and update mechanisms. These are useful because they reduce unnecessary exposure during ordinary browsing, even though they do not solve every privacy or security problem on their own.

Built in browser protections still matter and should not be treated as minor settings. Features such as Safe Browsing, SmartScreen, download reputation checks, pop up controls, permission controls, and extension review tools can reduce exposure before a file is opened or a risky page is trusted. These protections do not make browsing risk free, but they add important friction at the point where unsafe pages, suspicious downloads, or misleading prompts try to move the user towards a bad decision.

When a browser needs to reach a website, one of the early stages is usually a DNS lookup. DNS answers the question “Where should I connect?” by resolving the requested domain name into information the device can use to reach the destination.

Secure DNS, using technologies such as DNS over HTTPS or DNS over TLS, can encrypt the DNS exchange between the device or browser and the DNS resolver. This helps reduce the ability of the local network path to inspect or interfere with an otherwise unencrypted DNS request.

A filtering DNS provider can apply an additional decision at that stage:

Browser needs to reach a website
↓
DNS asks: Where should I connect?
↓
Secure DNS protects the lookup on its way to the resolver
↓
DNS filtering policy checks the requested domain
↓
Blocked: connection does not continue normally
or
Allowed: DNS information is returned
↓
Browser continues towards the destination

This is only one part of the browsing connection. DNS filtering does not normally inspect all of the content subsequently exchanged with the website, and Secure DNS does not create an encrypted tunnel for the browser’s complete internet session.

Once the browser connects to an HTTPS website, HTTPS and TLS provide another separate layer concerned with protecting that subsequent connection and checking the identity presented by the service.

Secure DNS, HTTPS and a VPN all use encryption in different ways, but they should not be treated as three versions of the same security control.

A simplified normal HTTPS browsing path can be understood like this:

Browser
↓
DNS resolves the website name
↓
Browser reaches the destination
↓
HTTPS/TLS establishes the protected web connection
↓
Browser checks the identity presented by the website
↓
Encrypted website session

If Secure DNS is being used, the DNS lookup itself is also protected between the device or browser and the DNS resolver:

Browser → encrypted DNS → DNS resolver

The subsequent HTTPS connection remains separate:

Browser → HTTPS/TLS → website

A VPN works differently. It can create an encrypted tunnel between the device and a VPN endpoint and carry a broader range of network traffic through that tunnel:

Device → encrypted VPN tunnel → VPN endpoint → internet

HTTPS still matters inside that model. A VPN does not make website certificate checking, browser security or HTTPS unnecessary.

These controls therefore answer different questions:

Secure DNS: How is my DNS request protected while it reaches the resolver?

DNS filtering: Should this domain be resolved or blocked?

HTTPS/TLS: How is the connection to this website protected, and what identity is the server presenting?

VPN: Should broader network traffic travel through an encrypted tunnel to another network endpoint?

This is also why a consumer VPN should not automatically be described as a replacement for browser security, endpoint protection or DNS filtering. Each control protects a different part of the connection.

HTTPS also does not mean that the website itself is necessarily safe. A malicious organisation can operate its own domain and obtain a valid certificate for that domain. Certificate validation helps the browser establish the identity associated with the domain it reached; it does not guarantee that the content, company, download or request on that website is trustworthy.

Browser settings are useful on their own, but they become stronger when combined with a filtering DNS service. This is where services such as NextDNS, or a Cloudflare resolver specifically configured to provide security filtering, can add another layer.

A DNS filtering service can help block access to known malicious domains, phishing pages, deceptive advertising networks, trackers, or other unwanted destinations before the browser fully loads the content. That does not mean every harmful page will always be blocked, but it can reduce exposure earlier in the connection process.

This is a good example of layered security. The browser has its own protections. The DNS layer can add another filter. Account security measures such as strong passwords, multi factor authentication, and security keys still remain separate and important.

NextDNS can be useful because it allows a more tailored filtering policy than the default settings built into many browsers or networks. Even the free version can still provide meaningful extra filtering, especially for people who want more control over what is blocked and what is allowed.

In practice, a NextDNS profile can help improve protection by adding filters for malicious domains, phishing sites, trackers, and other selected categories. It can also create more consistent protection across different browsers and devices, because the filtering logic sits outside the browser itself.

The value is not limited to Google Chrome. A configured DNS filtering service can support Chrome, Edge, Firefox, and other browsers, helping to improve the overall browsing environment rather than relying on one browser’s built in choices alone.

Google Chrome is a common starting point because many people use it, but similar security and privacy settings also exist in Microsoft Edge, Mozilla Firefox, and other modern browsers. The names and layout may differ slightly, but the main ideas are usually very similar.

The same security principles can be applied across different browsers rather than assuming that effective browser security depends on one particular product. A person may prefer Edge at work, Firefox at home, or Chrome across several devices. The practical approach is to understand the types of controls that matter, then look for the equivalent settings in the browser being used.

Browser protections can reduce risk during everyday browsing, but they should not be treated as a guarantee that harmful activity cannot reach or affect the device.

On their own, browser protections do not:

• guarantee that every malicious or compromised website will be identified

• guarantee that an HTTPS website is trustworthy

• guarantee that a fully updated browser contains no unknown or not yet fixed vulnerabilities

• replace operating system and software updates

• replace antivirus, endpoint protection or an Endpoint Protection Platform

• replace DNS filtering or wider network controls

• replace strong account security, MFA, passkeys or security keys

• prevent every form of session theft if malware or another compromise reaches the device

• replace email security

• replace independent backup, recovery planning or business continuity arrangements

Browser vendors and security services continuously identify harmful pages and suspicious behaviour, but detection cannot be assumed to be immediate. A newly created malicious page, a legitimate site that has just been compromised, or a trusted platform being abused by an attacker may remain accessible for a period before reputation and filtering systems recognise the problem.

Secure DNS also has a specific boundary. It can protect the DNS lookup path, but it does not stop scripts from running once an allowed page has loaded in the browser. Similarly, HTTPS protects the connection to the domain reached, but does not prove that everything provided by that domain is safe or legitimate.

Browsers also increasingly sit inside the authentication chain through password managers, credential managers, passkeys, security keys and active session cookies. Strong browser protection can reduce exposure, but the account, device and session still need their own controls.

Browser security should therefore be understood as one part of a wider chain of prevention, detection, containment and recovery rather than as a complete security boundary on its own.

A browser does not only help a user reach the sign in page. It also holds the active session after the user has signed in.

That matters because attackers do not always need to steal the original password or passkey. If malware can steal a live session cookie or token from the browser, the attacker may try to reuse that session and access the account without repeating the original sign in process.

Google explains that session theft commonly occurs when a user downloads malware. Once active, the malware may extract existing session cookies from the browser or wait until the user signs in to new accounts, then send those tokens to an attacker. Google also notes that cookies can have extended lifetimes, which can allow attackers to access accounts without needing the user’s password.

This is why browser security is not only about blocking unsafe websites. It is also about protecting the browser profile, downloads, extensions, stored credentials, session data and the device underneath the browser.

Saved browser passwords are also part of device risk

Saved browser passwords should also be treated as part of device security, not only as a browser convenience feature. Recent public reporting raised concern that Microsoft Edge may load saved passwords into browser process memory in clear text when the browser starts.

This does not mean every Edge user has been compromised. An attacker would still need local access, malware, administrative access, or another way to read process memory. However, it does show why stored browser credentials should be reviewed carefully, especially on shared computers, remote desktop servers, VDI environments, business devices, or computers used by more than one person.

For important accounts, the safer approach is to use unique passwords, passkeys where available, multi factor authentication, careful device protection, and a deliberate decision about whether credentials should be stored in the browser at all.

Google’s Device Bound Session Credentials are an example of newer browser level protection. DBSC binds authentication sessions to a specific device so that stolen cookies expire quickly and become less useful away from that device. However, this depends on browser support and website adoption, so it should be treated as an important extra layer, not a complete replacement for device security, endpoint protection, updates and safe browsing habits.

In May 2026, Google announced that Device Bound Session Credentials had become generally available for Google Workspace users in Chrome on Windows and would be enabled by default. This is a useful practical example of browser security evolving beyond the original sign in process to protect the authenticated session after sign in. Product support and deployment behaviour can change over time, so the enduring principle is the mechanism itself: binding a session to hardware can make a stolen session cookie substantially less useful on another device.

This is useful because it confirms that session theft is not a minor or theoretical issue. Attackers may not need to defeat the original sign in method if they can steal a valid session cookie or token after the user has already signed in. DBSC helps reduce that risk by binding the browser session to the physical device where the session was created.

It should still be treated as one layer rather than a complete solution. DBSC depends on browser support, device support, hardware backed security and service adoption. It does not replace updates, endpoint protection, DNS filtering, extension review, safe browsing habits or careful handling of downloads and prompts.

Device Bound Session Credentials rely on secure key storage on the device. On Windows, this normally means a Trusted Platform Module, or TPM. On macOS, Google refers to the Secure Enclave.

This means the protection may not be available in the same way on every computer. Older Windows devices, especially machines that are not Windows 11 capable, may not have TPM 2.0, may have an older TPM, or may have TPM support disabled in firmware settings.

Where DBSC is supported, the browser can bind the session to the device so that stolen session cookies are much less useful on another machine. Where secure key storage is not available, DBSC may fall back to normal session behaviour unless the service or administrator enforces DBSC protected access.

For business environments, this makes hardware age and device compliance important. A modern browser alone is not enough. The device also needs suitable hardware security, current operating system support, and the relevant service must support or enforce DBSC.

For Google Workspace administrators, DBSC can also be monitored through audit and investigation logs. A successful DBSC key binding event indicates that the user’s session is protected. This makes DBSC not only a browser protection, but also a useful visibility point for IT support and security review.

A sensible review does not require changing every setting. The aim is to confirm that the main protections are active and that unnecessary permissions are limited.

A practical browser review should not only look at privacy settings in the abstract. It should also check what the browser is currently allowed to do, what sites have been granted permissions, which extensions are installed, whether unwanted notifications are enabled, and whether download or prompt behaviour still reflects how the browser is actually being used today.

Google Chrome

Notifications

Open Chrome
Go to:

chrome://settings/content/notifications

Review:

Allowed to send notifications

Remove anything you do not recognise or no longer need

Downloads

Go to:

chrome://settings/content/automaticDownloads

Set to:

“Don’t allow sites to download multiple files automatically”

Review any allowed sites and remove unnecessary ones

Quick alternative (per site)

Click the 🔒 icon in the address bar
Select Site settings
Check:

Notifications
Pop-ups and redirects
Downloads

Reset if unsure

Microsoft Edge

Notifications

Go to:

edge://settings/content/notifications

Review:

Allow

Remove unknown or unnecessary entries

Downloads

Go to:

edge://settings/content/automaticDownloads

Block multiple automatic downloads unless required

Site-specific check

Click the 🔒 icon
Open Permissions for this site
Review and reset as needed

Why this matters

These steps are important because many unsafe pages do not rely on malware alone. Instead, they rely on getting the user to approve something that allows ongoing behaviour, such as repeated pop-ups, redirects, or downloads.

Many important systems are now accessed through a browser, including Microsoft 365, Google Workspace, banking, business portals, support platforms, and document services. In practice, the browser often sits between the user and a wider chain involving DNS, websites, identity systems, downloads, and online accounts.

Improving browser settings and using a filtered DNS layer does not solve everything, but it can make common web based attacks, misleading prompts, unsafe permissions, and unnecessary exposure less likely during normal browsing. That is why browser privacy and browser security deserve to be reviewed together rather than treated as two separate topics.

The wider importance of browser security becomes clearer when browsers are viewed in their real role. They are often the route into email, banking, Microsoft 365, cloud platforms, business portals, support systems, and online documents. If a browser session is abused, if an unsafe permission is granted, or if a connected account is exposed, the effect may spread well beyond one page or one device. That is one reason why cyber risk is now increasingly understood as an operational and continuity issue rather than only a technical one. UK cyber resilience guidance makes the same broader point: disruption to digital operations is not simply an IT issue, but can become a business continuity issue.

This also helps explain why browser discipline matters even where nothing appears obviously wrong. A weak extension choice, an unsafe prompt approval, an unnecessary permission, or a careless download may interact with real accounts and services that people rely on every day. The browser is often the point where those risks meet the user.

Browser security should not be treated as a one time configuration exercise. Browser interfaces change, security features evolve, extensions change ownership or behaviour, websites introduce new capabilities, and new vulnerabilities continue to be identified.

The appropriate settings can also depend on whether the browser is used on a personal device, a business laptop, a shared computer or a centrally managed environment. Browser settings, extensions, permissions, saved credentials, active sessions and DNS choices should therefore be reviewed periodically.

Keeping software current remains essential, but review should not stop at prevention. Where browser based services are important to business operation, organisations should also consider what happens if an account, device or browser session is compromised or becomes unavailable.

That can include:

• knowing how important accounts can be recovered

• maintaining independent backups of important business information where appropriate

• protecting administrative and recovery accounts separately

• knowing how active sessions can be revoked

• having a process for isolating or rebuilding an affected device

• documenting important supplier and service access

• reviewing what happened after an incident and improving the controls that failed or were insufficient

This is the wider layered approach:

Prevent → Detect → Contain → Recover → Learn → Improve

Browser security is one part of that process. DNS filtering, identity protection, endpoint protection, email security, backups and business continuity remain separate but connected layers.

Sometimes they may be able to infer or detect parts of the extension environment, depending on browser behaviour, available resources, and how the website interacts with the browser. That is one reason extension review matters for privacy as well as security.

Browser fingerprinting is the practice of combining technical characteristics of a browser and device to make that browser more distinctive. It is different from a simple cookie because it relies on observable browser behaviour or configuration rather than only stored identifier data.

No. Cookies are small pieces of stored site data. Browser fingerprinting refers to identifying or distinguishing a browser by combining signals such as settings, supported features, display information, language, time zone, and other characteristics.

In this context, device telemetry means technical details a site may gather or infer about the environment it is running in, such as memory related information, display characteristics, time zone, or language settings. Not every such signal is malicious, but together they can contribute to a more distinctive browser profile.

Not completely. Privacy settings can reduce some forms of tracking and unnecessary site access, but they do not guarantee that a website cannot observe technical characteristics of the browser environment.

No. Secure DNS can help protect DNS lookups and improve privacy on that part of the connection path, but it does not stop site side scripts from running once the page loads in the browser.

No. HTTPS helps protect the connection between the browser and the website and includes checks around the identity presented for the domain being visited. It does not prove that the organisation operating the website is trustworthy or that the page, download or request is safe. A malicious or misleading domain can have a valid HTTPS certificate for its own domain.

Usually yes. A smaller extension set reduces attack surface and may also reduce how unusual the browser appears compared with a heavily customised setup.

Private browsing can reduce some local storage persistence and some routine browser residue, but it is not a complete privacy shield. It does not make the browser invisible to websites.

Yes. Updates are essential because they correct known security problems for which fixes are available, but an updated browser can still reveal technical information and configuration related signals during normal browsing. It may also contain vulnerabilities that have not yet been identified or for which an effective fix is not yet available. Being fully updated therefore reduces risk but does not make the browser invulnerable.

Browser hardening can reduce unnecessary exposure, improve resistance to common threats, and limit weak configurations. It does not replace software updates, endpoint protection, strong account security, filtered DNS, or careful user decisions. It is one layer in a broader security approach.

Yes. Browsers are part of layered security because they often sit between the user, the website, online accounts, cloud services, downloads, and browser based identity sessions. Browser settings, extension controls, Safe Browsing, Secure DNS, and sign in behaviour can all affect how much risk is reduced during normal use.

The following sources may be useful if you would like to explore the standards, terminology, and real world examples in more detail.

Google Online Security Blog: Protecting Cookies with Device Bound Session Credentials.

Chrome Developers: Device Bound Session Credentials.

Google Workspace Admin Help: Prevent cookie theft with session binding.

SecurityWeek: Google Rolls Out Cookie Theft Protections in Chrome.

A guide can explain the issue and outline useful checks, but some situations need the actual device, account, service, website, network or supplier arrangement to be reviewed. Evening Computing can help review what is happening and advise on suitable next steps before changes are made.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
16 August 2026