Make Chrome 69 great again

Chrome 69 introduced quite a few controversial changes, this is an effort to document all relevant chrome://flags settings to revert most of them.

Update: Google removed the flag from the browser in Chrome 71, released in December 2018. There is no option anymore to restore the old Chrome design.

A note about Chrome Flags

The chromium team specifically mentions that there are no guarantees made about them (as opposed to Firefox). That means they could vanish at any time in a future update (and they often do). Let’s just hope they last long enough until Google realizes that e.g. stripping vital parts of the URL is probably not a good idea. :-)

Due to security reasons websites can’t link to chrome://flags directly, just copy paste them into your address bar and make the mentioned changes.

Problem: Material Design refresh, rounded tabs

I guess this boils down to personal preference but I like the classic design for my daily driver better.

For me, the main downside of the new UI is that on macOS the account switcher doesn’t state the profile name anymore, which makes it harder to quickly discern which profile I’m currently using:

Since Chrome 69

When reverted back

chrome://flags/#top-chrome-md
==> Normal

Problem: URLs in the omnibox are shortened, lacking the protocol

As a web developer this change is especially annoying, caused bugs and makes me slower in my daily work.

It’s not only the protocol (https://) but www. and other sub domains Google deemed irrelevant will be stripped as well.

chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains
==> Disabled

Problem: The omnibox prefers titles over URLs, became dumbed down

Personal preference but I find it much quicker to eyeball URLs than fluffy website titles to understand what’s going on.

The following change will put the URL back to the left, before the title.

chrome://flags/#omnibox-ui-swap-title-and-url
==> Disabled

And Google is shortening URLs in the omnibox dropdown as well.

chrome://flags/#omnibox-ui-elide-suggestion-url-after-host
==> Disabled

Problem: Signing into a Google Service will cause a Browser sign in as well

A very controversial and somewhat sneaky change by Google caused the browser to be signed in whenever the user is signing into a Google owned website as well.

I understand in part the motivation behind it (e.g. Chrome Store Payments will use the Browser Account, whereas the Chrome extension could have been downloaded through a different Google Account, causing inconsistencies).

Still, the way this was implemented and (not) communicated is not acceptable. As a side-effect it’s very easy to accidentally sync all browser data with Google.

chrome://flags/#account-consistency
==> Disabled

Outlook

It certainly feels like Google is on a quest to make the browser more accessible to mainstream audiences, or in other words to continuously dumb it down.

Unfortunately this comes at the expense of privacy and developer happiness. For now it’s possible to revert most of these changes but it’s questionable how long that will be possible in the future.

If Google continues down this path the next blog post in this series will most likely compare other chromium based browsers to Google Chrome.

As a web developer there’s no alternative to the excellent built-in chromium DevTools and it’s a shame that Google is giving away all the good will the built up in the developer space over the years, eventually forcing people to look into alternative browsers.