> Civ, though, was using an offset-square map, which is no different than a hex map, so I think it only amounts to a different look plus a marketing spiel. What do you mean by that?

Civ Rev wasn't a port of Civ IV any more than Civ II was a port of Civ I. It was a completely different game, with different mechanics, graphics, civilizations, etc. It was definitely "dumbed down" compared to Civ IV, but it was not a port.

As I understand it the "Advanced" list is correct - it is the one that the application itself is enforcing (if you uncheck an option there, the application will not use the specified certificate for that purpose). The list of purposes under "view" is, I believe, the list of purposes declared by the certificate itself, as specified by whoever generated the certificate. You may choose to use it for a smaller list of purposes, which is what Chrome is doing wrt email (in the same way, Firefox only trusts the CNNIC cert for SSL, not for email or binary signing).

Why does there have be hysteresis to the process? That is, why does the burden of proof change once Mozilla has accepted the certificate? If you see how the process worked, it was basically the case that by the time it became relatively common knowledge that the CNNIC certificate was going be added, the time for comments had passed (not many people make the habit of trolling through Bugzilla entries or the Mozilla "RFC" page to find things they may want to comment on). If, once it became common knowledge, there were serious objections raised to adding the certificate - why not start the process again from scratch? Why force anyone to prove that CNNIC will violate the duties of a CA, especially given that these violations may be in the future? Furthermore, the whole discussion should be considered special given that the "great firewall" has apparently begun blocking most of the threads discussing the issue, such that open discussion isn't even possible since the very people who may be affected by this most (those within China) are being prevented from discussing it.

Not sure about Opera, but here is the resolution of the same issue for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=340198

This kind of vulnerability extends even to very commonly used applications. The firefox download, remarkably, does not occur over HTTPS, and yet that is the way in which you get your root certificates used by SSL. It is entirely possible for someone to intercept your download and return you a hacked version of firefox which contains malicious root certificates which would then could to sign any sort of phishing or other attack site, allowing spoofing of pretty much any website's identity.

Deflate doesn't work well on shortish strings because (a) it has some 11 or bytes of overhead you pay no matter what (b) you are no likely to find a lot of long-run duplication in short strings (c) the relative cost of including the huffman tree in the output is large, so it is likely that a less efficient static variation will be chosen.