The Hacker Factor Blog

My friend Bob G. recently told me about a column on page 12 of National Geographic Magazine's June 2010 issue. The column titled "Getting Real" is a rant about how a photographer supplied the magazine with a digitally altered photo. (A shorter version of the article is available online under the title "Your Shot Digital Manipulation".)

Basically, "photographer" William Lascelles submitted a photo to National Geographic and claimed that it was real. The magazine asked Lascelles to verify the photo, and he submitted a second fake photo. National Geographic then printed the image, only to learn that Lascelles lied to them twice; they were duped into printing a fake photo.

Whenever I post blog entries about photo manipulation, there is always someone who asks "what's the harm?" and "what about artistic freedom?" In this case, the harm directly impacts National Geographic's reputation. The photo contest is restricted to real photos for a reason: the magazine strives to use photos based on reality and not fake or doctored or modified situations that are fictitious.

In response to being duped, National Geographic published a full column identifying the fraud by William Lascelles and repeatedly naming him. The printed column also names another fake, by Dobrev and published in December 2009. This is more than just posting a small correction. This is a full outing.

Told You So

Like National Geographic, Smithsonian Magazine holds an annual photo contest. In March 2009, I wrote to the Smithsonian and informed them that some of their finalists used digital modifications that appeared to be outside the permitted amount of allowed manipulations. The Smithsonian responded a few days later. They had investigated the images and queried the photographers. In the end, three of the five modified photos were disqualified from the contest. The remaining two were determined to have an acceptable amount of digital modification.

I was thrilled with the Smithsonian's reply. They listened to the concern, investigated the situation, and took appropriate action.

I sent a similar letter to National Geographic on Tue, 24 Nov 2009 21:36:10 -0700. I had noticed that at least one of their contest submissions was digitally modified. Here's the reply they sent me:

Subject: Re: Digital Manipulation in the Photo Contest
To: "Dr. Neal Krawetz"
Sender: [redacted]@ngs.org
Date: Tue, 8 Dec 2009 13:48:19 -0500

Dear Dr. Neal Krawetz:

Thank you for contacting the National Geographic Society.

Your comments regarding photos submitted to the 2009 International Photo Contest are very much appreciated. While we provide information on photo manipulation and what is and is not accepted in the contest rules <http://ngm.nationalgeographic.com/photo-contest/manipulation>, all the photos in the contest are submitted by the individual photographers. We do not go through each one of them and remove them, even if we feel they have been manipulated. We simply do not have the time or staff to do that. You can view the winning photos on our website at http://ngm.nationalgeographic.com/photo-contest/past-winners

Best wishes,

[Name redacted]
National Geographic Society

That's right: National Geographic does not review each of the images that they accept for publication on their web pages, and they do not remove images that they know or believe are digitally modified. As seen with William Lascelles, their "verification" consists of asking the photographer -- who has already lied and won't mind lying again. I can understand that they don't have a big budget or staff for image analysis. However, this is their reputation. One would think that they would be interested in protecting it.

In the fraud exposure column, National Geographic wrote that they have changed their policy: "Now we're looking more closely at all Your Shot pictures." It's about time!

Frankly, if you are going to hold a photo contest and require original photos (not digitally altered), then you should take the time to verify every finalist. I'm not saying that you should police every submission. Rather, attempt to evaluate every finalist or semifinalist -- probably a dozen or so pictures. You usually don't even need special tools; a critical eye is usually good enough. If you don't have the time or resources to validate potential winners, then perhaps you shouldn't hold the contest.

And I'm sure that someone is going to ask "Where can they get my tools?" It isn't so much the tools as the training. If you are not trained to spot photo manipulation, then the best tools in the world won't help you. And as my friend Cynthia Baron has repeatedly demonstrated to me: people with the right training and experience can do this without any specialized tools.

Going Deeper

The dog picture by Lascelles is available online at http://s.ngm.com/your-shot/img/faked-blue-dog-615.jpg. Let's see what can be found with real image analysis...



Disclaimer
Please keep in mind: I'm not analyzing the original submission that National Geographic received. I'm analyzing a resave that National Geographic likely scaled for use on their web page. I seriously doubt that this is the original submission. In effect, I'm looking at a bad photocopy of the original submission. As with any bad photocopies, some results may be inaccurate due to artifacts introduced during the reproduction process and some evidence of modification may be completely wiped out. And more importantly: the original submission was fake, so it also includes modifications and artificial artifacts.

