Microsoft has never been a slacker in the C++ department – they’ve always worked hard to provide a top-notch, compliant product. Visual Studio 10 supports their current incarnation, and for the most part it is up to their usual standards. It’s a great development environment, and I am a dedicated user, but I have to give Microsoft a demerit in one area: their C++11 hash containers have some serious performance problems – so much that the Debug versions of the containers may well be unusable in your application.

Background

I first noticed the problem with unordered_map when I was working on the the code for my updated LZW article. I found that when running in the debugger, my program would hang after exiting the compression routine. A little debugging showed that the destructor for my hash table was taking a long time to run. And by a long time, I mean it was approaching an hour!.

This seemed pretty crazy. Destroying a hash table wouldn’t seem to be a complicated task. I decided to see if I could come up with a reasonable benchmark. I wrote a test program that does a simple word frequency count. As a starter data set, I used the first one million white space delimited words in the 2010 CIA factbook, as published by Project Gutenberg. This data set yields 74,208 unique tokens.

I wrote a simple test rig that I used to test the word count program using four different containers:

• unordered_map indexed by std::string
• unordered_map indexed by std::string *
• map indexed by std::string
• map indexed by std::string *

The reason for testing with std::string * was to reduce the cost of copying strings into the hash table as it was filled, and then to reduce the cost of destroying those strings when the table was destroyed.

I ran tests against map expecting to see a pretty big difference in performance. Because map is normally implemented using a balanced binary tree structure, it has O(log(N)) performance on insertions. A sparsely populated hash table can have O(1) performance. By using fairly large data sets, I expected to see a big difference between the two.

I tried to eliminate a few obvious sources for error in my test function – and I used a template function so that I could use the same code on all the different container types:

template<class CONTAINER, class DATA>
void test( const DATA &data, const char *test_name )
{
  std::cout << "Testing container: " << test_name << std::endl;

#ifdef _DEBUG
  const int passes = 2;
#else
  const int passes = 10;
#endif
  double fill_times = 0;
  double delete_times = 0;
  size_t entries;
  for ( int i = 0 ; i < passes ; i++ ) {
    CONTAINER *container = new CONTAINER();
    std::cout << "Filling... " << std::flush;
    clock_t t0 = clock();
    for ( auto ii = data.begin() ; ii != data.end() ; ii++ )
      (*container)[*ii]++;
    double span = double(clock() - t0)/CLOCKS_PER_SEC;
    fill_times += span;
    entries = container->size();
    std::cout << " " << span << " Deleting... " << std::flush;
    t0 = clock();
    delete container;
    span = double(clock() - t0)/CLOCKS_PER_SEC;
    delete_times += span;
    std::cout << span << " " << std::endl;
  }
  std::cout << "Entries: " << entries
            << ", Fill time: " << (fill_times/passes)
            << ", Delete time: " << (delete_times/passes)
            << std::endl;
}

I didn’t go overboard when it came to instrumenting this problem, I just used the timing functions built into the C++ library. On my Windows and Linux test systems, the values of CLOCKS_PER_SEC are both high enough that I’m not worried about granularity issues.

The First Results

I ran my test program in Visual C++ Release mode, using all the standard settings for a console application. For purposes of comparison, I ran the same program using g++ 4.6.1 on the same computer, booted up under Linux. For the set of 1,000,000 tokens, the results are shown below:

There are a few interesting points to take away from these tests:

• Microsoft’s compiler is taking an exceptionally long time to destroy hashed containers – one order of magnitude greater than it took to create it, and two orders of magnitude greater than it takes g++ to do the same task.
• It doesn’t look like constructing and destroying the strings is a big factor. Both compilers have roughly the same performance with both std::string and std::string *. Microsoft’s behavior is counterintuitive, as it takes longer to construct and destroy containers using the pointer.
• The GNU compiler appears to be able to run through this exercise notably faster.

The time it takes to destroy the table is a concern – having a C++ program hang for over 3 seconds to destroy a modestly large data structure is a serious concern – particularly when the same task completes in a few milliseconds with g++.

The Pathological Results

These concerns are nothing compared to what I see when running in debug mode. Setting my Visual Studio project to Debug mode, then running the same test, yields the results shown here:

Those numbers are hard to believe. Destroying a hash table takes one millisecond when using g++. In VC++ 10, it takes almost ten minutes!

