Correcting a few misconceptions

(I speak on behalf of Adam Smith and free market economic ideas alone in this post.)

In a recent blog post, Gen Kanai, in discussing the EU browser ballot, at one point opines that South Korea’s monopoly browser market is a consequence of a free market. (I derive this from the first sentence of his second paragraph, in which I interpret, “To those critics of the browser ballot [supporting a free market through the invisible hand], I would present to you the example of South Korea”, as saying South Korea’s situation is a negative consequence of the invisible hand. It seems to me that either this interpretation is correct, or presenting the example would be a non sequitur.) Specifically, by his words he deems South Korea’s situation a consequence of “Adam Smith’s invisible hand” (link in original). This doesn’t seem to me to be the case, and I would like to correct a few mistaken assumptions implicit behind his assertion.

Did Adam Smith’s invisible hand approve of monopolies?

Through specific invocation of Adam Smith it is implied that, in his support of a free market, his acceptance of laissez-faire economics also means he would have condoned monopolies. This is not the case. Adam Smith was certainly no fan of monopolies, and his magnum opus, The Wealth of Nations, repeatedly noted the bad outcomes engendered by monopoly.

Europe, however, has hitherto derived much less advantage from its commerce with the East Indies than from that with America. The Portuguese monopolized the East India trade to themselves for about a century, and it was only indirectly and through them that the other nations of Europe could either send out or receive any goods from that country.

Smith goes on in subsequent sentences to explain that the exclusion of other countries, and the widespread use of nationally-chartered companies such as the East India Company to only permit exclusive access to the East Indies, made trade with America of greater overall importance than trade with East India — this notwithstanding the greater sophistication of potential trading partners in the East Indies, capable of supplying more value than “savages and barbarians” of the New World. This is hardly acceptance of monopoly. One might also consider this later statement impugning monopolies:

Country gentlemen and farmers are, to their great honour, of all people, the least subject to the wretched spirit of monopoly.

True, Smith permitted the possibility of monopoly in the case of two narrow exceptions: with respect to industries where a national defense interest might come into play (see Book IV, Chapter 2), and with respect to an industry resulting from “a dangerous and expensive experiment” such as autonomous colonization and fortification (see Book V, Chapter 1). These exceptions, however, certainly do not swallow the rule. It is simply inaccurate to say that Adam Smith’s support of a free market implies support of monopolies. (In any case, while Adam Smith’s The Wealth of Nations may have been a seminal work of free-market theory, it is not its highest point, its ne plus ultra, but merely its starting point.)

(With respect to the particular situation of South Korea and encryption, it’s plausible a national security interest was an initial factor in the development and use of a proprietary algorithm. Such an interest seems highly ephemeral given the development of widely used standards a short time later, however, so Smith’s acceptance of this particular monopoly on that basis would have been fleeting at best.)

Is the browser market in South Korea the consequence of a free market?

I freely admit that I am mostly uninformed on this topic; my knowledge comes primarily from Gen Kanai’s first post on the cost of monoculture in South Korea’s browser market. If I have misconstrued the narrative given in that post, I welcome correction.

Quoting from that post:

The history goes back to 1998, when the 128 bit SSL protocol was still not finalized (it was finalized by the IETF as RFC 2246 in Jan. ‘99.) South Korean legislation did not allow 40 bit encryption for online transactions (and Bill Clinton did not allow for the export of 128 bit encryption until December 1999) and the demand for 128 bit encryption was so great that the South Korean government funded (via the Korean Information Security Agency) a block cipher called SEED. SEED is, of course, used nowhere else except South Korea, because every other nation waited for the 128 bit SSL protocol to be finalized (and exported from the US) and have standardized on that.

In the early years of SEED, users downloaded the SEED plugin to their IE or Netscape browsers, either an Active X control or a NSplugin, which was then tied to a certificate issued by a Korean government certificate authority. Can you see where this is going?) When Netscape lost the browser war, the NSplugin fell out of use and for years, S. Korean users have only had an Active X control with the SEED cipher to do their online banking or commerce or government.

