The article emphasizes that the next version of Firefox Quantum will be the major release for Firefox.

I have been using Chrome as my primary web browser for a long time, while before, I have been using Firefox. But recently, I am finding I am using more Firefox more often.

From few different perspective, here are my thought on this topic. With this article, I am not making assertion that the one browser is better than others, but to get the foundation out so it can be compared time to time.

Platform Support

Chrome and Firefox both supports Windows, Linux, and Mac. Thus they are on par with this perspective.

Feature Comparisons

Browser Sync

Chrome supports syncing via Google Sync, and Firefox via Firefox Account. They offer similar functionality. Both Chrome and Firefox offer encrypted sync. Perhaps Firefox’s sync feature is a little more comprehensive as it supports history syncing while Chrome seems to be limited in this regard.

Security

Both Chrome and Firefox are discovered with good number of security issues. (and it is important they are addressed in timely manners, too!) Discussing these can be article of its own, so I am focusing here regarding the security feature.

Chrome has been supporting sandboxing and most recent version of Firefox is supporting it as well. From more robust multi process design with Chrome (more of that in later) perhaps in this area, Chrome has bit of edge compared to Firefox.

One thing I like about Firefox that lacks on Chrome is the support of master password, which you can lock password store with the master password.

Chrome has recently moved toward hiding security information from the browser interface, perhaps to make it more user friendly. One illustration of this problem is that they are making jump through some hoops to be able to look up certificate information. (Through developer tools.) While this can be turned back on through experimental features, it is bit concerning they are hiding this information for the sake of user friendliness; if that’s the reason.

Operating System Integration

Chrome uses operating system’s own certificate management where available, which makes it easy to integrate in environment where internal certificate (while this is not a best practice, but it happens!) or internal Active Directory authentications are used.

Firefox, in contrast, uses Network Security Service, which basically is a security storage independent of the system. This makes the system less integrated with the one configured through the system. While configuring Active Directory authentication for Firefox is certainly possible, it is not a simple one-click process.

With this regard, Chrome seems to integrate a little better with the operating system.

Google Service Integration

This is somewhat silly notion when Chrome is designed by Google who owns those Google services. One of the major blocking factor is if there’s Chromecast involved, as at least from the desktop, there is no practical way to control it outside of Chrome.

Other than that, aside from some services that heavily expect Chrome to be used, most of Google Service should work on both of those browsers.

Mobile Versions

With extensions support, it appears Firefox for Android, also known as Fennec feels like a mobile port of the desktop version rather than the scaled down version, which is the way every time I use Chrome I can’t help notice.

Internal Designs

Chrome is designed from the ground up with multi-process utilization in mind, which this development was relatively recent with Firefox. While they work similar, with this regard, perhaps Chrome has a slight advantage of this in stability. Multi process support for Firefox, called Electrolysis can be disengaged for having incompatible feature sets (like accessibility) or extensions. This problem usually comes from the older type of extensions, and perhaps will soon go away when Firefox 57 only supports WebExtension.

Other Features I Love

Firefox features a reader mode. This mode is very useful when reading long article as it removes a lot of clutter off the document. (Also supported on a mobile version as well!)

Like this:

As much as Hideki’s Songlist Offline started off from my needs (and still serving mostly for that reason…) this offline solution also comes from my desire to have offline access to the Hideki’s Songlist even when there is no Internet connection available.

As Hideki’s Songlist already exposes API to exchange data outside of the system, in the form of text/songlist, this project involved implementing text/songlist parser on the local side.

Hideki’s Songlist Offline takes same premise, however, I have decided to use AngularJS this time. This simplified JSONP parsing.

Once JSONP is loaded from Hideki’s Songlist web system, it is stored into local storage database. This essentially creates replicated copy of songdata library. Currently, when the update button is pressed, it drops whatever you have in current database and reload fresh copy of list from the server. This is ridiculously inefficient, so expansion is planned to deliver only updated information through the API.

Once data is loaded, subsequent loading of the Chrome app will load current contents within the database instead of one on the server, thus realizing offline functionality of Hideki’s Songlist.

I’ve created this project in 3 hours or so, thus still a lot to polish. The code is available from songlist-offline-client on GitHub. If you want to experiment plugging it with your own implementation of text/songinfo, please feel free to do so.

Share this:

Like this:

I 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 creativecommons.org, 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 slashdot.org then cnn.com, and then navigated to creativecommons.org — if the bar says http://www.cnn.com/ then refreshing will refresh to cnn.com, back button will put you back to slashdot.org, and once you are back to slashdot.org pressing forward button will cause cnn.com 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.

Share this:

Like this:

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

Share this:

Like this:

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 google.com/chrome and it will be deactivated. But it is only given if you do not have active Google Chrome installed.]

Share this:

Like this:

LikeLoading...

Search for:

Items contained in Hideki's Random Stuff are views of Hideki Saito and may not necessary reflects views of his employer, and/or affiliates. Fact and opinion presented in each post may not be up to date and may not reflect current status.