A recurring problem for the Chrome ecosystem is third party programs that rely on private implementation details of Chrome to operate. Because Chrome is always updating, unsupported dependencies on how Chrome operates have a very high risk of failure. Activities like reading and writing the preferences file directly, locking the Chrome preferences directory, injecting DLLs into Chrome and relying on assumptions about Chrome’s window management can all be problematic when Chrome updates.
Issues have arisen with toolbars, PC cleaners, so-called ‘browser managers’ and many other third party programs ranging from innocuous and well intentioned to likely malicious - all of them causing problems for users by assuming that Chrome’s implementation is static and dependencies can be safely introduced. Such assumptions are one of the leading causes of Chrome crashes, profile and IndexDB/LevelDB corruption and broken Chrome UI. Sometimes they even prevent Chrome from successfully installing in the first place.
The best and most reliable way to help your users make changes to Chrome is by showing them how to make those changes within Chrome’s UI. If your native app relies on Chrome’s internal implementation details, you should expect it to break on a regular basis.
Since one common source of instability and unwelcome loss of user control is third party programs from Windows programs attempting to offer changes to common search related settings such as homepage and default search engine we have built an extension based Settings API for Windows. Using the API will ensure that the offer works correctly and also that users have given consent and control over the changes to their critical browser settings. Where available, the API is the only approved path for making changes to those settings in Chrome.
Some DLLs are known to cause stability issues when loaded into Chrome. This outlines how a DLL is blacklisted, as well as what steps can be taken to remove a DLL from the blacklist.
Once a DLL has been determined to cause a noticeable decrease in Google Chrome’s stability, that DLL will be added to this list of troublesome DLLs for sandboxed processes or this list of troublesome DLLs for the browser process, which Chrome prevents from being injected into the corresponding process.
Once a DLL has been selected, an effort will be made to find the developer of the DLL. If the developers are found, they can receive some debugging information to assist them in fixing the problem. Additionally, an announcement about our intention to blacklist the DLL will be sent to email@example.com.
If a DLL is causing serious stability issues, it will be added to the blacklist right away.
If the DLL doesn’t need to be blacklisted right away, the developer will have at least 3 business days to respond to the issue. If there is no response from the company, the DLL will be added to the blacklist.
If the company responds, they will then have an additional week to fix the troublesome DLL. If the DLL is still causing a noticeable decrease in Chrome stability, it can be blacklisted.
If at any point during this process the DLL starts causing serious stability issue, it may be immediately blacklisted.
Note For Chromium Developers:
If you are blacklisting or wanted to blacklist a dll, you are responsible for following the instructions above (trying to find and contact the developer at first, and then alerting firstname.lastname@example.org when the dll is actually blocked).
Note For Google Developers:
If you have a dll that you think should be blacklisted, the internal page go/modulestabilityreport can help you determine the stability of the dll and if it should be blacklisted.
If your DLL has been blacklisted and the issue has been fixed, you may request to be removed from the blacklist by contacting email@example.com. If the DLL still causes stability issues, it will be blocked again.