Gen Kanai, the cost of monoculture (with KISA link updated)

SEED, then, was the direct result of government funding of encryption and protocol research. The two (later one) SEED plugins used to implement client-side support for the protocol and encryption were part of a package provided exclusively by the government, as Gen Kanai says in a comment on that post:

Each Korean citizen is issued a nation ID number. This is embedded into the certificate issued by the Korean CA. Thus non-Koreans in Korea (such as US military in Korea) cannot make secure transactions like online banking or online commerce. The ‘package’ (including SEED, the national ID, and the Active-X cert.) that the CA’s distribute is Active-X based, and thus only works in Windows and IE.

Assuming the above is true, I’m not sure how the free market was responsible for the establishment of Microsoft’s monopoly on being able to provide browsers supporting South Korean encryption. The South Korean government brought about the single-protocol monopoly there through its funding of SEED and its ubiquitous use in governmental settings. It alone provided the packages implementing SEED in browsers. The result may be a Microsoft monopoly (if one partially due to a global decline in Netscape market share), but it seems one sanctioned by the Korean government. As Gen Kanai later notes,

Korea will only get beyond this problem by 1) applying Korean laws on open standards to the certificate authorities, 2) reassigning new certificates which work with open web standards to all Koreans, 3) reprogramming all Korean websites to support 128 bit SSL which will allow for a heterogeneous marketplace of operating systems and web browsers.

The third component of the solution requires actions by private entities, but the first and second components require governmental action. Indeed, they are direct steps to overcome previous governmental missteps, and the third component arguably doesn’t make sense except in anticipation of the first two occurring imminently. In what way did the invisible hand, or free markets, bring about South Korea’s encryption monoculture and monopoly? True, Netscape’s declining market share turned a duopoly into a monopoly — but the Korean government chose not to offer plugins for other browsers after that point (and indeed had not offered any for Internet Explorer on Windows Vista, either). Did the problem truly lie with the free market, or did it lie with the Korean government? Whose action brought about the monopoly? Whose inaction sustains it? Whose action is necessary to move toward proper competition?

It also seems worth noting that, later in Gen Kanai’s recent post, he mentions that until recently South Korea required Korean-specific hardware in smartphones. Further, South Korean government guidelines and regulations still require SEED encryption and signing for financial transactions, perpetuating SEED’s monopoly in phone browsers. These governmental restrictions on the cell phone market simply further show how governmental interference in South Korea has impacted Koreans for the worse.

A return to Adam Smith

That the Korean monopoly is the result of government action is particularly important when considering what views Adam Smith might have had of it. While Smith disdained monopolies, he particularly disdained government-created monopolies such as the East India monopolies noted previously. He writes:

The legislature…ought…to be particularly careful neither to establish any new monopolies…nor to extend further those which are already established.

It seems clear that Adam Smith would have been doubly suspicious of government-created monopolies of the sort present in South Korea, precisely because they are government-created.

A brief note on choice and browsers

None of this is to say that choice, or browser choice in particular, is bad — it’s good, precisely for reasons demonstrated by South Korea! However, South Korea’s experience doesn’t really seem to demonstrate a free market-induced shortcoming which might add support for a non-free-market action like a browser ballot. Neither the legitimacy nor the illegitimacy of a browser ballot is increased by reference to the history of encryption protocols and browsers in South Korea, even if South Korea emphatically demonstrates the ills of monopolies.


Brief talk on ES5 and Mozilla support for it

Tags: , , , , , , — Jeff @ 12:32

I gave a three-minute not-actually-lightning-talk-but-let’s-call-it-that-anyway on ECMA-262 5th edition, what’s in it, and the state of Mozilla’s support for it at the Mozilla weekly meeting this week. It’s probably old hat if you’ve been following the standard closely, but if you haven’t it gives a short and sweet overview of what’s new; there’s a three-minute video of the actual talk on the meeting page (start at around 7:00 into the complete video). If you’re strapped for time, view the slides and turn off stylesheets (View > Page Style > No Style in Firefox) to see notes on what roughly accompanied each slide.



