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 now 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 recent example of browser extension and device data collection
• How browser protections help
• What Secure DNS and DNS filtering do
• 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
• 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 the browser updated is still essential, but an updated browser is not private by default. A secure browser can still allow unnecessary permissions, carry too many extensions, expose a distinctive set of browser signals, or permit more data collection than the user realises.

This matters because browser privacy risk is often quieter than malware or obvious phishing. Nothing may appear broken. A site may simply learn more about the browser and device than the user expects. That can contribute to a more distinctive profile of the person visiting the site, especially when combined with account logins, cookies, or repeated visits.

This is why browser privacy cannot be judged only by whether the browser is fully patched.

An up-to-date browser is still only one part of the picture. Some unsafe pages can appear legitimate at first, including pages that arrive through normal search results, advertisements, or shared links. These pages may attempt to redirect the browser, trigger downloads, request permissions, or load harmful content as soon as they are opened. In other cases, the page may rely on prompts that look familiar, such as cookie notices, notification requests, or privacy related pop ups, in the hope that the user will click through without pausing to assess what is being asked.

Similar risks can also appear through fake support messages, sponsored results, forum posts, or AI generated answers that point the user towards a convincing page, download, phone number or account recovery instruction. In those cases, the browser may be working normally. The risk comes from the page, prompt, download, permission request, login form or support instruction being trusted too quickly.

A browser may also open a phishing page that arrived through a trusted looking platform. For example, a link may come from a cloud workflow tool, document sharing service, website builder, form platform or hosted PDF rather than from an obviously suspicious domain. The browser may be working normally, but the page may still be designed to collect credentials, MFA codes, business details, identification documents or screenshots.

This matters because modern browser risk does not always begin with an obvious exploit or visibly broken page. In many cases, the browser itself is working normally, but the page is designed to abuse trust, prompts, permissions, or user attention. That is one reason why browser security is not only about updates. It is also about how sites behave, what the browser is allowed to do, and how quickly unusual behaviour is recognised and stopped.

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 useful recent example 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.

The value of mentioning that report is not to turn this page into a reaction article. The value is that it gives a real example of why browser privacy should be treated as more than a cookie question. It shows how extension visibility and device characteristics can become part of a wider browser fingerprinting discussion.

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 opens a website, one of the early steps is resolving the site name into an address the device can use. Secure DNS helps protect that step by sending DNS lookups through an encrypted method rather than leaving them more exposed to interference or inspection on the local network path.

This does not replace every other security control, but it can improve privacy and help reduce certain risks around DNS requests. In practical terms, Secure DNS can be combined with a trusted DNS provider so that the browser is not only using encrypted lookups, but also benefiting from the provider’s filtering policies where those are available.

Secure DNS and DNS filtering can reduce exposure to some malicious destinations and improve privacy on the DNS lookup path, but they do not stop a website from running scripts in the browser once the page has loaded. That means they are valuable protections, but only for part of the browsing chain.

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 Cloudflare can add value.

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.

That point is important for the page. The value is not only in 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.

This matters because the guide should not imply that only one browser can be hardened properly. 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 exposure during everyday browsing, but they do not solve every security problem on their own. They should be understood as one layer within a wider security approach.

On their own, they do not:

• • guarantee that all malicious websites will be blocked
  • replace software updates
  • replace anti malware or endpoint protection
  • replace strong passwords or multi factor authentication
  • directly secure an account in the same way as identity controls
  • remove the need for periodic review

A more accurate way to describe the benefit is that these controls can reduce exposure to harmful websites, phishing pages, trackers, and other unwanted domains, which helps lower risk during normal browsing.

Browser protections do not necessarily prevent websites from attempting browser fingerprinting or observing technical characteristics of the browsing environment. Privacy settings can reduce some forms of tracking without making browser identification impossible. Secure DNS helps protect DNS lookups, but it does not stop site side scripts from running once the page loads in the browser.

Browser protections also have limits. A page appearing in search results is not a guarantee that it is safe, and a site that looks polished or professionally presented may still be unsafe. Search engines, browser vendors, and security services work continuously to detect harmful pages, but unsafe or compromised sites can still appear for a period of time before they are identified and removed. That is why browser protection should be understood as one layer in a wider chain rather than a complete answer on its own.

This also matters because browsers increasingly sit in the authentication chain through password managers, credential managers, passkeys, and security keys. Strong browsing protections reduce exposure, but they do not replace better sign in methods. Current NCSC guidance now recommends passkeys over passwords wherever they are available.

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.

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.

Google Workspace has also started moving Device Bound Session Credentials from beta into general availability. According to Google’s Workspace communication, from 25 May 2026 the previous beta DBSC setting is being removed and DBSC will be enabled by default for Google Workspace domains as part of its standard protection against session theft. At launch, this protection works with Chrome.

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. Recent UK resilience guidance makes the same point clearly: disruption to digital operations is not simply an IT issue, but 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.

This page should not be treated as a one time permanent checklist. Browser interfaces change, security features evolve, and the right settings can vary depending on whether the browser is used on a home device, a business laptop, or a managed environment.

For that reason, browser settings, extensions, permissions, and DNS filtering choices should be reviewed from time to time. Layered security remains the right approach. Browser settings are one layer. DNS filtering is another. Identity protection, software updates, email security, and endpoint protection remain separate layers that still matter.

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.

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 still essential for security, but an updated browser can still expose technical information, permissions, and configuration related signals during normal browsing.

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.

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
London, United Kingdom

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
07 May 2026