Worse, we suddenly see that hashed containers are slower than the containers built on red-black trees. Again, this just doesn’t make sense.

The big problem with these numbers is that it means the debug mode of the compiler is effectively unusable for a lot of tasks. Regardless of how much testing it does, when it is this slow, it is just not useful.

A Workaround

I didn’t invest the time to try debugging Microsoft’s library, so I don’t really know where the time is being spent. I did try a few things to speed things up, and I found one technique that helps a lot. Before including any Microsoft header files, try entering this single line in your source:

#define ITERATOR_DEBUG_LEVEL 0

With this definition in place, the delete times return to ball park of the times seen when running in release mode. Of course, you give up some debugging. I believe that an explanation of what this macro does might be found here.

In the final analysis, I think Microsoft has some serious work to to do here. The performance of their hashed containers, and to some lesser extent, the pre-C++11 associative containers, needs some serious examination. If the library is going to run this much slower than the competition, I need a good explanation why.

Source

HashTest.cpp

Getting a new computer can be interesting. My recent purchase of a Dell XPS notebook came with a few problems that I didn’t anticipate, including:

• The video hardware is not properly supported under Linux – my fault for not checking up on this.
• The backlit keyboard is an ergonomic catastrophe. When viewed under bright light, the translucent legends on light brown keycaps literally disappear. I got Dell to replace this with a non-backlit keyboard, problem solved.
• The traditional numeric keypad control keys, including arrows, Page Up/Down, Delete, and Home, have all been reduced in size and moved to random new locations. Since the notebook I bought is the size of a small car there was really no good reason for this, and it will probably take six months for my fingers to get used to the new locations.
• Under Windows, the Bluetooth driver has some sort of glitch that causes Word to crash – go figure that one out. This was resolved by disabling an addin that I wasn’t likely to ever use anyway.
• Under Linux the Bluetooth driver makes my wireless mouse nearly unusable. However, turning off Bluetooth also turns off wireless networking. I feel like there is a solution to this out there somewhere, I just have to find it.

None of these problems are going to ruin my life, but they definitely contributed to a small feeling of buyer’s remorse which I am still trying to shake off.

Phone capture of the backlit keyboard under direct overhead light – the key legends do a nice disappearing act

It’s not all glitches and pain though, there is some levity as well. Check out the message the BIOS produces on an attempt to start up on a non-bootable device:

The BIOS message seen on a boot failure

Yep, my Operation System was not found.

For most of the thirty-some years that I’ve been paid to program, I’ve worked with Assembly language, C, or C++. There have been some diversions to Java, which is pretty painless for a C++ programmer, and always the odd short job or two in anything from Perl to Haskell.

But for the last three months or so I’ve been working full time on a short-timeline project that is using PHP as a general-purpose scripting language. So I’ve been working in this unfamiliar language at a fairly frantic pace, and I have to say that PHP, like Perl, is a strange place for a C programmer.

The Normal Problems

Any tutorial in a scripting language like PHP or Perl always makes a big deal out of Type Juggling, meaning that the type of a variable is inferred from the context in which it is used. In a simple example, a string literal can behave like an integer without any fuss, and vice versa:

{appliance:~} php -r '
> $a = 25;
> printf( strlen($a) . " " );
> printf( 15 + $a );
> printf( "\n" );'
2 40

Maybe it’s just me, but this aspect of PHP doesn’t seem to cause too much trouble. It may be because C and C++ already do implicit data conversions in a lot of situations; PHP just turns the dial up a notch or two.

What does give me a lot of trouble (and this is not exactly news) is that PHP doesn’t require declaration of variables, being perfectly content to create them on first use.

There’s of course nothing wrong with this, but as a C programmer, I have not developed any defensive skills in this area. A PHP programmer is much less likely to enter the following code, because he or she will be a lot more careful about entering variable names:

{appliance:~} php -r '
>$first = "Mark";
>$last = "Nelson";
>$name = $fist . " " . $last;
>print( "$name\n" );'
 Nelson

The good news on variable declaration is that I can jack up PHP’s error reporting so that these mistakes are flagged at runtime. Increased error reporting will also catch another error that plagues C++ programmers:

{appliance:~}php -r '
>$version = "1.2.3";
>print( version . "\n" );'
version

Yes, string literals are just as good without quotes as they are with.

This Week’s Puzzle

