Working Around Extreme Lag of Google Chrome

Update (2016-02-22): Developers have implemented changes to address this issue. While you won’t see the benefit of these changes immediately, it is certainly “coming soon” at this point.

I have been experiencing excessive lag on Google Chrome on Linux for a while, and I have been searching for solutions. The issue itself, has been reported in different incarnation of bug reports, including issue #424082 on Chromium bug reporting system.

Recently, it was tracked by one of the Chromium developers that some font configuration is causing an unnecessary call to fontconfig, giving it bit of a performance penalty.

Perhaps this problem wouldn’t have affected so much about western fonts, because of relatively less load involved in the system to parse western font sets (though I’d think increased CPU load would have been observed, albeit in shorter duration.)

If you are affected by this issue, you’d seen a significant lag in UI interaction, including input to the Omnibox, as well as other actions such as menus.

Unfortunately, a good number of Japanese users may have been encountering this issue, as very common fonts (at least on Linux) such as IPA fonts would have been one of fontsets that can cause this issue.

To work around, in case of KDE, you will have to install kde-config-gtk-style and change GTK styling to use fonts other than ones affected by this issue. (On Gnome, it would be gnome-tweak-tool.)

Note that you will have to restart Chrome everytime you change this setting.

The Chrome SSH client (developer version that supports certificates)

Trying Chrome SSH client (developer version that supports certificates) and it is very usable!

This works very well, and already replacing most of my SSH need.

This is a developer version of the SSH client for Chrome. (you first need to join Google Group for it before you can download it, I believe.)


A Call for Help Resolving Google Chrome Issue

Chrome BugI have been observing the issue with Google Chrome mainly on Mac OS X, that in some instance, the browser would show wrong URL and page title.

For instance, the screenshot on this page shows problem — the page I’ve navigated was, but page title shows “New tab” (my UI is set to Japanese, thus showing it in Japanese) as it also shows chrome://newtab. Reloading this page would cause new tab page to load, and forward and back functionality will function as if it was on the page display on the URL displayed. (If navigated then, and then navigated to — if the bar says then refreshing will refresh to, back button will put you back to, and once you are back to pressing forward button will cause to load. I observe is this can happen in any pages, and persists until I kill the browser process of the page instance. As annoying this could be, this also carries security implication, as one could be navigating to website for bank, and if they have navigated to possible phishing site, the browser still will show URL and title for the bank. So far I have observed this issue on Mac OS X, but it might be happening on other operating systems, too.

I reported this as issue 82073 (may not be visible as it is security issue) however was told they won’t fix unless I have repro step. As I feel it is very critical issue, I would like to see if I can provide them repro step, and the first step is to find out if there are any patterns. However, so far I haven’t found the cause yet.

If you happen to see this issue, please let me know of your environment, URL of the site affected, browser version, extensions installed, as well as any operations you have been doing when you observed the issue. As the security bug, if Google is to offer bounty on it, I will see if they’ll be able to split it among contributors, and if not, I will refuse such payment and have it donated to charity. Main thing is that I want this to be addressed.

Thank you for your help in advance!

Google Chrome for Mac and Linux, and Why That Matters

It has been a little more than a week since stable version of Google Chrome for Mac and Linux was made available by Google. I haven’t tried Mac version, but I’ve tried Linux version.

Linux version supports extensions as much as its Windows counterpart does, and it seems to be they are pretty much compatible out of the box. (which isn’t surprising as they are written mainly in JavaScript.)

Google Chrome is perhaps not adding too much of competition on Linux, as there aren’t so much notion of standard browser, although probably most of distributions are including Firefox as default browser, therefore, I can see it will be start eating some portion of pies from Firefox…

Google Chrome on Mac is more interesting as there is Apple’s own Safari browser. (much like the case of IE on Windows.) It’d be interesting to see how their new version 5, which was released earlier today will compete with it. (word on the street is that Safari now supports extensions.) Though when I used to use Mac, I was on Firefox rather than Safari. I simply didn’t like Safari for some reason.

Google Chrome’s introduction to those additional platform is quite meaningful, because people who are using multiple computers, and often different operating system (for example, Windows at work, Mac/Linux at home) will find Google Chrome’s multi-platform very useful. I can find this availability issue between platforms could defer some users from it. You can use same extensions (which actually somewhat better than Firefox — believe or not, there are Firefox extensions that only supports certain platforms…), same browser sync feature.

