Google Chrome is preparing to reject policy-installed extensions that take over the New Tab page or default search engine on unmanaged Windows and macOS machines, closing a persistence route long used by browser hijackers. The protection is still under Chromium review and is not available in Stable Chrome, but Ghacks reports that Google intends to switch it on by default once the change is approved.
The important boundary is where Chrome draws trust. A browser governed through Active Directory, Microsoft Entra ID, an MDM platform, or Chrome Enterprise management has an administrator Chrome can identify. A personal PC with policy values dropped into the local registry does not. Yet today, both can cause Chrome to force-install extensions and lock users out of removing them.
That equivalence is the flaw Google is now trying to narrow. Chromium contributor Anunoy Ghosh has previously described locally applied policies as a “low-trust” management environment, and Google’s existing Chromium work already treats local-registry policy differently from domain-joined and cloud-managed devices. The newly reported work applies that distinction to a particularly lucrative class of unwanted extension: one that controls where a new tab opens or where an address-bar search goes.
On a genuinely managed Windows PC, Chrome’s enterprise policy system is supposed to be strong enough to prevent an employee from removing a mandated extension or changing a company search configuration. Google documents supported policies for specifying a New Tab page and setting the default search provider, including Windows Group Policy paths for both kinds of configuration.
The trouble begins when unwanted software writes equivalent policy data locally. Chrome sees a policy-installed extension, labels it administrator-controlled, and may display “Managed by your organization.” The person at the keyboard can be left with an extension they cannot disable or uninstall through the normal Extensions page, even though there is no employer, school, MDM service, or domain behind the machine.
Ghacks’ reporting describes a proposed Chromium feature named
The proposed behavior goes further than showing a warning. Chrome would store the extension ID as blocked and stop retrying its download on later policy refreshes. That matters on infected PCs: if Chrome merely removed the extension but kept rereading the malicious force-install instruction, the browser could repeatedly fetch and restore it. Recording the ID creates a browser-side refusal state.
Google has already established the underlying trust model in code shipped for a different class of extension abuse. Chromium changes from 2025 added the ability to silently disable force-installed extensions that were greylisted for Chrome Web Store policy violations or unwanted-software concerns when installed through low-trust local policy. Google’s Chrome Enterprise release material says that protection applies to unmanaged Windows and macOS environments, while excluding domain-joined, Entra ID-joined, MDM-managed, and Chrome Enterprise Core-managed deployments.
The New Tab and search-engine proposal appears to turn that same model toward behavior rather than a Web Store enforcement status. In practical terms, Chrome would not need Google to first greylist the extension: the browser would identify the attempt to force-install an extension that claims these high-value browser controls on a consumer PC.
Chrome’s own enterprise documentation confirms that an administrator can configure
That distinction changes the support advice. When this feature eventually arrives, it should reduce one durable category of locked extension hijacker. It will not turn Chrome into a general cleanup tool for every PC that says it is managed. A consumer who sees an unfamiliar search engine, unexpected New Tab URL, or administrator-installed extension still needs to identify the process, installer, scheduled task, management agent, or registry policy that made the change.
The proposal also reportedly prevents a manually installed extension from being converted later into a locked policy installation. That is a useful edge-case fix. Without it, an unwanted program could take an extension the user originally installed voluntarily and alter its status so Chrome treats it as untouchable administrative software.
There is another cleanup path in the design: when a formerly managed device loses its trusted management status but local policy keys remain, Chrome would remove affected New Tab and search override extensions. That could help after a device leaves an organization, is decommissioned, or is restored from a corporate image. It also means IT teams that casually use local policy on machines outside their formal management boundary may see behavior change after the feature ships.
That is sensible for deployments that use a corporate portal, internal search product, or a search-first extension that replaces the standard New Tab experience. It also introduces a familiar administrative risk: an exception intended for a narrow business app becomes a permanent broad bypass. Security teams should inventory force-installed extensions that modify browser search or New Tab behavior before the change reaches Stable, document why each is needed, and test the policy transition on representative Windows and macOS clients.
Administrators should also verify that devices described as managed actually satisfy Chrome’s trust checks. Google’s previous low-trust extension controls distinguish local policy from Windows devices joined to Active Directory or Entra ID, and from macOS endpoints managed through MDM or an appropriate domain arrangement. Merely writing Chrome policy to a registry key is not equivalent to deploying Chrome through an auditable management channel.
For personal Windows PCs, the feature should be viewed as prevention rather than remediation. It may stop a new bad extension from becoming entrenched, but it cannot remove the program that wrote the policy or guarantee that program will not use another persistence method.
Next, inspect
A sensible response sequence is:
Google has not announced a Chrome version, channel milestone, or rollout date for the feature. Until it does, the immediate operational lesson is straightforward: an unexpected “Managed by your organization” message on a personal PC is evidence to investigate the machine, not proof that Chrome itself is the source of the problem.
That equivalence is the flaw Google is now trying to narrow. Chromium contributor Anunoy Ghosh has previously described locally applied policies as a “low-trust” management environment, and Google’s existing Chromium work already treats local-registry policy differently from domain-joined and cloud-managed devices. The newly reported work applies that distinction to a particularly lucrative class of unwanted extension: one that controls where a new tab opens or where an address-bar search goes.
The browser hijack survives because Windows treats it as policy
On a genuinely managed Windows PC, Chrome’s enterprise policy system is supposed to be strong enough to prevent an employee from removing a mandated extension or changing a company search configuration. Google documents supported policies for specifying a New Tab page and setting the default search provider, including Windows Group Policy paths for both kinds of configuration.The trouble begins when unwanted software writes equivalent policy data locally. Chrome sees a policy-installed extension, labels it administrator-controlled, and may display “Managed by your organization.” The person at the keyboard can be left with an extension they cannot disable or uninstall through the normal Extensions page, even though there is no employer, school, MDM service, or domain behind the machine.
Ghacks’ reporting describes a proposed Chromium feature named
kBlockDseNtpOverrideExtensionsOnUnmanagedDevices. “DSE” is Chromium shorthand for default search engine, while “NTP” means New Tab page. On an unmanaged Windows or macOS installation, Chrome would cancel a policy-directed extension installation if that extension tries to override either surface.The proposed behavior goes further than showing a warning. Chrome would store the extension ID as blocked and stop retrying its download on later policy refreshes. That matters on infected PCs: if Chrome merely removed the extension but kept rereading the malicious force-install instruction, the browser could repeatedly fetch and restore it. Recording the ID creates a browser-side refusal state.
Google has already established the underlying trust model in code shipped for a different class of extension abuse. Chromium changes from 2025 added the ability to silently disable force-installed extensions that were greylisted for Chrome Web Store policy violations or unwanted-software concerns when installed through low-trust local policy. Google’s Chrome Enterprise release material says that protection applies to unmanaged Windows and macOS environments, while excluding domain-joined, Entra ID-joined, MDM-managed, and Chrome Enterprise Core-managed deployments.
The New Tab and search-engine proposal appears to turn that same model toward behavior rather than a Web Store enforcement status. In practical terms, Chrome would not need Google to first greylist the extension: the browser would identify the attempt to force-install an extension that claims these high-value browser controls on a consumer PC.
What this proposal does — and does not — block
The change is a meaningful fix, but the wording around “search hijacking” needs precision. It targets policy-installed extensions that override Chrome’s default search engine or New Tab page. It does not, on the reported design, erase every local policy capable of changing those settings.Chrome’s own enterprise documentation confirms that an administrator can configure
NewTabPageLocation directly and can set a default search provider through the DefaultSearchProvider policy family. Those policies have legitimate corporate uses. They are also separate from the extension-install mechanism. If malware writes direct search-provider or New Tab policy values rather than delivering the change through an extension, this proposed extension block alone would not necessarily restore the user’s chosen settings.That distinction changes the support advice. When this feature eventually arrives, it should reduce one durable category of locked extension hijacker. It will not turn Chrome into a general cleanup tool for every PC that says it is managed. A consumer who sees an unfamiliar search engine, unexpected New Tab URL, or administrator-installed extension still needs to identify the process, installer, scheduled task, management agent, or registry policy that made the change.
The proposal also reportedly prevents a manually installed extension from being converted later into a locked policy installation. That is a useful edge-case fix. Without it, an unwanted program could take an extension the user originally installed voluntarily and alter its status so Chrome treats it as untouchable administrative software.
There is another cleanup path in the design: when a formerly managed device loses its trusted management status but local policy keys remain, Chrome would remove affected New Tab and search override extensions. That could help after a device leaves an organization, is decommissioned, or is restored from a corporate image. It also means IT teams that casually use local policy on machines outside their formal management boundary may see behavior change after the feature ships.
Enterprises keep an override, but should not treat it casually
Google is not removing the ability to force-install a legitimate search or New Tab extension in managed environments. Ghacks reports that an enterprise escape-hatch policy will allow administrators to opt out where a business has a genuine requirement.That is sensible for deployments that use a corporate portal, internal search product, or a search-first extension that replaces the standard New Tab experience. It also introduces a familiar administrative risk: an exception intended for a narrow business app becomes a permanent broad bypass. Security teams should inventory force-installed extensions that modify browser search or New Tab behavior before the change reaches Stable, document why each is needed, and test the policy transition on representative Windows and macOS clients.
Administrators should also verify that devices described as managed actually satisfy Chrome’s trust checks. Google’s previous low-trust extension controls distinguish local policy from Windows devices joined to Active Directory or Entra ID, and from macOS endpoints managed through MDM or an appropriate domain arrangement. Merely writing Chrome policy to a registry key is not equivalent to deploying Chrome through an auditable management channel.
For personal Windows PCs, the feature should be viewed as prevention rather than remediation. It may stop a new bad extension from becoming entrenched, but it cannot remove the program that wrote the policy or guarantee that program will not use another persistence method.
What affected users should do before Chrome ships it
Users should not wait for an unannounced Chrome release to investigate a browser that claims organizational management on a personal PC. Chrome’s policy viewer remains the fastest first check: enterchrome://policy in the address bar, reload policies, and look for unfamiliar extension, New Tab, or default-search entries. The page shows the policy name, current value, and source; it does not prove that a policy is legitimate.Next, inspect
chrome://extensions for entries marked as installed by an administrator. Do not assume removing an extension will solve the problem. A policy force-install entry or the unwanted software responsible for it can restore the extension the next time Chrome checks policy.A sensible response sequence is:
- Run a reputable anti-malware scan and remove the software or persistence mechanism that introduced the policy.
- Review Chrome’s policy page again after cleanup, paying special attention to extension force-install settings and default-search or New Tab policies.
- Remove only the policy entries that are confirmed unwanted, then restart Chrome and verify that the extension does not return.
- If the PC belongs to an employer or school, stop there and contact the administrator; deleting legitimate policy can break required security tooling and may violate organizational rules.
Google has not announced a Chrome version, channel milestone, or rollout date for the feature. Until it does, the immediate operational lesson is straightforward: an unexpected “Managed by your organization” message on a personal PC is evidence to investigate the machine, not proof that Chrome itself is the source of the problem.
References
- Primary source: gHacks
Published: 2026-08-03T08:24:37+00:00
Loading…
www.ghacks.net - Related coverage: support.google.com
Loading…
support.google.com - Related coverage: support.google.com
Loading…
support.google.com - Related coverage: developer.chrome.com
Loading…
developer.chrome.com - Related coverage: developer.chrome.com
Loading…
developer.chrome.com - Related coverage: groups.google.com
Loading…
groups.google.com - Related coverage: security.googleblog.com
Loading…
security.googleblog.com - Related coverage: chromeenterprise.google
Loading…
chromeenterprise.google - Related coverage: services.google.com
Loading…
services.google.com - Related coverage: services.google.com
Loading…
services.google.com - Related coverage: chromium.googlesource.com
Loading…
chromium.googlesource.com - Related coverage: cyberdefenders.org
Loading…
cyberdefenders.org - Related coverage: ipfly.net
Loading…
www.ipfly.net - Related coverage: patents.google.com
Loading…
patents.google.com - Related coverage: conferinte.stiu.md
Loading…
conferinte.stiu.md