A Very Close Look at Comodo Dragon

Updated August 25, 2012.

This site is no longer being maintained so anything below could still be accurate, or very outdated.

Since last December's article on Chrome, Chromium and Iron, I’ve received various questions about Comodo’s Dragon browser. What’s the difference? Is it better? It’s from Comodo so it must be holier than all, right? And so on.

Why I’m just writing about it now, I do not know, but the last version of Dragon I used was 6 (circa late 2010) so I wasn’t much help to anyone. Now I hope to redeem myself in eyes of the 5, maybe 6 people who read this site. In this edition of tSc goodness are the discernible changes Comodo made to Dragon and I did the packet sniffing exercises as was done with the other Chromium browsers.

Comodo Dragon stepped onto the web browser scene in November of 2009 and like SRWare’s Iron, billed itself as THE privacy friendly alternative to Google Chrome. Dragon is closed source but built from Chromium’s source code. It is Windows only and the release cycle generally keeps pace with Chrome stable. Like Chrome, Dragon automatically updates itself and Dragon points to the Chrome Web Store for extensions, themes and such things.

Little of that is important now though, because the privacy and security changes are what we care about here. Problem is, Dragon’s download page is far from a persuasive experience. Comodo excels at hyping their products with generic and weak supporting information. For example, under the features tab it humorously reads that Dragon "stops cookies and web spies" and "prevents all download tracking". While they’re not false claims, all modern browsers allow various cookie blocking policies and an internet browser has nothing to do with tracking downloads beyond its download history (which is easily deleted on most browsers).

"Web spies" or web bugs, scripts, trackers, whatever you prefer to call them, are combated by limiting or disabling JavaScript and plugins, and/or by using an ad blocking extension—not by changing browsers. Again, all modern browsers can do this and Dragon’s JavaScript and plugin capabilities are no different than its Chromium-based cousins. Thus Comodo’s claims are about as significant as they are unique to Dragon, which are not at all. It’s like if, in 2012, a car manufacturer were to laud their model is better than the competition because it comes with airbags and seatbelts. Marketing fail, Comodo. I feel only disappointment.

But hang on! Comodo also says that Dragon wields "privacy enhancements that surpass Chromium’s technology" and "stronger security features". Ah, finally something to dig into. The only possible response?


Dragon’s installation process gives you some extras you won’t find with the other Chromium browsers. You can opt to have it install Adobe Flash and the installer offers to make Dragon portable. Dragon installs to its own directory tree so it’s possible to have Dragon, Chrome and Chromium all on one computer. Next, I could choose whether to use Comodo's Secure DNS for domain name resolution and then I was informed that my free lifetime license for Dragon would be activated. I spend most of my time in Linux systems so this unnecessary verbiage had an effect on me probably similar to how your dog feels when you feint throwing a tennis ball out of his view.

Comodo did a thorough job of rebranding Chromium, even redirecting internal chrome URLs to say dragon. Notice the two icons to the right of the address bar in the screenshot below. The gray button is to share pages in Facebook, Twitter or LinkedIn. The second button that looks like a Tootsie Pop is actually Comodo’s Site Inspector. The icons can be hidden but the backend functions cannot be removed like a plugin or extension. From reading around, it seems that Site Inspector didn’t work in incognito mode with previous Dragon versions. Now it does. There also were issues with theming Dragon in versions 19.0 and 19.1. These were fixed too.

First Impression

The familiar menus are all familiar. In the settings tab are the options to start Dragon in incognito mode by default, disable referrers and switch on or off Comodo’s Secure DNS settings. In Content Settings, you can select to delete the browsing history on exit. Instant and omnibox pre-rendering are disabled by default.

Dragon doesn't have a PDF viewer but can use Chrome’s pdf.dll just fine. Dragon supplies OGG and Theora decoding for HTML5 media support instead of the H.264 found in Chrome. As with Iron, Dragon doesn’t come with Native Client while Chrome and Chromium do. Google Search is the default and you get Bing and Yahoo preloaded but of course that can be changed.

Last but not least, Dragon uses Google’s Omaha updater which is still called Google Update in dragon:plugins. I found this ironic since the ever-present GoogleUpdate.exe process was one of the things Chrome’s privacy critics were most vocal about. Dragon’s updater runs in the background as a system owned process (Google’s updater is user owned) and auto-updating Dragon can be disabled. At that point, the updater will still run in the background but it will only give you a notification for an available Dragon update.

