Google Will Block Third-Party Software From Injecting Code Into Chrome (bleepingcomputer.com)
Catalin Cimpanu, writing for BleepingComputer: Google has laid out a plan for blocking third-party applications from injecting code into the Chrome browser. The most impacted by this change are antivirus and other security products that often inject code into the user's local browser process to intercept and scan for malware, phishing pages, and other threats. Google says these changes will take place in three main phases over the next 14 months. Phase 1: In April 2018, Chrome 66 will begin showing affected users a warning after a crash, alerting them that other software is injecting code into Chrome and guiding them to update or remove that software. Phase 2: In July 2018, Chrome 68 will begin blocking third-party software from injecting into Chrome processes. If this blocking prevents Chrome from starting, Chrome will restart and allow the injection, but also show a warning that guides the user to remove the software. Phase 3: In January 2019, Chrome 72 will remove this accommodation and always block code injection.
Chrome already has a lot of protections built in, including blocking known malicious sites. It appears to be Google's judgement that third party injected code from AV vendors doesn't add any real value or causes too many crashes. Vendors can still install extensions to do the same thing.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Plugins are JavaScript with access to a restricted set of JavaScript APIs, and the plugin system is designed and tested by Google and provides compatibility between releases. It should be almost impossible for a plugin to crash the browser, if it manages then that's a browser bug. While plugins themselves are very restricted, they can use the Native Messaging API to talk to a separate native process that has full access to the system. The separate native process is not part of the browser, so any bugs in it can't crash the browser.
Injection involves injecting native code into the browser in a way that Google don't expect, using APIs that may change between releases (they may even change in a security update). Any bugs will crash the browser.
I love it. I wish other software vendors would do a better job and informing users as to the root cause of issues they're seeing. More information is better. I don't care if something like "Please wait" or "oops, sorry" tested as being friendlier. I want information!
Google's next new feature will be to require users to raise their hand and ask permission before typing a URL in the address bar. If you aren't clicking a link in a Google search result page you're just asking for trouble!
I'd rather it ask permission than not allow a download. Comodo firewall deleted a keygenerator I use. Not put it in a safe place or recycle bin but removed it, without a word.
... first-party injection.
It little behooves the best of us to comment on the rest of us.
What's the difference between "plugging in" and "injecting"? Spin!
Hardly, and I'm a little disappointed that there's a need to explain the difference to an adult.
You plug things into receptacles designed to accept those things, whereas you inject things so as to bypass barriers that those things are not otherwise able or intended to cross. I'm not "injecting" a power plug when I plug it into the wall. The wall outlet is designed to take the plug. I'm not "plugging in" a syringe when I receive a tetanus booster shot in my arm. It's being injected into me in order to bypass my skin, which would otherwise keep it out.
Chrome provides frameworks by which developers can "plug in" third-party code (e.g. userscripts, extensions, apps, etc.), and many of us here have experience in developing those. But those frameworks are intentionally limited so that they can only accept code that's designed to work within their APIs. In contrast, the code being injected by these third parties has no such constraints, since they've injected it in a way that bypasses Chrome's frameworks.