Google to block third-party code injections in Chrome
Google published a schedule for blocking third-party code injections in the company's Chrome web browser yesterday.
Code injections by third-party software affect about two-thirds of all Chrome users on Windows operating system devices so Chris Hamilton, a member of Chrome's Stability Team. Chrome installations with code injections are 15% more likely to crash according to Google's statistics, and that is the main reason why Google decided to block third-party code injections in the browser.
Two types of applications inject code the most: security solutions and accessibility software. While Google plans to block most code injections in Chrome eventually, it will continue to allow Microsoft-signed code, accessibility software, and IME software.
The change affects security software the most which often integrate in browsers to gain better access and protect against phishing and malware threats.
Google plans to tighten the browser in regards to third-party code injection in three steps:
- April 2018 -- Chrome 66 will inform users if code injection was the cause of a crash in the web browser. It includes information on updating the application that caused the issue, and to remove it.
- July 2018 -- Chrome 68 will block software from injecting code in the browser (with the notable exceptions mentioned above). If Chrome cannot start because of that, Chrome will restart automatically and allow the code injection. A warning is displayed to users however with removal instructions.
- January 2019 -- Chrome 72 will block third-party code injections. There is no bypass anymore.
In little bit over a year, Chrome will block third-party code injections completely. The notifications that Chrome will display during the first and second phase of the process will be an eye-opener to many users on Windows machines.
Code injection happens in the background and without user interaction, and it seems likely that most users are unaware of it happening at all on their machines.
Google recommends that companies who inject code currently in the browser use Chrome extensions or Native Messaging instead.
Companies have about 13 months to remove the code injecting bits from their programs, at least when it comes to Google Chrome, and find a different solution instead. It is unclear right now if other web browsers on Windows will benefit from Google's move as well, or if code injecting will continue to happen in those.
Now You: What's your take on this? (via Bleeping Computer, Chromium blog)
I may be wrong but I assume AV has to inject code into browsers to prevent drive-by malicious downloads for example. So will users be putting their systems at risk by running a browser which is going to block the very application designed to keep them safe online?
So is there a way we block code injections in Chrome on the current version (Chrome 62 on my system today)?
The Chromium blog post (https://blog.chromium.org/2017/11/reducing-chrome-crashes-caused-by-third.html) mentions that “native messaging” provides an alternative to loading third party software, and thus is one reason for precipitating this change now. Mozilla introduced a native messaging API into WebExtensions last year (https://blog.mozilla.org/addons/2017/01/24/preventing-add-ons-third-party-software-from-loading-dlls-into-firefox/). Given the targeted interoperability of WebExtensions with Chromium extensions, how likely is it that this is a feature backported from Firefox into Chrome?
Does this mean, Tampermonkey or Violentmonkey will not work anymore?
No, those are extensions, not third-party software.
I am pleased Google will take this action, although I think their timetable for stopping injectors is overly generous.
I would like to see a Google “blessed” process for Chrome extension approval.