Packet Sniffing the Dragon

I made sure to get in some long nanny time with Dragon on both Windows XP and 7 while using Netstat and Emsisoft Online Armor to see what Dragon was doing. In total, nearly 40 hours of Dragon’s traffic was logged over about 3 weeks. Dragon was left open for anywhere from 1 to 8 hours to see what connections it would make. No websites were visited during these capture times, I was only looking for traffic originating from the browser without user input. TCP and DNS traffic were focused on when reviewing the Wireshark logs.

During installation, the dragon.exe binary flashes by quickly in the installer window with the flag --register-dragon-browser. Wireshark showed some brief information sent to I did 7 different Dragon installs and this activation information was the same in all of them. There were timestamps, Dragon’s version, the operating system and CPU architecture (32 or 64 bit).

Dragon behaved almost identical to its Chromium-based peers but a general trend I noticed was that Chromium and Iron aren’t as talkative in comparison to Chrome and Dragon. Each new browser session begins with a TLS encrypted Client/Server Hello with Google and can repeat several times throughout a session. Dragon’s connections were mainly to Google or Comodo and those which were not were instead to Thawte, Verisign and other TLS certificate authorities.

Dragon often established keep-alive connections (some over https) to Google which is normal for Chromium-based browsers. If Safebrowsing was enabled, those updates ran every 30 minutes and I even logged the actual Dragon update from version 19.2 to 20.0. Extension blacklists, the dictionary download and crx updates made up the remainder of observable traffic. Again, normal behavior for Chromium-based browsers. Oh, and despite Dragon’s ability to share pages in social networks, there were no connections made to anything related to those sites. Same goes for Comodo’s Site Inspector.

There was only one major difference which came up. With Chrome, Chromium and Iron, there were reliable times when the browsers had no open connections at all. When left idling, it didn’t take long for them to show no connection activity, no keep-alive sessions and nothing hanging open on the browser’s end. They had found their place of nirvana. Dragon seemed to lack the chi to reach this inner peace.

In XP, Dragon nearly always had at least one open connection to a Google 1e100 server through port 443. Sometimes it was port 80, other times multiple connections from both ports but always to a IP address. In Windows 7, Dragon’s updater kept 2 connections to 2 different IP addresses in CLOSE_WAIT status at all times. This means that Comodo’s server had issued its FIN packets, closing the connections on the its side, but Windows was still waiting for Dragon to close the local connections. This is an issue with Dragon in Windows 7 and I didn't see it happen in XP. During these keep-alive connections, nothing interesting is sent anywhere but the fact that they are hanging open is likely a bug.

Dragon’s Secret Sauce

Comodo CertSentry is included in Dragon. It is not part of Dragon’s code base but rather CertSentry is an extra program that Comodo plans to also supply with it’s internet security bundle and maybe somehow work into IceDragon, their new Firefox fork. Information on CertSentry is minimal at best and after extensively searching the depths of the common interwebz, the only place I found any definition was a thread on Comodo’s forums. You must register to view it but I've mirrored the important parts on a tSc page.

Here is what you need to know about CertSentry and TLS certificates for now. If a web browser set to check for SSL/TLS certificate revocation, then each time you connect to an https website, the browser checks the validity of that site’s certificate to confirm it’s not expired or fake. This is done usually by one of two methods: a certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP).

CRL works similar to how an extension blacklist works. Frequently the browser receives lists of invalid TLS certificates from the certificate authorities (CAs), the companies who actually issue the certificates. The serial number of the certificate owned by the website you want to access is checked against the bad serial numbers on the revocation list. If you’re going to a site with an invalid or undetermined TLS certificate, the browser warns about it.

OCSP is more realtime in that instead of constantly downloading and consulting blacklists, your browser asks the certificate authority directly if the site's certificate is valid or not. This happens as you’re accessing the website. OCSP is generally superior to CRL but both methods are not perfect and it’s a recurring theme lately that SSL/TLS is "broken" because forged certificates can be still bypass verification with a little bit of effort. This blog is a good place to read more about OCSP and CRL differences.