After a few months I start feeling a bit of a false sense of confidence in my understanding of the language, and naturally, I got some serious comeuppance this week, demonstrated by the following code:

{cslinux1:~} php -r '
>class base {
>  private $secret="42";
>  public function print_secret() {
>    printf( "$this->secret\n" );
>  }
>};
>class derived extends base {};
>$foo = new derived();
>$foo->secret="43";
>printf( $foo->secret . " " );
>$foo->print_secret();'
43 42

As a C++ programmer, I fully expect the attempt to modify $foo->secret to generate a runtime error. $secret is a private member, and as such I shouldn’t have access to it via the derived class. But the runtime happily makes the assignment.

When I actually print the value, I see that the base class and derived class print different values for $secret. What has happened here is that the assignment actually created a new data member in the derived class with the name $secret.

So what exactly is happening here? The reason for the difference in behavior is that PHP uses the private and protected modifiers to define not just accessiblity, but visibility as well. The $secret member in the base class is not only inaccessible outside of the base class, it is invisible as well.

That invisibility is the key to the behavior. When I try to assign a value to $this->secret, the runtime looks to see if the object of class derived already has a member called $secret. Since the member in the base class is invisible, the conclusion is that there is no member with that name, and as a result, a new variable is created on the fly: derived::$secret.

This can’t be fixed by simply amping up the error level, unfortunately, and it definitely is a problem for C++ or Java programmers. It doesn’t just cause me a lot of confusion, it just seems wrong.

Of course, there is plenty to like about developing in PHP, and it is definitely the right tool for this project. The speed bumps just make the process a lot more interesting. The concept of visibility set me back a few hours, but I’m ready to move on – until I hit the next bit conceptual roadblock.

Photo by Bob Brown

One of the oldest rules in print journalism is to get the reader’s attention with the lead, and to make your whole point in the first paragraph. Here goes: The storage of plaintext or encrypted passwords by any company that does business with the public is an act of stupidity. An act of stupidity so dangerous that it needs to be made illegal. Yes, we need federal laws banning the storage of passwords on more or less all IT systems in the world. The recent break-in of the Gawker user database makes this point more clearly than anything I can say, but that won’t stop me from trying.

Best Practices

Long ago, in the pre-PC days, I was a neophyte learning my way around the UNIX system my employer used for software development. It didn’t take long before I bumped into one of the more interesting files on the system: /etc/passwd. To my young eyes, it appeared that this file contained the encrypted passwords for all the users in the company. All I had to do was get my hands on the system software that managed logins, and I could quickly print out a complete list of credentials. Awesome!

Soon enough I learned my lesson. One of those bearded UNIX gurus was kind enough to take me aside and point out the obvious: /etc/passwd doesn’t contain encrypted passwords. It contains hashed passwords. Hashed and salted, in fact. Because of this, the original designers of UNIX were able to do what seemed like hubris to me: leave the password file with a mode value of 644 – available for anyone on the system to read.

Even though this was a best practice almost forty years ago, the Gawker debacle shows us that some people just don’t learn. Media empire Gakwer, host of dozens of popular web sites, had their internal database hacked. After much of the data was posted to public web sites, the truth came out. Gawker had over 1.25 million passwords stored in their database. Encrypted passwords, which they felt were quite safe. Safe, that is, until they showed up on the Pirate Bay’s lists of torrents.

Gawker was stupid – that much is obvious. Anything that is encrypted can be decrypted. That’s the nature of the algorithm, and that is why the passwords were stored that way. And if a password can be decrypted, you are just one security breach away from a bad actor having a plaintext password for every user on your system. If your passwords are hashed and salted, the bad actor can still get that list – but it should take at least a few decades.

But this kind of stupidity has the power to do much more damage than letting a script kiddy post comments on Lifehacker using my name. In today’s web, the average citizen who creates an account on a Gawker property such as Lifehacker, Gizmodo, or Fleshbot uses a password that is identical to the one they use on Amazon, eBay, PayPal, and their bank. So it’s pretty obvious what a black hat can do with that list of email address/password combinations – the economic damage can be stupendous.

That’s why we need to make the storage of encrypted passwords illegal.

Yes, Illegal