Google Chrome won’t be grabbing big chunk of market share overnight, but I can see it slowly approaching to solid two digits sh

Useful Google Chrome Options for Privacy Protections

Google Chrome offers several different parameters you can pass in when you launch the application. Use them, you can disable components of Google Chrome.

  • -disable-extensions disables extension
  • -disable-images inhibit Google Chrome from loading images
  • -disable-java disables Java
  • -disable-javascript disables JavaScript
  • -disable-plugins disables plugin
  • -disable-sync inhibits bookmark sync feature
  • -incognito opens browser in incognito mode

Those parameters need to be passed in the command line. (or if you are using Windows, you can also add those to your shortcut, too.)

For instance, the following would disable both plugins and extensions. (thus no Flash, etc.)

chrome -disable-plugins -disable-extensions

Also there is -proxy-server, which you can also make Google Chrome access through proxy server. (Useful if you are creating SSH tunnel, for example.)

chrome -proxy-server=socks5://localhost:1234

One caution is that in order to use this, you will have to make sure that all instances of Google Chrome are closed, or this will not work.

Getting Rid of Google Chrome’s RLZ Tracking

If you are Google Chrome user and search on Google from the bar (called “OmniBar”) you might have noticed there’s some odd parameter on the URL.

Apparently, this is called RLZ. Masked part would show something like 5FA3ADH_enUSA3AGE332.

According to Chromium Blog article from Google, it’s:

RLZ: When you do a Google search from the Google Chrome address bar, an “RLZ parameter” is included in the URL. It is also sent separately on days when Google Chrome has been used or when certain significant events occur such as a successful installation of Google Chrome. RLZ contains some encoded information, such as where you downloaded Google Chrome and where you got it from. This parameter does not uniquely identify you, nor is it used to target advertising. This information is used to understand the effectiveness of different distribution mechanisms, such as downloads directly from Google vs. other distribution channels. More information is available in the Google Chrome help center. This cannot be disabled so long as your search provider is Google. If your default search provider is not Google, then searches performed using the address bar will go to your default search provider, and will not include this RLZ parameter.

Looks very innocent. But while this may not identify you, if you are using system like Tor, there is privacy implication as it can potentially link your real IP address with Tor routed ones. Think of the scenario where you Google something, then after you enable routing through Tor, search on Google. Even if you don’t use Tor, if you are on your notebook accessing through different access points, it can be tracked too. (I’m not necessary saying Google will do that, I’m saying they can.)

Investigating further, I have located rlz.h header file as part of Google Chromium project. This does not give out implementation of RLZ feature, but the comment on this file reads the following:

RLZ is a library which is used to measure distribution scenarios. Its job is to record certain lifetime events in the registry and to send them encoded as a compact string at most twice. The sent data does not contain information that can be used to identify a user or to infer browsing habits. The API in this file is a wrapper to rlz.dll which can be removed of the system with no adverse effects on chrome. For partner or bundled installs, the RLZ might send more information according to the terms disclosed in the EULA. In the Chromium build the rlz.dll is not present so all the functionality becomes no-ops.

Interestingly, it seems to indicate that removing rlz.dll causes this feature to be disabled. So I tried that.

I exited Google Chrome and went into C:\Program Files\Google\Chrome\Application\5.0.375.38 (yes, I use beta) and located rlz.dll. I’ve renamed rlz.dll to rlz.dll.bak, so Google Chrome will not find it, and restarted Google Chrome.

Looks like this really did get rid of it.

One note is that I can’t seem to locate equivalent file for Linux installation. Not sure if they are embedded within binary (in which case it is hard to remove) or located elsewhere at the moment. Same goes for Mac version. Mac version might have this file within application bundle.

[Update: Looks like current Linux beta do not have this feature built-in. Not sure about Mac version.]

Another thing to note is, when auto updater on Google Chrome kicks in, you’ll see come this file come back, as it’ll be installed on separate directory under aforementioned Google Chrome directory (5.0.375.xx in case of beta channel). In that case, you can remove newly created rlz.dll, unless Google changes this structure.

[Update: Also, you could just install from and it will be deactivated. But it is only given if you do not have active Google Chrome installed.]