Tags: , , , , — Jeff @ 21:52

(Image attribution: File:Fig.jpg by Fir0002, used under CC-BY-SA)

(I am aware this is almost hopelessly esoteric. I’ll say as a hint that p.m.o readers stand a far better-than-average chance of understanding this; the subset of those readers who are active web developers have an even better chance yet; and the subset of those who have been active since, oh, 19:13 PST today have the best chance of all. If you don’t get it [and who would blame you? :-) ], I’ll explain fully in the first comment.)



A glory, an optical phenomenon in which a circular rainbow appears on a background of water droplets when the sun is directly behind the observer
Glory and cloud horizon
Glory and cloud horizon
Glory and tip of plane wing
Glory and tip of plane wing
The glory, part of the plane wing, framed at bottom by the airplane window
A little further zoomed out
The glory and the plane wing, as the plane shadow begins to be visible
The glory and the plane wing, as the plane shadow begins to be visible
The glory just beneath the furthest hydraulic motor on the wing, with a brilliant blue sky above
The best of the glory pictures
The glory just underneath the wing, with the plane's shadow now unmistakable
After further descent the plane's shadow is now unmistakable
The glory, seen during mostly level flying (original video)
The glory and airplane shadow, seen during descent into the clouds (original video)

…all taken in the waning minutes of my flight from BOSMSP yesterday, returning from MIT‘s Mystery Hunt to the Bay Area (following a long stretch of working and hacking on Mozilla remotely in areas which, in contrast to the Bay Area, have proper winter climes).

For more of this sort of thing, I highly recommend watching the famous “rainbow lecture” given by MIT’s Walter Lewin, the professor under whom I had the pleasure of taking 8.03. And yes, Walter Lewin is my homeboy.


More ES5 backwards-incompatible changes: regular expressions now evaluate to a new object, not the same object, each time they’re encountered

(preemptive clarification: coming in Firefox 3.7 and not Firefox 3.6, which is to say, a good half year away from now rather than Real Soon Now)

Disjunction: is /foo/ the same object, or a new object, each time it’s evaluated in ES3?

According to ECMA-262 3rd edition, what should this code print?

function getRegEx() { return /regex/; }
print("getRegEx() === getRegEx(): " + (getRegEx() === getRegEx()));

The answer depends upon this question: when a JavaScript regular expression literal is evaluated, does it create a new RegExp object each time, or does it evaluate to the exact same RegExp object each time it’s evaluated? Let’s look at a few examples and make a guess.

I sense a pattern

var tests =
   function getNull() { return null; },
   function getNumber() { return 1; },
   function getString() { return "a"; },
   function getBoolean() { return false; },
   function getObject() { return {}; },
   function getArray() { return []; },
   function getFunction() { return function f(){}; },

for (var i = 0, sz = tests.length; i < sz; i++)
  var t = tests[i];
  print(t.name + "() === " + t.name + "(): " + (t() === t()));

If you test that code, you’ll see that the first four results are true, and the rest are false, all per ECMA-262 3rd edition. (Okay, technically, and bizarrely, ES3 permitted either result for the function case, but no browser ever implemented a result of true; ES5 acknowledges reality and mandates that the result be false.) The first four functions return primitive values; the last three return objects. There’s only a single instance of any primitive value — or, alternately, you might say, equality doesn’t distinguish between different instances of the same primitive. Therefore it doesn’t really matter whether primitive literals evaluate to new instances or the same instance. On the other hand, objects compare equal only if they’re the same object. Since the object cases didn’t compare identically, they must be new objects each time. This makes sense: if this were not the case, what would happen in the following example?

function makePoint(x, y)
  var pt = {};
  pt.x = x;
  pt.y = y;
  return pt;

var pt1 = makePoint(1, 2);
var pt2 = makePoint(3, 4);

It would be complete nonsense if the object literal above evaluated to the same object every time it were encountered; the next two lines would blow away the previous point, and we would have pt1.x ===3 && pt1.y === 4.