If it was just a matter of education, we could attack this problem in a sensible way. But the truth is, when it comes to security, the average IT person is an idiot, and the average user is an idiot. Just for example, my hosting service, Dreamhost.com, stores user passwords in their database. I’ve argued with them to no end about how stupid this is. But they’re content – the passwords are encrypted, and hardly anyone has access to them. They’ll happily go on in this mode until a disgruntled employee mails out the list, or the inevitable security breach leads to a mini-Gawker episode. And this is a company hosting close to a million domains. Just imagine how many startups out there have your credentials stored with no more protection than an XORed string in a database, and nothing but some caffeine-fueled PHP code protecting you from a SQL injection hack.

No, I think it’s time to acknowledge that my credentials belong to me, and they need the legal protection that my other properties enjoy. We need to to develop a new FIPS regulation regarding the storage of passwords, and then enact it as law – with hefty penalties. A Gawker-size breach should result in an instant fine on the order of tens of millions of dollars.

It’s Clear This is Needed

Like millions of people, I received the Gawker email shortly after passwords were posted:

Gawker Media to markn
12/13/10
This weekend we discovered that Gawker Media’s servers were compromised, resulting in a security breach at Lifehacker, Gizmodo, Gawker, Jezebel, io9, Jalopnik, Kotaku, Deadspin, and Fleshbot. As a result, the user name and password associated with your comment account were released on the internet. If you’re a commenter on any of our sites, you probably have several questions.
…

The site had a link to a FAQ which answered questions about the breach. The most important question thing to note about this FAQ is that months after the breakin, we still see a very bad entry:

11) What are you doing to ensure this doesn’t happen in the future?
We’re bringing in an independent security firm to improve security across our entire infrastructure. Additionally, we will continue to work with independent auditors to ensure we maintain a reliable level of security, as well as the processes necessary to ensure we maintain a safe environment for our commenters.

There is really only one good answer to this question: it should have read “We will never store passwords on our systems again – either in clear text, or encrypted. As this episode demonstrates, storing passwords is a worst practice. We were stupid once, but we are going to show the world that we have the capacity to learn. From now on, our passwords will be hashed and salted using the strongest possible algorithms available on our back end.”

What You Can Do

The obvious thing you need to do is to not use the same password on every site – this is a no-brainer. If you currently use fluffy99 as your password on Amazon, PayPal, eBay, and Poker Stars, you are vulnerable. Just make a small change in your algorithm. Instead of using fluffly99, simply append the first letter of the site to the password: Amazon gets fluffy99a, PayPal gets fluffy99p, etc. Use some easy-to-remember variation on this theme and you are immediately protected against the first wave of automatic attacks following a breach.

The second thing is to start shaming the morons. From time to time, go through a password recovery exercise on your favorite sites. If they offer to send you an email with a copy of your password, or to show it to you after you answer some security questions, you are dealing with Gawker-league stupidity. Call it out, publicly, loudly, and make sure you file a support case on it.

And finally, if you work in an organization that holds sway over Internet policy, take this call for legal action seriously. If you’re part of the EFF, or CERT, or the FCC, start pushing for this legislation – it’s the right thing.

Afterward

Calling for federal legislation in a blog post is clearly troll bait. For starters, the Internet user base has a fairly large number of people who lust for a global adoption of Anarcho-capitalism. In their view, any new government institution is a step in in the wrong direction. They will weigh in on this idea with some vigor, arguing that the problem can easily be handled with existing tort law. Additionally, they will point out that smart people (like them) are already immune to this problem, because they carry USB keys with a list of randomly generated 32 character passwords for every web site they use.

There will also be a large number of people who claim structural obstacles with the exclusive use of hashed passwords – the example being my Dreamhost captors.

Countering all of the objections they will raise in this post runs the risk of turning it into a manifesto, and that’s not my goal – I don’t get paid by the word. I will address the arguments as they come in. The structural and procedural arguments will all be wrong, and easily addressed. The philosophical arguments are more difficult, because winners and losers in those arguments are generally selected based on personal opinion, only slightly tempered with the facts. (And much of political argument starts off with name-calling and deteriorates from there.) But it’s safe to say I don’t agree with the idea that there are no good laws.

Maybe Gawker will be the last million-user password breach. I hope so. But somehow I doubt it. It’s kind of fun to think of the same type of breach happening at, say, Mint.com or Intuit. Now that will be a call to action!

Update

Since writing this, I received some useful clarification from a source who has worked with Gawker. Like most people, I was basing my information on Gawker’s security practices from their own statement:

Passwords in our database are encrypted (i.e., not stored in plain text),

