Test Instructions for Third-Party Software Blocking
(This doc is available at https://goo.gl/SFPNC5)
Disabling the blocking feature for testing
This page provides instructions on how to test Chrome’s third-party software warning and blocking features on Windows. Third-party software is defined as any DLL that is not signed by either Google or Microsoft.
With the warning feature enabled, Chrome will display a list of third-party software that injects a DLL into the browser process following a crash, whether or not one of the injected DLL caused the crash. The warning feature only works on Windows 10. Note that it is possible to force a crash of the browser by typing chrome://inducebrowsercrashforrealz in the address bar.
When the blocking feature is enabled Chrome will stop third-party DLLs from loading into the browser process. Note that the effect is not immediate as each DLL is allowed to load once while it is analyzed in the background. If it is determined that the module should have been blocked, it is added to a blacklist cache that will take effect on the next Chrome start.
To reset the blacklist cache, simply delete the User Data directory. Its path can be found by looking at the Profile Path on the chrome://version page. A backup of this folder should be made to ensure you don't lose your personal profile.
To disable both blocking and warning use the following command-line
chrome.exe --disable-features=IncompatibleApplicationsWarning,ThirdPartyModulesBlocking |
To enable only warning[1] use the following command-line
chrome.exe --enable-features=IncompatibleApplicationsWarning --disable-features=ThirdPartyModulesBlocking |
To enable both warning and blocking use the following command-line
chrome.exe --enable-features=IncompatibleApplicationsWarning,ThirdPartyModulesBlocking |
Note that the above command-line flags will eventually be deprecated as the code moves from being experimental to being a permanently enabled feature of Chrome. It will always possible to disable the both features by using the following command-line
chrome.exe --allow-third-party-modules |
This flag entirely disables both feature but displays a prominent warning to the user informing them of this fact. It is intended to allow developers of whitelisted software to easily test pre-release versions of their software against a running instance of Chrome.
Note that neither the warning nor blocking features will function until the “Third Party Module List” component has been downloaded. To ensure this is the case, open the chrome://components page, search for the “Third Party Module List” component and click “Check for Update”. A version number other than 0.0.0.0 will be indicated after a successful install.
Note that the first time a module is seen it is always allowed to load. After a first injection the module is analyzed to determine whether or not it will be allowed to load during the next startup. The result of this analysis will be one of the strings described below.
To see if a module is successfully blocked or not Chrome must be restarted after the analysis has been performed. At this point the decision from the earlier analysis will be applied in either allowing the module to load or blocking the module from loading. The status string associated with the module will also describe whether or not the module was successfully blocked.
To fully evaluate the effects of this feature on third party software Chrome must be started in the presence of the software twice, and the analysis must have completed during the first startup. The best way to ensure the analysis completes is to visit chrome://conflicts and wait for the page to load.
Further note that some software only injects in some situations, and may require specific user interaction to trigger the injection. As an example, many shell extensions only inject if a “File Open” or “File Save” dialog is opened, and a file is right-clicked. Other software may require other specific actions in order to trigger injection.
When either feature is enabled the chrome://conflicts page displays information about which modules will either be blocked or cause a warning to be displayed should Chrome crash. Under the "Conflicts Status" column, you'll find a text description of how Chrome will treat the module.
The following strings describe the result of the module analysis:
The certificate of the module matches the certificate of chrome.exe (ie, this is a Google module).
It's possible to view the list of incompatible applications by opening the chrome://settings/incompatibleApplications page. Note that this page can only be opened if one of the DLLs in chrome://conflicts is marked as "Disallowed".
Once a module has been analyzed and the decision made to blacklist it, further load attempts on subsequent startups will be blocked. When this occurs the status string will be updated to indicate the status of the module with respect to the blocking logic. The following strings describe this status:
Note that the above strings are not necessarily mutually exclusive, and that multiple strings can be concatenated to describe the current situation. For example, it’s possible for the following description to arise:
Chrome will automatically detect when the ThirdPartyModulesBlocking feature is disabled, but it could take a few minutes and require a Chrome relaunch. But if you are testing the feature using the command-line flag or the group policy, it’s possible to force Chrome to pick up the change by following these steps:
[1] Note that the IncompatibleApplicationsWarning feature is enabled by default for Chrome 68 and later releases as of 17 August 2018. The associated feature flag still exists but is slated for removal in Chrome 71.