Plausible assertion: regular expression literals evaluate to new objects when encountered?

Returning to the original question, then, what does ES3 say this code should print?

function getRegEx() { return /regex/; }
print("getRegEx() === getRegEx(): " + (getRegEx() === getRegEx()));

A regular expression is an object. If you don’t want to get weird property-poisoning of the sort just suggested, regular expression literals must evaluate to different objects each time they’re encountered, right?

Alternative: ES3 says /foo/ is the same object every time

Wrong. According to ES3, there’s only a single object for each regular expression literal that’s returned each time the literal is encountered:

A regular expression literal is an input element that is converted to a RegExp object (section 15.10) when it is scanned. The object is created before evaluation of the containing program or function begins. Evaluation of the literal produces a reference to that object; it does not create a new object.

ECMA-262, 3rd ed. 7.8.5 Regular Expression Literals

This was originally a dubious optimization in the standard to avoid the “costly” creation of a regular expression object every time a literal would be encountered. It’s perhaps a little surprising that the same object is returned each time, but does it make a difference in real programs not written to demonstrate the quirk? Often it doesn’t matter. As a simple example, if (/^\d+$/.test(str)) { /* ... */ } executes identically either way, assuming RegExp.prototype.test is unmodified. The RegExp never escapes, and its use doesn’t depend on mutable state, so creating new objects each time doesn’t make a difference (other than negligibly, in speed).

Sometimes, however, the shared-object misoptimization does matter meaningfully: when a RegExp with mutable state is used in ways that depend on that state. Most regular expressions don’t store any state, so if the same RegExp object is used twice it’s no big deal. However, it can matter a lot for regular expressions specified with the global flag:

var s = "abcddeeefffffgggggggghhhhhhhhhhhhh";
function next(s)
  var r = /(.)\1*/g;
  return r.lastIndex;

var r = [];
for (var i =0; i < 8; i++)
print(r.join(", "));

Each time a regular expression with the global flag is used, its lastIndex property is updated with the index of the location in the matched string where matching should resume when the regular expression is next used. Thus, in this example we have mutable state, and if next is called multiple times we have uses which will depend on that mutable state. Let’s see what happens in engines which implemented regular expression literals per ES3. If you download the Firefox 3.6 release candidate and test the above code in it (adjusting the implied print to alert), the printed result will be this:

1, 2, 3, 5, 8, 13, 21, 34

ES5: an escape to sanity

Is ES3’s behavior what you’d expect? No, it isn’t. In fact, ES3’s behavior, which Mozilla and SpiderMonkey implement, is the second-most duplicated bug filed against Mozilla’s JavaScript engine. SpiderMonkey and (strangely enough) v8 are the only notable JavaScript engines out there that implement ES3’s behavior. ES3’s behavior is rarely what web developers expect, and it doesn’t provide any real value, so ES5 is changing to the behavior you’d expect: evaluating a regular expression literal creates a new object every time.

Starting with Firefox 3.7, Firefox will implement what ES5 specifies. Download a Firefox nightly from nightly.mozilla.org and test it out as above (use the profile manager if you want to keep your current Firefox settings and install untouched). Instead of the Fibonacci sequence you’ll get this:

1, 1, 1, 1, 1, 1, 1, 1

The bottom line

Starting with Firefox 3.7, evaluating a regular expression literal like /foo/ will create a new RegExp object, just as evaluating {} or [] currently creates a new object or array. The optimization ES3 specified has resulted in clear developer confusion and was misguided and inconsistent with respect to other object literal syntax in JavaScript.

Again, as with my previous post, we doubt this change will affect many scripts (in this case, except for the better). The fact that few browsers implemented ES3’s semantics means that most sites have to cope with either choice of semantics, so the semantics in ES5, implemented by Mozilla for Firefox 3.7, are likely already handled. Still, it’s possible that this change might break some sites (particularly those which include browser-specific code), so we’re giving a heads-up as early as possible.

« NewerOlder »