As it turns out, this statement false. According to a post from Gawker, their user passwords were hashed using crypt(3), the same algorithm used by the bearded UNIX gurus I talked to over 30 years ago.

This means that Gawker was using a hashed, salted password. Unfortunately, they were using an algorithm that was considered to weak for any reasonable security as long as 20 years ago. Dictionary-based cracking programs on modern computers can break crypt(3) passwords with astonishing speed. That is apparently what happened to Gawker.

This doesn’t change the gist of the problem much – Gawker was still horribly negligent with user passwords. For whatever reasons they chose to use a security scheme that simply doesn’t pass muster. This could clearly have been prevented with a FIPS standard based on modern technology.

A Visit From Mr. Language Policeman

As an aside, is it reasonable to claim that Gawker misspoke when they said their passwords were encyrypted? It’s perhaps a fine point, but the Wikipedia definition of encryption says:

In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.

Clearly, the process of hashing passwords using crypt(3) does not meet this definition. You will sometimes hear people refer to this as one way encryption, but this usage doesn’t turn hashing into encryption.

These days I’ve turned over a lot of my life to Google – they have my email, a lot of my documents, and my primary phone number.

This is all great while it works, because in general it’s free, and the uptime is very reliable.

But if you are non-paying customer, when things break, you can find yourself in a world of trouble.

I use my Google Voice number as my primary phone number, and it rings my mobile, work, and home numbers. That’s a nice feature. In addition, I use it to receive texts, because I can send and receive them from both my Google Voice web page and my phone.

This morning I noticed that my texting traffic had strangely disappeared. A little checking showed that I could still send texts from my Google account, but it wasn’t receiving any. My cell phone could still send and receive properly, but nobody uses that number.

Generally my first debugging step on something like this is to search Twitter to see if this is a big problem. Maybe Google broke SMS for everyone, or some sizable portion of the population.

No such luck.

Now I found myself in free service hell. Something I depend on rather heavily stopped working, and I basically had no avenue for support.

As an unpaid Google Voice user, my only hope was to post a message on the appropriate forum. I wrote up a problem report, doing my best to provide as much detail as I could, but with not too much hope. If you browse through the forums you’ll see that the resolution rate for people’s problems is depressingly low.

As it happens, my story has a happy ending. Although I hadn’t done anything to my Google Voice settings, I remembered that this morning when I logged into gmail, Google asked if perhaps I would like to set up SMS password recovery for my account. Seemed like a good idea, so I gave them my Google voice number. I didn’t bother to try a test run – I have this feature set up on other accounts and it is drop dead simple.

But as it turns out, somewhere in the bowels of the Googleplex, adding that field to my account database broke some piece of code in Google Voice’s SMS reception code. When I changed the setting to point to my cell phone number, I instantly regained the ability to receive SMS messages on my Google Voice number. I have to believe this is a simple bug – I can’t think of any reason that using a Google Voice number for SMS password recovery should break it.

Of course, it appears that all the messages that were sent during my downtime were discarded, but I think I can recover from a few hours of SMS silence. If I hadn’t been fortunate enough to connect the dots and ferret out a fairly serious bug, there is no telling how long I would have waited to see a fix.

I might have even demanded a full refund.

Nobody likes getting ripped off, and I’m no exception. I search the web from time to time to see who’s copying my stuff, and it’s always a little disheartening.

This week I ran a check to see who was copying my 20-year old LZW Compression article. Mind you, I’m not talking about isolated quotes taken without attribution; for the most part I’m looking for people who have posted a wholesale copy of the article – a complete rip-off. Looking through the top 25 hits yields some interesting statistics:

• About 30% of the people who copy my work are University faculty. The assign the article as reading for a class, and instead of simply posting a link, they scrape the article off the web and post a private copy.
• Another 40% are people who are blatantly plagiarizing – they’ve incorporated my work into a paper or thesis. Unfortunately for them Google now crawls PDF and PostScript files, which makes detection pretty easy
• The remainder are blogging programmers who, for some reason, delight in taking my article and posting it on their site, reformatted and unattributed, but often with my name and contact information still intact

Taking Action

Finding these rip-off artists is easy, but getting the stolen material removed from the web is another matter. In the cases where I can clearly identify a person who owns the site, I usually start with a friendly email. Maybe 25% of the time this works, but the typical response is dead silence.

