Google to block third-party code injections in Chrome - gHacks Tech News

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.

chrome code injection block

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)

 

 

Summary
Google to block third-party code injections in Chrome
Article Name
Google to block third-party code injections in Chrome
Description
Google published a schedule for blocking third-party code injections in the company's Chrome web browser yesterday.
Author
Publisher
Ghacks Technology News
Logo
Advertisement

We need your help

Advertising revenue is falling fast across the Internet, and independently-run sites like Ghacks are hit hardest by it. The advertising model in its current form is coming to an end, and we have to find other ways to continue operating this site.

We are committed to keeping our content free and independent, which means no paywalls, no sponsored posts, no annoying ad formats or subscription fees.

If you like our content, and would like to help, please consider making a contribution:


Previous Post: «
Next Post: »

Comments

  1. chesscanoe said on December 1, 2017 at 11:22 am
    Reply

    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.

  2. Knocker said on December 1, 2017 at 2:36 pm
    Reply

    Does this mean, Tampermonkey or Violentmonkey will not work anymore?

    1. Martin Brinkmann said on December 1, 2017 at 3:02 pm
      Reply

      No, those are extensions, not third-party software.

  3. foolishgrunt said on December 1, 2017 at 7:23 pm
    Reply

    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?

  4. Matthew J Borcherding said on December 2, 2017 at 12:37 am
    Reply

    So is there a way we block code injections in Chrome on the current version (Chrome 62 on my system today)?

  5. TelV said on December 3, 2017 at 6:06 pm
    Reply

    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?

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

Please note that your comment may not appear immediately after you post it.