Google has made a few changes to recent Chrome versions that most users are bound to disagree with since it takes away some of their control over the browser.
The biggest of these changes is the removal of the chrome://plugins page in the upcoming Chrome 57 version.
This page is where users can enable or disable Chrome plugins such as the Widevine DRM, Adobe Flash Player, the built-in Chrome PDF viewer, and the Native Client C/C++ sandbox.
According to this page on the Chromium project bug tracker, Google engineers have talked about deprecating the chrome://plugins settings page since May 2016.
Based on Google's explanation, the reason to remove this page is that it already moved most of these controls in the Google settings pages.
Taking a closer look at the plugins, this is not so, because only the Flash and built-in PDF viewer have options in the settings section that allows users to disable them, while some plugins are now unremovable.
"Since we've deprecated NPAPI, Flash Player is now our last remaining plugin (i.e. 3rd party binary modules)," Google engineers said. "Those remaining 'plugins' (PDF, CDM, etc...) started life as 3rd party code, but have since been built and maintained by Google... and at this point are effectively just specialized libraries for Chrome."
In simpler terms, Google doesn't want users turning off some plugins anymore, such as Widevine and the Native Client.
Chrome users like to disable these plugins (not to be confused with extensions) due to security reasons, because they introduce an extra attack surface in the browser. Others disable the plugins due to performance issues, mainly because they lead to Chrome crashes. Other reasons about disabling the Widevine plugin are detailed in finer detail here.
The last Chrome version where users can turn off plugins is Chrome 55 since in Chrome 56, every change made to the chrome://plugins page will be discarded when the user restarts his browser the next time, and all plugins will be re-enabled automatically.
But running an outdated Chrome version just for the option to disable a few unwanted plugins is far more insecure than any attack surface any of these plugins could potentially expose, which means users will be forced to accept Google's modifications whether they like it or not.
Another change that hardcore Chrome users didn't like was the relegation of the HTTPS status information to the Developer Tools section, starting with Chrome 56, released last week.
Prior to version 56, you simply had to click the green lock in the URL bar to get information on a site's HTTPS certificates.
Now users have to press F12 to open the Developer Tools, click on the Security tab, and locate the HTTPS certificate information on the right-side panel.
From a security viewpoint, the decision to move the location of a website's HTTPS information to the Developer Tools makes no sense.
If this wasn't enough, Google also announced plans last week to limit the processing power of background Chrome tabs.
While Google says that most websites won't be affected, most web developers who analyzed Google's proposal say this would affect websites that deal with real-time data, such as email systems, chats, social networks, live text feeds, and more.
These changes weren't made in Chrome alone, but are also reflected in the Chromium project, used as the base for other browsers, such as Opera, Vivaldi, Brave, and others.
These browser vendors can opt out of implementing these modifications, but as we've seen in the past, almost all core changes to the Chromium project eventually end up in all the smaller off-shoots.
These types of changes generally go unnoticed by regular Chrome users, but taking away the options to modify core browser settings might alienate Chrome's hardcore userbase, who like to tinker with their browser, make it their own, and feel at home on the Web. It goes without saying that most people don't react very well when you remove the knobs on their water taps.