When the informal methods fail, the next step is the formal takedown notice. In the United States, web publishers enjoy protection from claims of copyright infringement under the Online Copyright Infringement Liability Limitation Act if they register a copyright agent who handles complaints, and if they respond to those complaints in a timely fashion.

This means that a site like Blogger.com, owned by Google, provides a formal mechanism for handling notices. When I can’t find a link to an abuse agent, I use the WHOIS database to find the hosting service, and send an email to their address. This generally works pretty well. For example, Scribd responded to my requests within a matter of hours, and generally assumes that my complaints are legitimate unless the poster of the material puts up a decent defense.

Things aren’t always so simple though. Just as an example, CiteSeer, a very popular database of academic publishing, has a cached copy of a stolen article that their crawler found. In their FAQ, under the question “How can I remove a copy of my article from your database?”, they give this unhelpful tidbit:

Papers within CiteSeerX corpus are crawled from the web. The only reason a papers of yours is in the CiteSeerX database is because it was/is available from the web.

No kidding. And this helps me remove your illegal copy how?

The Tough Cases

With enough perserverance, I’m usually able to remove a large percentage of the illegal copies. But some problems remain intractable. Overseas servers in countries where English is not widely spoken are particularly difficult. I could certainly sue Baidu.com in Federal Court, but I have a feeling that wouldn’t get me very far.

Even when I don’t succeed, there is some entertainment value in the excuses. Today I got an email from a gentleman in India who incorporated my work in a paper published in a peer-reviewed article. He told me that he would work on taking it out, but right now he is busy taking care of his mother, who is in poor health. He hopes I will be patient.

Patient I will remain. Not like I have a choice.

This isn’t the first time I’ve complained about innumeracy, and I’m sure it won’t be the last. Just to get off on the right foot, let me give the definition of the word from thesite innumeracy.com:

A term meant to convey a person’s inability to make sense of the numbers that run their lives. Innumeracy was coined by cognitive scientist Douglas R Hofstadter in one of his Metamagical Thema columns for Scientific American in the early nineteen eighties. Later that decade mathematician John Allen Paulos published the book Innumeracy. In it he includes the notion of chance as well to that of numbers.

The example of innumeracy found in this post is somewhat more interesting than most, because it comes from a source that really should know better: Discover Magazine.

In the July 2008 of Discover Magazine, I was reading an article titled Ocean Acidification: A Global Case of Osteoporosis, and saw this quote:

One such event occurred 55 million years ago at the so-called Paleocene-Eocene Thermal Maximum (PETM), when 4.5 million tons of greenhouse gases were released into the atmosphere.

Now, we’re supposedly talking about an event in which so much greenhouse gas was emitted that extraordinary climate change occurred. Is 4.5 million tons really a lot? Checking the Wikipedia article on greenhouse gas emissions gave this interesting quote:

According to a preliminary estimate by the Netherlands Environmental Assessment Agency, the largest national producer of CO2 emissions since 2006 has been China with an estimated annual production of about 6200 megatonnes. China is followed by the United States with about 5,800 megatonnes.

So the US and China produce 12 million billion tons of CO2 in a year, while the PETM produced 4.5 million tons. And the PETM was a major event that we are blowing away every year, year after year? Something is not right here.

Check the Source

Fortunately, Discover references the source of their information right on the web page, and quick check of the paper shows what the actual number is supposed to be:

Atmospheric temperatures inferred from surface ocean (references in Zachos et al. [2005]) and terrestrial (e.g., Wing et al. [2005]) proxies warmed by 5 – 9° C globally during the PETM. Warming was closely associated with the release of between ~1500 and 4500 Gt of carbon to the ocean and atmosphere, resulting in large but poorly quantified increases in atmospheric CO2 levels [Zachos et al., 2005].

Okay, so in my book, Gt means Gigatonne, and regardless of whether we are using English or Metric units, that’s going to be measured in billions, not millions of tons.

How did Discover take this number from the paper and mangle it by three orders of magnitude? We’ll never know. But avoid innumeracy, try to be aware of just how big the earth is, and realize that what seem like big numbers don’t always do it justice.

Slate has a regular piece called Explainer, subtitled “Answers to your questions about the news.”

A while back, they apparently lost their Explainer and asked for applications for a replacement. As part of the application, they requested that you submit a list of 10 sample questions to be explained.