Photo Ballistics
Lascelles' file was saved as a JPEG and includes a JPEG APP12 section labeled "Ducky". (If you search for strings in the image, you will see "Ducky".) What is Ducky? It is a section added by Photoshop's "Save For Web" and includes the saved quality level. In this case, someone used Photoshop's Save For Web and selected 83% quality. (The "someone" was probably National Geographic.)

However, the quantization tables do not match the stated quality level. Instead, the Quantization tables match 94% compression. The discrepancy is due to the saved settings. Specifically, the last save used Save For Web with "JPEG", "Very High" and 83% quality. (The "Very High" setting selected the 94% quantization tables. Photoshop's quality level does not represent the quantization tables.)

Principal Component Analysis
PCA is great at identifying JPEG artifacts from resaves. These appear as rectangular blocks that are either 16x16, 16x8, 8x16, or 8x8. The more extreme the blocks, the lower the JPEG quality. High quality or original images should have very few visible artifacts.



In this case, the PCA shows severe blocking in the sky -- this is a low quality image from multiple resaves. But there is a problem... The blocks are not 8x8; they are smaller. In this case, the big squares appear to be 7x7 and small squares appear to be about 3x3. This means that the image was low quality and then scaled smaller. (I wouldn't be surprised if National Geographic scaled the final image for presenting on their web page.) The final image is probably about 40% smaller than the previous version. Since this image is 201x134, the previous image was somewhere around 500x335 (or larger with multiple resaves that scaled it smaller).

The other thing to notice is the block quality. The sky has big chunks indicating a low quality image. The front of the house has small blotches with no visible grid. The dog shows grid-like blocks on his ear and face that match the sky but not the house. And the jets have no visible blocky artifacts. So while the dog may go with the sky, it does not match the house or the jets. The mottled pattern on the front of the house actually matches what I would expect from a picture of this quality. (I even ran a few tests with other pictures using Save For Web and "Very High" and 83% -- the tests generated the same blotchy pattern seen on the house.) This means that the dog, jets, and sky are wrong for this picture.

Error Level Analysis
Taken without any context, the ELA for this image identifies the dog and jets as being at a higher error level potential (newer) than the rest of the image. However, this difference could be explained due to a combination of Photoshop and scaling. Photoshop attempts to counteract the JPEG losslessness by over-emphasizing high frequency areas. (See my Alyson Hannigan write-up.) This image does have a large amount of rainbowing (the red/blue/purple coloring), so this certainly matches the meta data that identified Photoshop. With scaling, every pixel is modified and high frequency areas (like the dog's fur) can have pixel values altered more than the rest of the image.



However, there are two issues that really stand out. First, the jet planes appear to be uniform in color (low frequency) yet have a high error level. So this is a modification.

Second, ELA should identify similar 8x8, 16x16, etc. blocks as PCA; for low quality images, ELA identifies the chrominance subsampling. And this is a problem. The subsampling should be the same across the entire image. However, the sky clearly shows 16x8 subsampling (scaled to fit 7x3 grids). However, the house only has square subsampling (either 8x8 or 16x16 scaled to 7x7; you can easily see them on the roof). With the dog and the jets, I don't see the subsampling grid. This means that the image must be made from four separate components: sky, house, jets, and dog.

Blur Detection
Blur detection identifies subtle, high frequency edges created from artificial blurs. Ideally, each edge should either consist on one thin line, or two parallel lines that are one pixel apart (1 pixel wide double line). Anything else indicates an artificial blur.



In this picture, the dog has 1-pixel wide double lined edges -- it is real. However, the house and jets both have wide double edges; the jets and house have artificial blurs.

Color Distance
A new algorithm that I've been working on is based on color distances. Basically, real pictures blend colors along edges. When pictures are spliced (one pasted onto another), there is no blending. This algorithm measures the amount of blend. If you see a thin black line outlining anything, then it was spliced.



In this case, the dog has a thin, black outline against the sky. He was spliced into the picture. It is a little more difficult to see, but the upper 4 jets also have thin black lines. They were pasted into the picture.

Observation

Alright, so it really looks like the dog and jets were spliced into the image. How many jets were there originally?



In this example, I have shifted the picture down and to the left a little. This allows me to overlay the top three jets onto the bottom three jets. Guess what? Two of them are perfect matches. Let's number the jets for clarity:

4

 2

5 1

 3

6

From what I can tell jets 2, 4, and 5 are all the same plane and all uniformly spaced. Similarly, jets 1, 3, and 6 are the same plane. That is a total of two unique planes.

In real life, jets flying in formation will not be perfectly at the same angle to the viewer and they will not be perfectly spaced. Instead, they will all be ever so slightly different.


DoD photo by Airman 1st Class Gul Crockett, U.S. Air Force/Released


Same image, shifted to align the top plane on the middle plane, and overlaid to show differences.

This uniqueness factor even holds when the image is scaled smaller, like when the wingspan is only 20 pixels across. They may be small, but they should all be different. I think Lascelles cloned some jets.

Also, notice how none of Lascelles' vapor trails look the same. If they are about the same thickness and same color and the sun is in the same place, then they should all look similar. Jet #3 has a much whiter vapor trail -- likely two trails pasted next to each other. Jet #5 has a dark edge, probably from blending an overlapping paste.

National Disaster

Even without specialized tools, National Geographic should have noticed the cloning of the jets, varying vapor trails, and the artificial blur. Since they have the original submission, they could have checked the meta data and quantization tables to see if it matched the digital camera. This alone would have identified the fraud. And most importantly: don't just accept the word of a photographer; it may be significantly altered even if they claim that it is "100% real".

There's a couple of random thoughts rumbling around my head... Rather than writing a blog entry on each, I decided to just mention them here.

Oiling The Machinery

Everyone is complaining about the oil gusher in the Gulf of Mexico. And everyone seems to have their own solutions. Use hair, use hay, construct a man-made barrier island, send down sludge, and more. British Petroleum has a couple of solutions lined up -- if one fails, then they will try the next. One of their solutions won't be ready until August! Some people think the government should take over the capping processes, but our government can't even pave roads without months of debate.

A few people are blaming Obama for this problem. (These are probably the same people who are upset that the Republicans lost the election and still watch Glenn Beck.) Frankly, we can't blame Obama for this one. Blame Bush? Sure -- he caused it by easing governmental regulatory oversight between 2006 and 2008. Obama only inherited this mess. And given other messes like Health Reform, Financial Reform, Immigration Reform, and Lobbying Reform... Regulatory Oversight Reform is just another item in the to-do list.

Anyway, I think I know the solution to quickly stopping the oil gusher. Congress should pass a resolution preventing BP from collecting any revenue until the gusher is capped and the cleanup is completed. Until both of those happen, any revenue received by BP should either go toward capping and cleanup, or be forfeited to the government and impacted states. If we cut off their revenue, then they will have an incentive for achieving a faster solution.

Google and SSL

Google recently released a beta of an SSL solution for their search engine. (https://www.google.com) They claim that this will improve privacy:

This secured channel helps protect your search terms and your search results pages from being intercepted by a third party. This provides you with a more secure and private search experience.

There's a few problems here. First, SSL is a placebo. From a security perspective, it does not add very much security or privacy. To gain security and privacy, you really need SSL with client-side certificates -- but Google isn't offering that.

Second, I find it ironic that Google is offering a security and privacy solution. I mean, they store every search, associate searches with user accounts, and cache personal information. So for them to be concerned about search privacy is just... funny.

Summer's Here

Summer vacation has clearly started. The number of malware and attackers scanning my web site for vulnerabilities has increased 10x compared to last month. Looks like the k1dd13z are out of school.

The uptick includes a significant increase in scans for WordPress vulnerabilities. Sample initial scans look like this:

2010-05-03 11:10:10 | 72.46.136.130 | GET /wp-login.php

2010-05-09 17:43:28 | 188.40.73.239 | POST /wp-admin

2010-05-24 17:52:37 | 213.231.27.46 | GET /blog/wp-includes/js/tinymce/wp-mce-help.php

2010-05-24 17:52:40 | 213.231.27.46 | GET /blog/wp-admin/upgrade.php

2010-05-24 23:24:35 | 69.245.165.224 | GET /blog/wp-login.php

Of these scans, it is the tinymce one that bothers me the most. This is a WYSIWYG editor and it has a history of remote access vulnerabilities. If you don't need it, consider removing it or locking down your htaccess file and web pages.

Arizona State Lottery

Arizona recently passed Senate Bill 1070. The law basically says that people suspected of being illegal aliens will be asked to provide proof that they are permitted to be in the USA. Failure to provide proof can lead to incarceration and/or deportation.

I'm not going take a side on whether this law is racial profiling or justified. (Let's leave that debate to the pundits and citizens of Arizona.) Rather, I'm looking at this from the hacker point of view. The first US Citizen that is arrested and/or deported under this law will have a heck of a lawsuit. Most likely, the victim will receive an out-of-court settlement as an apology because the case won't have legs to stand on if a provable citizen goes to court. Anyway, this law should be called the Arizona State Lottery because you too can become a millionaire overnight!

I'm always looking for security-oriented podcasts to listen to when I'm traveling. Some of the ones that I have found are pretty bad, while others are truly excellent.

2600

The 2600 radio show "Off The Hook" has been around since 1988. They have had episodes available for download as MP3 files since before "podcast" became a word. So one would think that, with over 20 years of experience, they would finally learn how to use the mixing board! For a technical forum, these jokers can barely make the phone lines work; every other podcast that I have heard has been cleaner and more professionally produced than this one.

Getting past the quality issues are the topics and advice. While they do discuss current topics related to security and privacy, they often take the viewpoint of someone intentionally doing something wrong. In some cases, they actively promote and advocate illegal activities. If you heed their advice and get caught, then you will probably end up in jail. (No wonder many of their letters to the editor published in 2600: The Hacker's Quarterly are from people in prison... and some of the hosts have felony convictions.)

I cannot recommend this show to anyone. It is an hour of your life that you will never get back. I give it two frownies:

2600's Emmanuel Goldstein also has a show called "Off The Wall". It is basically a baseless rant and topic-less meander with really bad background music. Three frownies: . You'd be better off and more satisfied by spending an hour staring at a blank wall.

CyberSpeak

CyberSpeak is a semimonthly podcast hosted by Ovie Carroll (Director, Cybercrime Lab at U.S. Department of Justice Computer Crime and Intellectual Property Section) and Bret Padres (Director, Digital Forensics at Stroz Friedberg, LLC). One would think that, with their backgrounds in law enforcement, this would be a dry and boring podcast -- but one would be very wrong! The hosts are hysterical (they constantly crack each other up, and usually make me laugh out loud at least once per episode).

For topics, they cover recent issues in computer security, computer forensics, and privacy. Unlike 2600, Ovie and Bret never advocate illegal activities, but they do not always support laws and legal requirements. They are usually very critical in their evaluations of legal topics and usually see both sides of an issue.

This hour-long show contains discussions about current topics, reviews of new tools, lists of cool web sites, and interviews with people involved in the field. While they do evaluate tools and interview software developers, they don't actively push products.

This podcast is a must-follow for anyone interested in computer security, forensics, and privacy. I give this podcast my highest rating, three smilies:

My only criticism: When he gets excited, Ovie shouts a lot. Be prepared to lose an eardrum if you wear headphones.

Crypto-Gram

Security guru Bruce Schneier has a monthly newsletter called the "Crypto-Gram". In it, he voices his opinion about various computer privacy related issues. The articles are actually a combination of his blog postings and mass media essays. While I don't always agree with him (I agree about 90% of the time), his arguments are well written and clearly presented. If you are looking for a speech and debate topic, he provides plenty of great starting points.

Unlike other podcasts, this one does not review technologies or dive into deep technical discussions. Instead, Schneier stays at the 1000-foot level, focusing on the forest and not the trees. You won't learn a new hack or how to apply a new program, but you will gain insight into the implications.

Shortly after his newsletter is published, the "Crypto-Gram Security Podcast" is updated. The podcast is someone other than Schneier reading the newsletter. The podcasts vary in length, but are usually 10-20 minutes long. If you only have a few minutes for something that will stimulate your brain, then this is a great choice.

Two smilies:

Speaking of Security

RSA has a weekly podcast called "Speaking of Security". This podcast is short -- usually 10 minutes -- and includes sponsor advertisements. All of the interviews involve RSA partners and affiliates.

Having said that, the topics do give a good idea about available security oriented products and services. Of the product pushing podcasts, this is one of the better ones. One smiley:

PaulDotCom

There is a security podcast called "PaulDotCom Security Weekly". This podcast ranges from 45 minutes to 1.5 hours. But, it is almost all product placement, advertisements, and unrelated tangents. The banter between the hosts may be funny to them, but rarely even gets a smirk from me. Some episodes have over 10 minutes of nothing (ads, music, and tangents) before discussing anything security related.

In Episode 199, they mentioned not having any listener winners. Perhaps it is because they don't have any listeners... The technical coverage is mainly personal experience and comments like "and then I used the blah program to do blah" without details or context. One frownie:

This Week in Computer Hardware

The video podcast "This Week in Computer Hardware with Ryan Shrout" is not security focused. However, it discusses hardware and other issues that directly impact security, privacy, and forensics. The host is very knowledgeable, the discussions are focused and detailed, and the hour-long podcast is entertaining without the need for humorous tangents. Two smilies:

Other Podcasts

Computer security and forensics really require timely topics. Thus, I'm not reviewing podcasts like "The Security Roundtable" and "SploitCast" since they haven't released new episodes in years.

Are they other (free) security podcasts that are worth listening to? If you know of other security-related podcasts, let me know! I'll update this blog entry with the podcast name, your rating (from three frownies to three smilies) and your brief description of the podcast. Be sure to include a link to the podcast's feed!

Other Recommentations

David Garrard recommends the Australian podcast, "Risky Business". David didn't provide a description, so I just listened to two episodes. They cover technical topics with some depth (not enough to program by, but enough to get you started) and discuss current issues in security and privacy. It is like CyberSpeak, but without the funny banter and with an Australian accent. Three smilies:

Paul Wilkins, Keith, and King recommend "Security Now". Paul gave it two smileys , while Keith recommended two to three smilies. Keith included this excellent description:

I've not listened to any of the other podcasts you listed, so I can't compare to them. But I've found "Security Now" (http://twit.tv/sn, http://grc.com/sn, http://itunes.apple.com/us/podcast/security-now/id79016499) to be excellent. Each week, Steve Gibson and Leo Laporte review the week in security news, provide errata and updates to previous shows, and then spend alternate weeks either doing listener Q&A or covering some interesting topic (frequently not security related, but always interesting to geeks). I'd give it three smileys for what it is; some may give it two smileys because it's more consumer oriented and not NSA-level hard core. 1.5 - 2 hours, and always entertaining. Contains 2-3 product placement spots, but even those are entertaining, as Leo does them in his characteristic homey, Arthur Godfrey style.

King added:

Another vote for Security Now, it's a good overview of timely security information and chosen topics. Leo is a professional radio/tv guy from way back (as well as fairly techy) and Steve is deeply techy but can still talk to "regular" people. They make a good team, even when you already know the topic, they're entertaining.

I recently listened to the "Security Now" podcast and agree with Paul, Keith, and King. I give it a solid two smilies:

The first time I used Unix, I was sitting in a small computer lab and had a cheat sheet of commands. 'ls' for listing files, 'mkdir' for making directories, and 'cp' to copy. But I found my favorite command within a few seconds: 'w'. This command shows you who is on the system and the commands they are currently running. My first response was "Cool! I can see what everyone is doing!" The guy sitting next to me didn't even look over. He just said, "And they can see you."

While this wasn't my first experience with online privacy, it was a huge eye opener. Privacy online is just like privacy in public; there is no privacy beyond what you create for yourself.

Wardriving the Google Way

A couple of days ago, Google came forward with an announcement and apology. The Google Street View cars that have been driving across cities all over the world have been doing more than mapping cities -- they have also been mapping wireless networks. This includes storing WiFi SSID strings as well as any packets sent over unprotected (open) wireless networks. Over the course of 5 years, they managed to collect about 600 gigabytes of data.

Now, to put things into perspective, 600 gigabytes can fit on most $99 hard drives. And they downloaded it over the course of 5 years. That's a download rate of about 30K per second. I can download over Tor faster than that. (And Tor isn't know for speed.)

So Google's vans were picking up a packet here and a packet there, over 5 years, across 30 countries. What kind of sensitive data could they capture? Assuming they were driving and everything was timed right, they could probably capture an HTML request and web page (but probably not the images), or an email being sent or received. In the worst case, the van may have stopped at an intersection and captured traffic for a duration of a minute or two. More likely, they captured fractions of transactions and a lot of ACK and ARP packets.

As far as privacy goes, I don't see this as a huge risk. Everything was transmitted out in the open and without any encryption. Anyone could see it if they looked. Aliens in the Epsilon Eridani solar system will be able to see the transactions in plain text in 10.5 years. So having Google see it really isn't that much of a loss of privacy. The actions took place in public and Google saw it.

However, I am extremely impressed with Google's response. They didn't hide it; they came out and said what happened. And they are planning to delete the data as soon as they make sure that no laws were broken. Outstandingly honest.

Better Sources of Sensitive Data

Many years ago, I was a network administrator. While checking the DNS logs, I couldn't help but notice that the DNS server had cached hostnames for a ton of porn web sites. At the weekly office meeting, I brought this up as a topic... "I know that someone in the department is looking at porn on the office computers. Rather than spending time tracking you down, please just stop it." The entire room went dead silent. And I gotta say, the DNS server stopped caching porn sites.

Google is planning on populating an entire city with fiber network. When they finally announce the city, somewhere between 50,000 and 500,000 residents will switch their ISP to the new Google network service. And this is where the privacy risk resides...

Most ISPs offer DNS services for their clients. So they can see every site you tried to access and when you tried to access it. ISPs also control the last-mile connection, so they can gain metrics about how much traffic you generate and consume, your hours of work, the network protocols you use, and even capture anything sent over plain text.

Then again, this is the privacy issue we face everyday. Does Comcast or Cox or Rogers or Sprint capture these metrics? Sure they do! At least, in raw packet metrics. This is how they determine when they need to allocate additional network resources or equipment, and when customers abuse "unlimited bandwidth" policies. Do they keep the data or use it for anything else? Probably some of it. As we saw when AOL released sample search data, ISPs do collect. But as a Comcast customer, I'll probably never know the full details.

At least Google is straightforward about their methods and policy, and strive to rectify collection issues. But it will be interesting to see how they handle serious ISP issues and practices when they take a full ISP role. Running a small experimental WiFi network is not the same as providing network access to an entire city. And collecting data related to every search people perform is very different from collecting information about every site you visit, every networked program you run, and everything you possibly do online. Even something basic, like monitoring a router or running a caching DNS server, requires data collection and metrics. While Google does take extraordinary measures to protect user's privacy, they are bound to make collection mistakes. Good luck Google, and thanks for being so honest.

No operating system is perfect. In my latest book, Ubuntu: Powerful Hacks and Customizations, I provide tips and tricks to enhance an already awesome operating system. (However not all hacks, like this one, made it into the book.) Some of these modifications add functionality to make the system better, while others are workarounds for common problems.

Watch Your Language

One such common problem is the built-in spell checker. With Dapper Drake (6.06 LTS) and Hardy Heron (8.04 LTS), the spell checker uses the default system language. If you installed using Australian English then it will use Australian English.

However, this isn't the case with later Ubuntu releases. If you are in the United States and use gedit, then you've probably noticed that the spell checker uses British English instead of American English. (For example, it thinks "color" is spelled "colour".) While you can change this using the Set Language option under the gedit Tools menu, changes are not retained when you open a new document.

This problem is actually much larger. Debian users have had this issue since at least 2004, but Ubuntu didn't incorporate this problem until 2008. Intrepid Ibex (8.10), Jaunty Jackalope (9.04), Karmic Koala (9.10), and the newest release -- Lucid Lynx (10.04) -- all have this spell checker problem.

He Who Spelt It...

The core problem actually isn't gedit. This simple notepad uses an open-source package called "enchant" for dictionary support. Enchant is a wrapper around a variety of back-end spell checker systems. The search list is found in /usr/share/enchant/enchant.ordering. The contents should look something like:

*:myspell,aspell,ispell

fi:voikko,ispell,myspell,aspell

fi_FI:voikko,ispell,myspell,aspell

he:hspell,myspell

he_IL:hspell,myspell

yi:uspell

This says that the Finnish language (fi) should use voikko as the primary spell checker first, then ispell, myspell, and aspell. If no specific language definition line is available, then it will default to the "*" entry: myspell then aspell then ispell.

And that's the problem. Myspell does not use the system-wide dictionary (see the man page section "Directories Important To Enchant"), so it ignores the default system language. In contrast, aspell does used the system-wide setting and it is installed by default on Ubuntu. Changing the enchant default to use aspell before myspell fixes the problem:

*:aspell,myspell,ispell

Alternately, you can leave the default and specify an alternate order for English:

*:myspell,aspell,ispell

en:aspell,myspell,ispell

en_US:aspell,myspell,ispell

Word Up

Finally, make sure that the language dialect is enabled on the system. For American English (en_US), use:

sudo locale-gen en_US.UTF-8

sudo update-locale LANG=en_US.UTF-8

You might need to logout and login in order to refresh the language settings in your various running shells and applications. The locale-gen program can take a specific dialect (en_US or en_US.UTF8), base language (en for generating all English dialects), or no options to use the default base language. The set of installed languages is found under /usr/share/locale/.

This trick also works for other languages and dialects, including Canadian English (en_CA), Hong Kong English (en_HK), Korean (ko_KR.eucKR), Lithuanian (lt_LT.ISO-8859-13), and any other language on the system.