A TLS certificate which fails a validation check doesn’t automatically mean !YOU SHALL NOT PASS! You see a warning and can still proceed to the website if you choose. This is the soft fail method which is standard on the major browsers, although Firefox has a setting to enable a hard fail which basically blocks the site.

Comodo believes that the remaining browsers should include a selectable hard fail setting for invalid TLS certificates but for various reasons, they’re finding little cooperation from browser vendors. This is where CertSentry comes in. CertSentry sets Comodo as Windows' default TLS certificate revocation provider so Comodo then handles TLS revocation for the major programs in Windows. From the super secret Comodo forum page:

Once installed, CertSentry is invoked whenever you run any application that uses the standard Microsoft CryptoAPI functions to perform revocation checks. Such applications include Dragon, Chrome (for now, at least!), Internet Explorer, Outlook, etc.

CertSentry is set by default to a soft setting so that you are not barred from every page which fails the validation check. If you wish to set CertSentry to hard fail, you must make a Windows registry edit. For the exact entries, see the mirrored CertSentry info or register on Comodo's forums.

Two Observations

Setting plugins as click-to-play is a good idea regardless of your browser, but it works slightly differently in Dragon than other Chromium-based browsers. Normally, you would click the gray plugin window to activate that plugin but in Dragon, you must right-click on a blank white area where the plugin window would be and tell it to allow that plugin. The interface presented to the user is different and I’m not sure if this is a glitch, but it has been listed in the bug reporting area of Dragon’s subforum for over a year.

Here is Dragon’s user agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11 Comodo_Dragon/

If you want to blend in better with other web traffic, you should remove the Comodo_Dragon/* part at the end. This leaves you with a regular Google Chrome user agent string. Another reason to do this is if you have trouble with websites not working properly and on Comodo’s forum there was a case where a banking site wouldn't allow the person to log in. Removing the Dragon-specific part of the user agent solved the problem.

The Final Word

I confess that I am surprised to see Dragon is now more than a mildly rebranded Chromium. Hard-wiring Dragon’s settings tab for some command line switches was a clever idea. Makes me wonder why SRWare never thought up anything like this for Iron, but 'tis their infinite folly.

Obviously the most significant, if not simply the most interesting thing that Dragon brings to the table, is CertSentry. However, though bundled with Dragon, CertSentry is a separate product. There is no reliance of one on the other. Google Chrome will even work with CertSentry but the only way to get it at this point in time is by installing Dragon. If you uninstall Dragon, CertSentry is removed too and it’s actually still in beta phase but Comodo has "big plans" for CertSentry so time will tell where it goes from here.

So where do we stand? Well, with Comodo’s claim that Dragon is more private than Chromium—no, it’s the same. Slightly easier access to a few options is superior convenience, not superior privacy. In fact, you could make the case that Dragon has worse privacy than Chromium because while both browsers contact Google servers, Dragon additionally contacts Comodo.

How about when compared to Chrome, then? Well, as pointed out in my first Chromium article, all but two of the original privacy concerns in Chrome have either been eliminated or are opt-in/opt-out via the settings tab. Of those two remaining things in Chrome, Google's Omaha updater is one, followed by the installation ID. Dragon doesn't have an installation ID, so it takes a point there against Chrome.

That leaves us with the updater. Omaha is one open source component of Chrome and you can view the code here. If you trust/assume that Google uses Omaha's code exactly as they present it and that their compilers are secure, then Dragon's updater would be a minus since it's Omaha, obviously modified by Comodo for Dragon's needs. It is also not re-released under an OSS license (and from there, we would then need to trust/assume that what Comodo presents is exactly what Dragon uses). So under the trusting presumption, Chrome has an open-source updater whereas Dragon does not.

In closing, no installation ID—that's it for Dragon's privacy advantages compared to Chrome. Kinda anti-climatic, don’t you think? But the security side of Dragon presents a stronger argument because you get Comodo’s DNS, the Site Inspector and CertSentry. So if you’re choosing Dragon because you think it will stop contact with 1e100 addresses, it won't. But Dragon could be more likely to steer you away from malicious websites.

From here, I’m done. Deciding which, if any, Chromium-based browser should be yours is up to you. Enjoy. Just remember, don’t concentrate on the browser or you will miss all the internet’s glory.

Share this page.


The exact browser versions used were Dragon and 20.0 in Windows XP Home SP3 and Windows 7 Professional SP1.