Now, I have no real general journalism experience – most of what I’ve done is technical writing of one form or another. So I’m not a particularly good candidate for this position. But I thought I’d give it a shot. Here is the list of 10 sample questions I submitted on March 17, all based on topical news items:

Do banks report transactions under $10,000 to the feds?
Is Tibet an occupied country or a Autonomous Region of China?
Why do cranes collapse?
How do you get this free money from the Fed?
What’s so bad about a weak dollar?
Who are the superdelegates and what are their superpowers?
Am I required to put my hand over my heart when the National Anthem is playing?
Is Scientology a religion?
What’s so bad about melting glaciers?
Is pancreatic cancer deadly or not?

Well, I didn’t get the job, and of course, I didn’t get a response, but today I see this article in Slate Explainer: Why Do Cranes Fall Down?.

I guess the reason I didn’t get the job was that I only had one article worth ripping off. If there had been five or six, I’d be explaining away at Slate as we speak!

Apple is in the middle of a minor fuss right now over their use of software updates as a promotional device. It turns out that if you are a Windows user with a copy of iTunes, Apple’s update process does its best to get you to install a copy of their web browser, Safari, along with whatever you need to keep your iPod humming along properly:

Of course, it’s not particularly unusual for companies like Google, Adobe, and Apple to try to sneak their software onto your system using somewhat deceptive practices. Last time I checked up on my Dad’s PC his browser had Google Toolbar, Yahoo Toolbar,  AOL Toolbar, and a Toolbar from his ISP. The actual browser window was a miserable little ribbon a few hundred pixels high. Dad had no idea how the toolbars got installed, but I have no doubt they were all stealthily piggybacked on one piece of software or another.

But Mozilla CEO John Lilly seems to think this use of the update feature to promote a web browser goes beyond aggressive marketing and into the depths of evil. His angry blog post basically says that using an update/patch service to load new software violates some sort of basic compact between users and providers:

It’s wrong because it undermines the trust that we’re all trying to build with users. Because it means that an update isn’t just an update, but is maybe something more. Because it ultimately undermines the safety of users on the web by eroding that relationship. It’s a bad practice and should stop. 

John goes on to say that he doesn’t condemn the common practice of using installed software to push your other products – he seems to be saying that the update program is a special case.

Things get really interesting when you start reading the comments to his post. As is often the case with All Things Apple, the issue seems to have caused extreme polarization.  A selection of anti-Apple comments include:

This is disgraceful. It fails the user in favor of serving Apple. It is, in fact, malware-level tactics. 

This is just a sick way of tricking users to download their browser by making it seem as if an update if available for a piece of software already installed. I bet it even takes over as the default browser afterwards, which would look very bad on Apple.

Right on, John Lily. “Update” means “update,” not “Give me your other products.”

But predictably, the Apple apologists insist that Cupertino can do no wrong:

You Windows users are not only paranoid, but so anti-Apple that your comments are hysterical. This is the biggest NON-ISSUE yet – and anyone using a computer that can’t use that screen and make a good decision should go back to a typewriter. 

The consumer has already trusted Apple (or any company) by downloading one of their pieces of software already. There is already a placement of trust in Apple (or other company). If they trust Apple enough to install one of their apps, then extending that to another one of their programs seems to make sense to me.

Some of the complaints here are over the top. Pushing Safari with a iTunes update is “Malware”? Please. Sure, it’s marketing, but it is utterly benign, other than using a little disk space that is trivial by modern standards. … Compared to all the real malware issues faced by Windows users, this is not worth notice. And, most of all, compared to the execrable practices of Microsoft and other PC software vendors, this is a tempest in a teapot.

I think one thing we can agree on is that there are tens of millions of Windows users with iTunes installed, and the vast majority of them are going to be clueless about what Safari is and whether they should uncheck that radio box.Does this mean Apple is preying on the ignorant? Are they in fact somewhat evil? Or is this just the way the world works now?

Use the comment box to let me know what you think. Inquiring minds want to know.

(By the way, I should note that in the past I’ve always used Firefox on OS/X – Safari 2.0 was lame, unstable, your basic piece of crap. I’m writing this on Windows using Safari 3.1, which is surprisingly fast and seemingly bug free. Quite an improvement!)

American Express is so excited about having me as a customer that they were willing to pay me $5 to take part in a survey:

American Express Needs YOUR Feedback!

Dear American Express Blue Cardmember:

American Express would like your feedback. We would like you to participate in a survey about your Blue card from American Express. Your participation will provide us with valuable feedback and help us tailor card benefits to better meet your needs.

As a token of our appreciation, you will receive $5 from American Express*. Please note that this survey will be running for a limited period of time. To increase your chances of receiving the honorarium, please complete the survey at your earliest convenience.

The web address for the survey is shown below. To begin the survey, simply double-click on the address to go directly to the questionnaire. However, if you are unable to double-click on the address, please copy and paste the text below into your browser’s address bar.

Well, I need five bucks, and a little bit of checking gave me moderate insurance that this was really from American Express, not a phisher. The survey was being outsourced to Confirmit, a real company, and they don’t seem to be on any malware site lists. Furthermore, as things went on, there was an enormous amount of content in the survey and seemingly no payoff for phishers, so it seems unlikely that this is a scam.

However, right off the bat there was some cause for concern. Double-click on the address? How many browsers do you use that need a double-click before they follow a link? If Confirmit is a real company, they clearly didn’t assign their top copywriter to this project.

The real fun started when I actually started the survey. The classic “make a good first impression” rule that your mother taught you is just as true for web pages as it is for anything else. And the first page of the American Express survey was the equivalent of showing up for your first date with a big gravy blotch on your tie:

Yes, that’s right, the first thing I see is some inner workings they’ve inadvertently exposed. No doubt the URL I clicked was supposed to preload a survey question and zip me right past this. This question was undoubtedly in use to stage their testing of the survey, and was supposed to be removed in the published version. There’s a lesson in that.

From Bad to Worse

The rest of the survey only served to further tarnish my impressions of Amex’s IT outsourcing choice. After making it through a few innocuous questions, another page I wasn’t suppose to see popped up:

Apparently I was going to be be seeing ths particular error quite a few times:

Survey Hell

Finally I seem to have made my way through the setup questions. The progress bar showed 50%, and I detected that I was entering the first ring of survey hell. This is where the survey designer starts trying to milk you for a ton of information by repeatedly varying some scenario, then asking you a bunch of detailed questions about it. (This is sheer idiocy on their part. Once they start trying to find the correct adjectives for how a particular ad makes me feel about the product/company, it’s over.)

In this case AmEx had a list of perhaps 15 benefits that their card offers. They started tossing them up in various combinations on the screen, and in each case asking me on a scale of 1-10 how that made me feel about the card. They then tried to quantify the results by asking me how much more I would put on my card each month given that benefit. (Again, totally moronic. No data retrieved this way could possibly have any value.)

This would all be great if their page actually worked. In this case, I’ve told them that I put a tidy $5,000 on the card each month, and they want to see how much I’m going to bump that up if someone comes to my house to give me a back rub. (No joke!) Just to see what would happen, I put down a lower number, and got this nifty error message:

It turns out the only way I could get past this page was by putting in 1, yes $1. But that’s okay, because at this point there’s obviously no reason to cooperate with the tragically broken survey.

Unending Hell

AmEx then applied the coup de grâce by inserting a fiendish logic error in the survey. I started looping through various permutations of three possible card benefits, over and over, for each one picking a number from 1-10 and then assigning it a cash value. I realized that the progress bar at the top of the page was actually moving back to 50% after each answer! In other words, I was stuck in the survey forever. They had a bug that prevented them from exiting the loop.

Nicely done, Amex!

So I bailed. In theory I can come back in a day or two and finish. Perhaps they will have fixed things up by then. More likely they will have fired Confirmit. Will I get my $5? It doesn’t seem likely. AmEx put the fix in here as well, by breaking the payment page. As you can see here, I’ve entered data in all the fields, but the survey software refuses to accept it, somehow thinking I’ve left something blank. This is a big PR win for Amex, putting people through a 20 minute broken survey, then refusing to pay!

Moral

The moral of the story is obvious. If you’re going to send an email out to thousands of customers, all of whom are most likely uninformed civilians, it would be a good idea to thoroughly test your product first. The fact that Confirmit clearly didn’t do that is a nail in their coffin, considering this is their livelihood. The fact that AmEx hired this joke of a company doesn’t say much for them, either.

Priceless Web Design:

• Designing a survey for your customer base? $10,000
• Deploying the survey and passing out rewards? $25,000
• Making yourself look like an incompetent pack of rubes for the whole Web to see? Priceless.