Cloudflare: The New Face of Bulletproof Spam Hosting

…or, why do I get all this spam, and who’s serving it?

Spammers have long had to face a problem. Legitimate Web hosting companies don’t host spam sites. Almost all Web hosts have policies against spam, so spammers have to figure out how to get their sites hosted. After all, if you can’t go to the spammer’s website to buy something, the spammer can’t make money, right?

In the past, spammers have used overseas Web hosting companies, in countries like China or Romania, that are willing to turn a blind eye to spam in exchange for money. A lot of spammers still do this, but it’s becoming less common, as even these countries have become increasingly reluctant to host spam sites.

For a while, many spammers were turning to hacked websites. Someone would set up a WordPress blog or a Joomla site but wouldn’t keep on top of security patches. The spammers would use automated tools capable of scanning hundreds of thousands of sites looking for vulnerabilities and hacking them automatically, then they’d place the spam pages on the hacked site. And a lot of spammers still do this.

But increasingly, spammers are turning to the new big thing in bulletproof spam serving: content delivery networks like Cloudflare.


What is a content delivery network?

Basically, a content delivery network is a bunch of servers that sit between a traditional Web server and you, the Web user.

A ‘normal’ Web server arrangement looks something like this:

When you browse the Web, you connect directly to a Web server over the Internet. The Web server takes the information stored on it and sends it to your computer.

With a content delivery network, it looks more like this:

The CDN, like Cloudflare, has a large number of servers, often spread all over the country (or the globe). These servers make a copy of the information on the Web server. When you visit a website served by a CDN, you do not connect to the Web server. You connect to one of the content delivery network servers, which sends you the copy of the information it made from the Web server.

There are several advantages to doing this:

1. The Web server can handle more traffic. With a conventional Web server, if too many people visit the Web site at the same time, the Web server can’t handle the traffic, and it goes down.

2. The site is protected from hacking and denial-of-service attacks. If someone tries to hack the site or knock it offline, at most they can affect one of the CDN servers. The others keep going.

3. It’s faster. If you are in Los Angeles and the Web server is in New York, the information has to travel many “hops” through the Internet to reach you. If you’re in Los Angeles and the content delivery network has a server in Los Angeles, you’ll connect to it. There are fewer hops for the information to pass through, so it’s delivered more quickly.


Cloudflare and spam

Spammers love Cloudflare for two reasons. First, when a Web server is behind Cloudflare’s network, it is in many ways hidden from view. You can’t tell who’s hosting it just by looking at its IP address, the way you can with a conventional Web server, because the IP address you see is for Cloudflare, not the host.

Second, Cloudflare is fine with spam. They’re happy to provide content delivery services for spam, malware, “phish” sites like phony bank or PayPal sites–basically, whatever you want.

Cloudflare’s Web page says, a little defensively, “CloudFlare is a pass-through network provider that automatically caches content for a limited period in order to improve network performance. CloudFlare is not a hosting provider and does not provide hosting services for any website. We do not have the capability to remove content from the web.” And, technically speaking, that’s true.

Cloudflare doesn’t own the Web server. They don’t control what’s on it and they can’t take it offline. So, from a literal, technical perspective, they’re right when they say they can’t remove content from the web.

They can, however, refuse to provide services for spammers. They can do that, but they don’t.


History

CloudFlare was founded by Matthew Prince, Lee Holloway, and Michelle Zatlyn, three people who had previously worked on Project Honey Pot, which was–ironically–an anti-spam, anti-malware project.

Project Honey Pot allows website owners to track spam and hack attacks against their websites and block malicious traffic. In an interview with Forbes magazine, Michelle Zatlyn said:

“I didn’t know a lot about website security, but Matthew told me about Project Honey Pot and said that 80,000 websites had signed up around the world. And I thought ‘That’s a lot of people.’ They had no budget. You sign up and you get nothing. You just track the bad guys. You don’t get protection from them. And I just didn’t understand why so many people had signed up.”

It was then that Prince suggested creating a service to protect websites and stop spammers. “That’s something I could be proud of,’” Zatlyn says. “And so that’s how it started.”

So Cloudflare, which was founded with the goal of stopping spammers by three anti-spam activists, is now a one-stop, bulletproof supplier for spam and malware services.


The problem

Cloudflare, either intentionally or deliberately, has a broken internal process for dealing with spam and abuse complaints. Spamcop–a large anti-spam website that processes spam emails, tracks the responsible mail and Web hosts and notifies them of the spam–will no longer communicate with Cloudflare, because Cloudflare does not pay attention to email reports of abuse even though it has a dedicated abuse email address (that’s often unworkakble, as Cloudflare has in the past enabled spam filtering on that address, meaning spam complaints get deleted as spam).

Large numbers of organized spam gangs sign up for Cloudflare services. I track all the spam that comes into my mailbox, and I see so much spam that’s served by Cloudflare I keep a special mailbox for it.

Right now, about 15% of all the spam I receive is protected by Cloudflare. Repeated complaints to their abuse team, either to their abuse email addres or on their abuse Web form, generally have no effect. As I’ve documented here, Cloudflare will continue to provide services for spam, malware, and phish sites even long after the Web host that’s responsible for them has taken them down; they kept providing services for the malware domain rolledwil.biz, being used as part of a large-scale malware attack against Android devices, for months after being notified.

One of the spam emails in my Cloudflare inbox dates back to November of 2013. The Spamvertised domain, is.ss47.shsend.com, is still active, nearly a year after Cloudflare was notified of the spam. A PayPal phish I reported to CloudFlare in March of 2014 was finally removed from their content delivery network three months later…after some snarky Twitter messages from Cloudflare’s security team.

(They never did put up the interstitial warning, and continued to serve the PayPal phish page for another month or more.)

Cloudflare also continues to provide services for sites like masszip.com, the Web site that advertises pirated eBooks but actually serves up malware.

In fact, I’ve been corresponding with a US copyright attorney about the masszip.com piracy, and he tells me that Cloudflare claims immunity from US copyright law. They claim that people using the Cloudflare CDN aren’t really their concern; they’re not hosting the illegal content, they’re just making a copy of it and then distributing it, you see. Or, err, something.

I am not sure what happened within Cloudflare to make them so reluctant to terminate their users even in cases of egregious abuse, such as penis-pill spam, piracy, and malware distribution. From everything I can find, it was started by people genuinely dedicated to protecting the Internet from spam and malware, but somehow, somewhere along the way, they dropped the ball.

I wonder if Michelle Zatlyn is still proud.

Some thoughts on government funding for research

Every time you buy a hard drive, some of your money goes to the German government.

That’s because in the late 1990s, a physicist named Peter Grünberg at the Forschungszentrum Jülich (Jülich Research Center) made a rather odd discovery.

The Jülich Research Center is a government-funded German research facility that explores nuclear physics, geoscience, and other fields. There’s a particle accelerator there, and a neutron scattering reactor, and not one or two or even three but a whole bunch of supercomputers, and a magnetic confinement fusion tokamak, and a whole bunch of other really neat and really expensive toys. All of the Center’s research money comes from the government–half from the German federal government and half from the Federal State of North Rhine-Westphalia.

Anyway, like I was saying, in the late 1990s, Peter Grünberg made a rather odd discovery. He was exploring quantum physics, and found that in a material made of several layers of magnetic and non-magnetic materials, if the layers are thin enough (and by “thin enough” I mean “only a few atoms thick”), the material’s resistance changes dramatically when it’s exposed to very, very weak magnetic fields.

There’s a lot of deep quantum voodoo about why this is. Wikipedia has this to say on the subject:

If scattering of charge carriers at the interface between the ferromagnetic and non-magnetic metal is small, and the direction of the electron spins persists long enough, it is convenient to consider a model in which the total resistance of the sample is a combination of the resistances of the magnetic and non-magnetic layers.

In this model, there are two conduction channels for electrons with various spin directions relative to the magnetization of the layers. Therefore, the equivalent circuit of the GMR structure consists of two parallel connections corresponding to each of the channels. In this case, the GMR can be expressed as

Here the subscript of R denote collinear and oppositely oriented magnetization in layers, χ = b/a is the thickness ratio of the magnetic and non-magnetic layers, and ρN is the resistivity of non-magnetic metal. This expression is applicable for both CIP and CPP structures.

Make of that what you will.


Conservatives and Libertarians have a lot of things in common. In fact, for all intents and purposes, libertarians in the United States are basically conservatives who are open about liking sex and drugs. (Conservatives and libertarians both like sex and drugs; conservatives just don’t cop to it.)

One of the many areas they agree on is that the governmet should not be funding science, particularly “pure” science with no obvious technological or commercial application.

Another thing they have in common is they don’t understand what science is. In the field of pure research, you can never tell what will have technological or commercial application.

Back to Peter Grünberg. He discovered that quantum mechanics makes magnets act really weird, and in 2007 he shared a Nobel Prize with French physicist Albert Fert, a researcher at the French Centre national de la recherche scientifique (French National Centre for Scientific Research), France’s largest government-funded research facility.

And it turns out this research had very important commercial applications:

You know how in the 80s and 90s, hard drives were these heavy, clunky things with storage capacities smaller than Rand Paul’s chances at ever winning the Presidency? And then all of a sudden they were terabyte this, two terabyte that?

Some clever folks figured out how to use this weird quantum mechanics voodoo to make hard drive heads that could respond to much smaller magnetic fields, meaning more of them could be stuffed on a magnetic hard drive platter. And boom! You could carry around more storage in your laptop than used to fit in a football stadium.

It should be emphasized that Peter Grünberg and Albert Fert were not trying to invent better hard drives. They were government physicists, not Western Digital employees. They were exploring a very arcane subject–what happens to magnetic fields at a quantum level–with no idea what they would find, or whether it would be applicable to anything.


So let’s talk about your money.

When it became obvious that this weird quantum voodoo did have commercial possibility, the Germans patented it. IBM was the first US company to license the patent; today, nearly all hard drives license giant magnetoresistance patents. Which means every time you buy a hard drive, or a computer with a hard drive in it, some of your money flows back to Germany.

Conservatives and libertarians oppose government funding for science because, to quote the Cato Institute,

[G]overnment funding of university science is largely unproductive. When Edwin Mansfield surveyed 76 major American technology firms, he found that only around 3 percent of sales could not have been achieved “without substantial delay, in the absence of recent academic research.” Thus some 97 percent of commercially useful industrial technological development is, in practice, generated by in-house R&D. Academic science is of relatively small economic importance, and by funding it in public universities, governments are largely subsidizing predatory foreign companies.

Make of that what you will. I’ve read it six times and I’m still not sure I understand the argument.

The Europeans are less myopic. They understand two things the Americans don’t: pure research is the necessary foundation for a nation’s continued economic growth, and private enterprise is terrible at funding pure research.

Oh, there are a handful of big companies that do fund pure research, to be sure–but most private investment in research comes after the pure, no-idea-if-this-will-be-commercially-useful, let’s-see-how-nature-works variety.

It takes a lot of research and development to get from the “Aha! Quantum mechanics does this strange thing when this happens!” to a gadget you have in your home. That also takes money and development, and it’s the sort of research private enterprise excels at. In fact, the Cato Institute cites many examples of biotechnology and semiconductor research that are privately funded, but these are types of research that generally already have a clear practical value, and they take place after the pure research upon which they rest.

So while the Libertarians unite with the Tea Party to call for the government to cut funding for research–which is working, as government research grants have fallen for the last several years in a row–the Europeans are ploughing money into their physics labs and research facilities and the Superconducting Supercollider, which I suspect will eventually produce a stream of practical, patentable ideas…and every time you buy a hard drive, some of your money goes to Germany.

Modern societies thrive on technological innovation. Technological innovation depends on understanding the physical world–even when it seems at first like there aren’t any obvious practical uses for what you learn. They know that, we don’t. I think that’s going to catch up with us.

Of Android, iOS, and the Rule of Two Thousand, Part II

In part 1 of this article, I blogged about leaving iOS when I traded my iPhone for an Android-powered HTC Sensation 4G, and how I came to detest Android in spite of its theoretical superiority to iOS and came back to the iPhone.

Part 1 talked about the particular handset I had, the T-Mobile version of the Sensation, a phone with such ill-conceived design, astronomically bad build quality, and poor reliability that at the end of the year I was on my third handset under warranty exchange–every one of which failed in exactly the same way.

Today, in Part 2, I’d like to talk about Android itself.


When I first got my Sensation, it was running Android 2.3, code-named “Gingerbread.” Android 3 “Honeycomb” had been out for quite some time, but it was a build aimed primarily at tablets, not phones. When I got my phone, Android 4 “Ice Cream Sandwich” was in the works, ready to be released shortly.

That led to one of my first frustrations with the Android ecosystem–the shoddy, patchwork way that operating system updates are released.

My phone was promised an update in the second half of 2011. This gradually changed to Q4 2011, then to December 2011, then to January 2012, then to Q1 2012. It was finally released on May 16 of 2012, nearly six months after it had been promised.

And I got off lucky. Many Motorola users bought smart phones just before the arrival of Android 4; their phones came with a written guarantee that an update to Android 4 would be published for their phones. It never happened. To add insult to injury, Motorola released a patch for these phones that locked the bootloader, rendering the phone difficult or impossible to upgrade manually with custom ROMs–so even Android enthusiasts couldn’t upgrade the phones.

Now, this is not necessarily Google’s fault. Google makes the base operating system; it is the responsibility of the individual handset manufacturers to customize it for their phones (which often involves shoveling a lot of crapware and garbage programs onto the phone) and then release it for their hardware. Google has done little to encourage manufacturers to backport Android, nor to get manufacturers to offer a consistent user experience with software updates, instead leaving the device manufacturers free to do pretty much as they choose except actually fork Android themselves…which has led to what developers call “platform fragmentation” and to what Motorola Electrify, Photon and Atrix users call things I shan’t repeat in a blog as family-friendly as this one.

But what of the operating system itself?

Well, it’s a mixed bag of mess.


When I first got my Android phone, I noted how the user interface seemed to have been designed by throwing a box of buttons and dialogs and menus over one’s shoulder and then wired up wherever they hit. System settings were scattered in three different places, without it necessarily being obvious where you might find any particular setting. Functionality was duplicated in different places. The Menu button is a mess; it’s filled with whatever the programmer couldn’t find a better place for, with little thought to good UI design.

Android is built on Linux, an operating system that has a great future on the desktop ahead of it, and always will. The Year of Linux on the Desktop was 2000 was 2002 was 2005 was 2008 was 2009 was 2012 will be 2013. Desktop aside, Linux has been a popular server choice for a very long time, because one thing Linux genuinely has going for it is rock-solid reliability. When I was working in Atlanta, I had a Linux Gentoo server that had accumulated well over two years’ continuous uptime and was shut down only because it needed to be moved.

So it is somewhat consternating that Linux on cell phones seems rather fragile.

So fragile, in fact, that my HTC Sensation would pop up a “New T-Mobile Service Notice” alert every week, reminding me to restart the phone. Even the network operators, it would seem, have little confidence in Android’s stability.

It’s a bit disappointing that the one thing I most like about Linux seems absent from Android. Again, though, this might not be Google’s fault directly; the handset makers and network operators do this to themselves, by taking Android and packaging it up with a bunch of craplets of spotty reliability.

One of the things that it is really, really important to be aware of in the Android ecosystem is the way the money flows. You, as a cell phone owner, are not Google’s customer. Google’s customer is the handset manufacturer. You, as as a cell phone owner, are not the handset manufacturer’s customer. The handset manufacturer’s customer is the network operator. You are the network operator’s customer–but you are not the network operator’s only customer.

Because of this, the handset maker and the network operator will seek additional revenue streams whenever they can. If someone offers HTC money to bundle some crap app on their phones, HTC will do it. If T-Mobile decides it can get more revenue by bundling its own or someone else’s crap app on your phone, it will.

Not only are you not the customer, at some points along the chain–for the purposes of Google ad revenue, say–you are the product being sold. Whenever you hear people talking about “freedom” or “openness” in the Android ecosystem, never forget that.

I sometimes travel outside the US, mainly to Canada these days. When I do that, my phone really, really, really wants me to turn on data roaming.

There are reasons for that. When you roam, especially internationally, the telcos charge rates for data that would make a Mafia loan shark blush. So Android agreeably nudges you to turn on data roaming, and here’s kind of a sticking point…

Even if you’re connected to the Internet via wifi.

It pops up an alert constantly, and by “constantly” I really do mean constantly. Even when you have wifi access, it pops up every time you switch applications, every time you unlock the phone, and about every twenty minutes when you aren’t using the phone.

Just think of it as Google’s way to help the telcos tap your ass that revenue stream.

This multiple-revenue-streams-from-multiple-customers model has implications, not only for the economics of the ecosystem, but for the reliability of your phone as well. And even for the battery life of your phone.

Take HTC phones on T-Mobile (please!). They come shoveled–err, “bundled”–with an astonishing array of crap. HTC’s mediocre Facebook app. HTC Peep, HTC’s much-worse-than-mediocre Twitter client. Slacker Radio, a client for a B-list Internet radio station.

The presence of all the various crapware that comes preloaded on most Android phones, plus the fact that Android apps don’t quit when they lose focus, generally means that a task manager app is a necessary addition to any Android system…which is fine for the computer literate, but less optimal for folks who aren’t so computer savvy.

And it doesn’t always help.

For example, Slacker Radio on my Sensation insists on running all the time at startup, whether I want it to or not:

Killing it with the task manager never works. Within ten minutes after being killed, it somehow respawns, like a zombie in a George Ramero movie, shambling after you no matter how many times you shoot it:

The App Manager in the Android control panel has a function to disable an app entirely, even if it’s set to launch at startup. For reasons I was never able to understand, this did not work with Slacker. It was always there. Always. There. It. Never. Goes. Away. You. Can’t. Hide. From. It.

Speaking of that “disable app” functionality…

Oh, goddamnit, no, I don’t want to turn on data roaming. Speaking of that “disable app” functionality, use it with care! I soon learned that disabling some bundled apps can have…unfortunate consequences.

Like HTC Peep, for instance. It’s the only Twitter client for smartphones I have yet found that is even worse than the official Twitter client for smartphones. It loads a system service at startup (absent from the Task Killer screenshots above because I have the task killer set not to display system services). If you let it, it will download your Twitter feed.

And download your Twitter feed.

And download your Twitter feed. It does not cache any of the Twitter messages you read; every time you start its user interface, it re-downloads the whole thing again. The result, as you might imagine, is eyewatering amounts of data usage. If you aren’t one of the lucky few who still has a truly unmetered data plan, think twice about letting Peep have your Twitter account information!

Oh, and don’t try to disable it in the application control panel. If you do, the phone’s unlock screen doesn’t work any more, as I discovered to my chagrin. Seriously.

The official Twitter app isn’t much better…

…but at least it isn’t necessary to unlock the damn phone.

All this crapware does more than eat memory, devour bandwidth, and slow the phone down. It guzzles battery power, too. One of the default Google apps, Google Maps, also starts a service each time the phone boots up, and man, does it hog the battery juice…even if you don’t use Maps at all. (This screen shot, for instance, was taken at a point in time when I hadn’t touched the Maps app in days.)

You will note the battery is nearly exhausted after only four hours and change. I eventually took to killing the Maps service whenever I restarted the phone, which seems to have improved the HTC’s mediocre battery life without actually affecting Maps when I went to use it.

Another place where Android’s lack of a clear and consistent user interface–

AAAAARGH! NO! NO, YOU PATHETIC FUCKING EXCUSE OF A THING, I DO NOT WANT TO TURN ON DATA ROAMING! THAT’S WHY I SAID ‘NO’ THE LAST 167 TIMES YOU ASKED! SO HELP ME, YOU ASK ME ONE MORE TIME AND I WILL TIP YOU STRAIGHT INTO THE NEAREST EMERGENCY INTELLIGENCE INCINERATOR! @$#%%#@!

Sorry, where was I?

Oh, yes. Another place where Android’s lack of a clear and consistent user interface is its contact management, which is surely one of the more straightforward bits of functionality any smart phone should have.

Android gives you, or perhaps “makes you take responsibility for,” a level of granularity of the inner workings of its contact database that really seems inappropriate.

It makes distinctions between contacts which are stored on your SIM card, contacts which are stored in the Google contact manager (and synced to the Google cloud), and contacts which are stored in other ways. There are, all in all, about half a dozen ways to store contacts–card, Google cloud, T-Mobile cloud, phone memory card. They all look pretty much the same when you’re browsing your contacts, but different ways to store them have different limitations on the type of data that can be stored.

Furthermore, it’s not immediately obvious how and where any particular contact is stored. Things you might think are being synced by Google might not actually be.

And worse, you can’t, as near as I was ever able to tell, export all your contacts at once. Oh, you can export them, all right; Android lets you save them in a .vcf file which you can then bring to another phone or sync with your computer. But you can’t export ALL of them. You have to choose which SET you export: export all the contacts on your SIM card? Export all your Google contacts? Export all your locally-saved-on-the-phone-memory-card contacts?

When I was in getting my second warranty replacement phone, I asked the technician if there was an easy way to take every contact on the phone and save all of them in one export. He said, no, there really isn’t; what he recommended I do was export each group to a different file, then import all those files to my Google contact list, and then finally delete all the duplicates from all the other contact lists.

It worked, but seriously? This is stupid user interface design. It’s a user interface misfeature you might not ever encounter if you always (though luck or choice) save your contacts to the same set, but if for whatever reason you haven’t, God help you.

Yes, I can see why you might want to have separate contact lists, stored and backed up separately. No, that does not excuse the lack of any reasonable way to identify, sort, and merge those contact lists. C’mon, Google engineers, you aren’t even trying.

And speaking of brain-dead user interface design, how about this alert?

What the fuck, Google?

Okay, I get it, I get it. WiFi sharing uses a lot of battery power. The flash uses battery power. Android is just looking out for my best interests, trying to save my battery…

…but don’t all the Fandroids carry on about how much better Android is because it doesn’t force you to do what it thinks is best for you, it lets you decide for yourself? Again I say, what the fuck, Google?


So far, I have complained mostly about the visible bits of Android, the user interface failings and design decisions that demonstrate a lack of any sort of rigorous, cohesive approach to UI design.

Unfortunately, the same problems apply to the internals of Android, too.

One early design decision Google made in the first days of Android concerns the way it handles screen redraws. Google intended for Android to be portable to a wide range of phones, from low-end phones to full-featured smartphones, and so Android does not make use of the same level of GPU acceleration that iOS does. Instead, it uses the CPU to perform many drawing tasks.

This has performance and use implications.

User interface drawing occurs in an application’s main execution thread and is handled primarily by the CPU. (Technically speaking, each element on the screen–buttons, widgets, and so on–is rendered by the CPU, then the GPU handles the compositing.) That means that applications will often block while screen redraws are happening. On HTC Sense, for instance, if you put a clock on the home screen and then you start switching between screens, the clock will freeze for as long as your finger is on the screen.

It also means that things like populating a scrolling list is far slower on Android than it is on iOS, even if the Android device has theoretically better specs. Lists are populated by the CPU, and when you scroll through a list, the entire list is redrawn with each pixel it moves. On iOS, the list is treated as a 2D OpenGL surface; as you scroll through it, the GPU is responsible for updating it. Even on smartphones with fast processors, this sometimes causes noticeable UI sluggishness. Worse, if the CPU is interrupted by something else, like updating a background task or doing a memory garbage collect, the UI freezes for an instant.

Each successive version of Android has accelerated more graphics functions. Android 4 is significantly better than Android 2.3 in this regard. User input can still be blocked during CPU activity, and background tasks still don’t update UI elements while a foreground thread is doing so (I was disappointed to note that in Android 4, the clock still freezes when you swap pages in HTC Sense), but Android 4’s graphics performance is way, way, waaaaaaay better than it was in 2.3.

There are still some limitations, though. Because UI updates occur in the main execution thread, even in Android 4, background tasks can still end up being blocked while UI updates are in effect. This actually means there are some screen captures I wanted to show you, but can’t.


One place where Android falls down compared to iOS is in its built-in touch keyboard. Yes, hardcore geeks prefer physical keyboards, and Android was developed by hardcore geeks, which might be part of the reason Android’s touch keyboard is so lackluster.

One problem I had in Android 2.3 that I really, really hoped Android 4 would fix, and was sad to note that it didn’t, is that occasionally the touch keyboard just simply does not work.

Intermittently, usually once or twice a day, I would bring up an app–the SMS messenger, say, or a notepad, or the IMO IM messenger, and I’d start typing. The phone would buzz on each keypress, the key would flash like it does…but nothing would happen. No text would be entered.

And I’d quit the app, and relaunch it, and everything would be fine. Or it wouldn’t, and I’d quit and relaunch the app again, and if it still wasn’t fine, I’d reboot the phone, and force quit Google Maps in the task manager, and everything would be fine.

I tried very hard to get a screen capture of this, but it turns out the screen capture functionality doesn’t work when your finger is on the touch keyboard. As long as your finger is on the keyboard, the main execution thread is busy drawing, and background functions like screen grabs are blocked.

Speaking of the touch keyboard, there’s one place iOS really shines over Android, and that’s telling where your finger is at on the screen.

That’s harder than it sounds. For one, the part of your finger that first makes contact with the screen might not be where you think it is; it’s not always right in the middle of your finger. For another, when your finger touches the screen, it’s not just a single x,y point that’s being activated. Your finger is big–when you have a high-resolution screen, it’s bigger than you think. A whole lot of area on the touch screen is being activated.

So a lot more deep programming voodoo goes on behind the scenes to figure out where you intended to touch than you might think.

The keys on an iPhone touch keyboard are physically smaller on the screen than they are on an Android screen, and Android screens are often bigger than iOS screens, too. You’d think that would mean it’s easier to type on an Android phone than an iPhone.

And you’d be wrong. I have found, consistently and repeatably, that my typing accuracy is much better on an iPhone than an Android phone, even when the Android phone has a bigger screen and a bigger keyboard. (One of my friends complains that I have fewer hilarious typos and bizarre autocorrects in my text messages now, since I switched back to the iPhone.)

The deep voodoo in iOS appears to be better than the deep voodoo in Android, and yes, I calibrated my touch screen in Android.

Now, you can get third-party keyboards on Android that are much better. The Swiftkey keyboard for Android is awesome, and I love it. It’s a lot more sophisticated than any other keyboard I’ve tried, no question.

But goddamnit, here’s the thing…if you pay hundreds of dollars for a smart phone with a built-in touch keyboard, you shouldn’t HAVE to buy a third-party keyboard to get good results. Yes, they exist, but that does not excuse the pathetic performance of the stock Android keyboard! It’s like saying “Well, this new operating system isn’t very good at loading files, but that’s not a problem because you can buy a third-party file loader.” The user Should. Not. Have. To. Do. This.

And even if you do buy it, you’re still not paying for the amount of R&D that went into it. It’s a losing proposition for the developer AND for the users.


My new iPhone included iOS 6, which feels much more refined than Android on almost every level.

I would be remiss, however, if I didn’t mention what a lot of folks see at the Achille’s heel of iOS: its Maps app.

Early iPhones used Google Maps, a solid piece of work that lacked some basic functionality, such as turn-by-turn directions. When I moved to Android, I wrote about how the Maps app in Android was head, shoulders, torso, and kneecaps above the Maps app in iOS, and it was one of the best things about Android.

And then Android 4 came along.

I don’t know what happened to Maps in Android 4. Maybe it’s just a problem on the Sensation. Maybe it’s an issue where the power manager is changing the processor clock speed and Maps doesn’t notice. I don’t know.

But in Android 4, the cheery synthesized female voice that the turn-by-turn directions used got a little…weird.

I mean, it always was weird; you should hear how it pronounces “Caesar E. Chavez Blvd” (something Maps in iOS 6 pronounces just fine, actually). But it got weirder, in that it would alternate between dragging like a record player (does anyone remember those?) with a bad motor and then suddenly speeding up until it sounded like it was snorting a mixture of helium and crystal meth.

It was a bit disconcerting: “In two hundred feet, turn llllllllllleeeeeeeeeeffffffffftttttttt oooooooooonnnnnnnnn twwwwwwwwwwwwweeeeeeeeeeennnnnnnnttttyyyyyyyy–SECONDAVENUEANDTHENTURNRIGHT!” There was never a rhyme or reason to it; it never happened consistently on certain words or in certain places.

Now, Maps on iOS has been slammed all over Hell and back by the Internetverse. Any mapping program is going to have glitches (Google places a street that a friend of mine lives on about two and a half miles from where it actually is, in the middle of an empty field), but iOS apparently has a whole lot of very silly errors.

I say “apparently” because I haven’t personally encountered any yet, knock on data.

It was perhaps inevitable that Apple should eventually roll their own app (if by “roll their own” you mean “buy map data from Tom Tom”), because Google refused to license turn-by-turn mapping to Apple, so as to create a product differentiation point to make bloggers like me say things like “Wow, Google’s Android Map app sure is better than the one on iOS!” That was a strategy that couldn’t last forever, and Google should have known that, but… *shrug* Whatever. Since Google lost the contract to supply the Maps app to Apple, they took a hit larger than their total Android revenue; if they want to piss it away because they didn’t want Apple to have turn-by-turn directions, I think they really couldn’t have expected anything else.

In part 3 of this thing, I’ll talk about T-Mobile, and how they’re so hopelessly dysfunctional as a telecommunication provider they make the North Korean government look like a model of efficiency.

Oh, Windows, how I love to hate thee…

Windows 7 is the best version of Windows I’ve ever used, and I’ve used literally every version of Windows since Windows 3.0.

But it’s still built on a foundation of crap, with its ugly kludges and hacks like the fact that the Recycle Bin is basically a single-file database that deleted files get copied into, because back in the day they couldn’t think of a more graceful way to handle what would happen if you threw away two files with the exact same name.

And every so often, it shows.

And when that happens, you sigh, roll your eyes, and just keep on going.

Of Android, iOS, and the Rule of Two Thousand, Part I

A year and change ago, I traded in my iPhone 3G for an Android phone.

I blogged about my initial experience and first impressions of Android here. The phone I got was a then top-of-the-line HTC Sensation 4G, which was at the time I got it T-Mobile’s flagship Android phone. And for a short while, I quite liked it.

A lot can change in a year. When the new iPhone comes out in a couple of weeks, I plan to jump back to iOS and never look back.

Before I go any further, I should take a moment to step back and talk about how I feel about computing devices. I’ve been using computers since the days of the TRS-80; I got my first computer in 1977. And computer Holy Wars have been around for just as long. Back then, it was the TRS-80 vs. the Apple II vs. the Commodore 64; today, it’s Windows vs. Mac vs. Linux. Same song, different dance. What’s amazing to me is that even the arguments haven’t changed very much.

A lot of it, I reckon, comes from good old-fashioned need for validation. When you get a computer or a smartphone, you’re actually buying into an entire ecosystem, one that has a relatively high cost of entry (it takes time–quite a lot of it–to learn an operating system, and if you buy any software, you’re locked in at least to some extent to your choice. Sure, you can do what I do and run Mac OS, Windows, and Linux side by side in virtualization, but doing that has a significant barrier to entry of its own; it’s not what typical home computer users do.)

It;s hard to admit that when you’ve just spent a lot of dosh on a new box and crawled up that painful learning curve to teach yourself how to use it, you might have made a mistake. So people validate their choices, largely by convincing themselves of how awful the alternative is.

I’ve been using (and programming) Microsoft-run boxes since the days of MS-DOS 2.11 and Macs since System 1.1. In that time, I’ve developed a principle I call the Rule of 2,000, which put simply says that anyone with less than 2,000 hours’ worth of actual, real-world, hands-on experience with some platform or operating system is completely unqualified to hold an opinion about it, and anything they say about it can be safely disregarded.

So now I have a years’ worth of Android experience under my belt. What have I learned from it? Well, I’m glad you asked.


PART I: THE HARDWARE

Let’s start with the phone itself. My HTC Sensation, on paper, looks a lot better than an iPhone. It has a larger screen, a significantly better camera than what was available from Apple at the time, a replaceable SD-Micro card that means upgrading storage is quick and easy to do, and a 4G LTE data connection. By the specs, it is a phone significantly superior to the iPhone at the same time.

One of the problems that computer–and, lately, cell phone–Holy Warriors have never quite grasped, though, is that technical specs don’t tell the whole story. In fact, tech specs by themselves don’t make for a compelling product at all, except perhaps to a handful of rabid geeks. Steve Jobs grokked this. Geeks don’t.

The HTC Sensation suffers from a number of design flaws, probably the result of engineering choices designed to keep costs down.

When you hold a Sensation and an iPhone, the Sensation feels cheap. It has a removable cover, which allows easy replacement of the battery…but the cover isn’t especially tight and doesn’t fit as well as it could, making the phone feel a bit creaky. It’s plastic rather than metal and industrial glass. Geeks will claim that the packaging doesn’t matter, but they’re wrong; even the most hardcore geek would be unlikely to buy a computer housed in a plain cardboard box.

More importantly, though, I am currently on my third HTC Sensation, in a bit over one year.

When I got the Sensation, zaiah urged me to pay for the unlimited replacement warranty, and I’m glad I did. The phone has failed twice on me, both times in exactly the same way. First, the GPS starts acting flaky, taking longer and longer to acquire a signal. Then, the phone starts getting really hot when the GPS radio is on. Finally, the GPS radio fails completely, and any attempt to run a program that uses the GPS causes the phone to either freeze so hard I had to take the battery out to reset it, or crash and reboot.

I quickly got accustomed to seeing these screens in this order:

Those of you who have met me in person know that I have the navigational sense of a drunken baboon on acid; when I don’t have GPS, it is a Very Big Deal. The second phone’s GPS finally failed completely while I was on my way to a distant city a couple hours’ drive from home to meet with a new sweetie, and probably cost me at least an hour and a half spent with her…but I digress.

You will note that the signal bars in these screenshots are all over the map. This has been an unending part of my experience with Android, though I think it’s more down to T-Mobile than to Android itself. T-Mobile advertises full 4G coverage in Portland, and that’s technically true, though there are more holes in that coverage than there are in Ayn Rand’s understanding of American history. I can be traveling down Stark street right outside my house and go from awesome signal to no signal and back again in the span of six blocks. At one friend’s house, I have zero coverage, but at the corner shop down the street, I have four bars. WTF, T-Mobile?

Now, it’s possible I’m a statistical fluke and there’s nothing intrinsically wrong with the GPS radio in the Sensation. However, when I took the second failed phone into the T-Mobile store to request a replacement, the bearded hipster behind the counter told me his Sensation had the same fault as well, so I doubt it.


WAIT FOR IT…WAIT FOR IT…

An issue this phone has always had since Day 1 is a perceived sluggishness and general, overall lack of responsiveness.

I’m not 100% sure if this is a hardware or software issue. Certainly, the processor and RAM in this phone were both much better than in my iPhone 3G, so it should have plenty of grunt for a fluid UI. Yet using this phone often feels like trying to wade through frozen molasses in zero G. I saw, and still see, these messages frequently:

I tried rather a lot of faffing to make the phone more responsive (using a task killer to kill unnecessary processes and services, that sort of thing), and never got it to be good. The update from Android 2 to Android 4 was supposed to take care of a lot of this issue, but it would seem that “taking care of the issue” really meant “putting a prettier wait icon on the dialog.” (That’s Android 4 in the middle, up there.)

This is, I think, down to both hardware and software; a lot of the UI in iOS is hardware accelerated, because Apple makes the hardware and therefore can be sure that it will have the GPU to support hardware acceleration.

One interesting thing about Sense, HTC’s user interface: When you touch the screen, background processes and background updates to the UI are totally suspended. This means that, for example, when you start to slide from one panel to the next, the clock freezes. It also means you can’t do screen captures when you have your finger on the screen–something that’s actually significant, and that I’ll get to in part 2 of this piece, where I talk about the software.


OH, WHO’S A DIRTY PHONE? YOU ARE! YOU DIRTY, DIRTY PHONE!

Most of the time, I keep my phone in my pocket.

As it turns out, with the Sensation, that’s not a very wise thing to do.

The Sensation, like nearly every other smartphone I’ve used, has a little wake/sleep button on the top. You press it to wake the phone up. With the Sensation, the button’s mechanism is part of the back case, which wraps around the top; the button is just a little bit of plastic that presses down on the actual switch, mounted to the phone’s circuit board.

The plastic bit isn’t well sealed against dust and debris. When I say “isn’t well sealed,” what I mean by that is “isn’t sealed at all.”

Now, maybe the engineers who designed it have Class 5 cleanrooms in their pants. I don’t know. I do know that my pants are a considerably less clean environment.

In practice, what that means is that little bits of dust and grit get into that button, gradually rendering it inoperable. There’s a ritual I have to go through every couple of months: take the back off, blow all of the crap out of that little button, put the back on again. This is not something I experienced with my iPhone, despite years of carrying it in some astonishingly grungy pockets.

Even if you do have a Class 5 cleanroom in your pants, you’re still not well-advised to carry your Sensation there, because of an odd quirk the phone has which I’ve never been able to figure out.

Well, perhaps it’s less a quirk than a habit. Every so often, usually a few times a week, the phone will suddenly start heating up, until it becomes uncomfortably warm. All three of my Sensations have done this.

I’ve never found a pattern to it. It can happen when the cell signal is weak or strong. It can happen when the phone is on 4G or WiFi. It happens with no discernible background activity going on. There seems to be no rhyme or reason to it. I’ll just be riding in the car or sitting in front of the computer watching Netflix or hanging out with a bunch of friends, and wham! My pants are scorching hot. Rebooting the phone usually, but not always, solves the problem.


Technical specs do not, of and by themselves, make for desirable hardware. I really, really wish more people understood this.

Most of my complaints about the hardware of the Sensation come down to the same thing: attention to detail. Whether it’s attention to detail in the switch or attention to detail in the user interface, detail matters.

Geeks love hardware specs. DGeeks drool over the newest processor with twenty-four overclocked turboencabulators per on-die core and hardware twiddlybits with accelerated inverse momentum. And I think that’s a problem, because they don’t get that hardware specs by themselves aren’t enough.

Attention to detail is harder. It’s not enough to have the fastest possible processor in your phone, if the user interface is sluggish. It doesn’t matter if the phone has a shiny OLED backlight if dirt and grit keep getting into it because nobody paid close attention to the little plastic button on top.

Android is in a lot of ways the triumph of the geek over the designer. True Believers like to brag that Android outsells iOS phones because the geek cred of Android is so much better; personally, I suspect that it might have something to do with the fact that you can buy an Android phone for about $75 without a contract, and get one for free with a contract, from a large number of different places.

But that’s not really the issue. The issue, as I see it, is that my Sensation is clearly a superior phone on paper to my old iPhone, but the experience of owning it has left a very bad taste in my mouth.

Detail matters. Little things matter. The Android contingent of the Holy Warriors had an opportunity to make me a convert, and they failed.

In the next part, I’ll talk about the software, and how even after several major revisions, Android still has some things it can learn from iOS.

Some Thoughts on Design and Humane Computing

A couple of weeks ago, someone on a programming mailing list that I read asked for advice on porting a Windows program he’d written over to the Mac. Most of the folks on the list, which is dedicated to Windows, Linux, and Mac software development, advised him that simple ports of Windows software generally tend to fare poorly on the Mac. Mac users tend not to like obvious ports from the Windows world, and several folks suggested that he might need to do some rejiggering of his program;s interface layout–moving buttons, repositioning alert icons, and so on–so that they fit the Mac guidelines better.

Which is true, but incomplete, and misses what I think is a really important point about software design. Or any kind of design, for that matter.


Right now, as I type this, Apple and Samsung are involved in a nasty patent spat concerning infringement of certain Apple user interface patents for cell phones. A lot of folks commenting from the sidelines on the spat tend to paint Apple as a villain, usually on the grounds that the patents in question (which generally relate to things like how searches work and so on) are “obvious,” and therefore shouldn’t be patentable at all.

Leaving aside entirely the question of whether or not Apple is the bad guy, the fact that so many folks deride the user-interface patents in question as “obvious” demonstrates a couple of important principles.

The first is that many computer geeks don’t understand design, and because they don’t understand design, they have contempt for it. (It is, unfortunately, a very common trait I’ve noticed among geeks, and particularly computer geeks, to assume that if they lack some particular skill, it’s only because that skill is trivial and not really worth bothering about.)

The second is that people tend not to pay attention to design unless it’s bad. Good design always looks obvious in hindsight, when it is noticed at all.


Today, touch-screen smartphones have generally settled on the same overall user interface idea: a series of virtual pages, accessed by swiping, which contain icons that can be touched to launch applications. But it wasn’t so long ago that such a simple and obvious user interface was unknown. Case in point: The first Windows CE devices.

The Windows CE-based smartphones used the same metaphor as Windows desktop systems: a “desktop” onto which you could place icons, and a tiny “start” menu in the corner of the screen which you would touch with a stylus or move a virtual mouse pointer over with a set of arrow keys or a rocker button to bring up a menu of applications.

This user interface succeeds on desktops but is an abject, epic failure on small screen devices because it simply isn’t designed for a different usage environment. Yet this, and things like it, were the norm for handheld devices for years, because nobody had come up with anything better. Nowadays we look at Android or iOS and marvel that anyone could be so dumb as to attempt the Windows desktop interface on a phone. Good design always looks obvious in hindsight.


So back to the mailing list.

Several of the responses the guy who wanted to port his software received concerned learning things like the ‘correct’ button placement and icon size on Mac systems. But that does not, I think, really address the central problem, which is that Mac users (and I know I’m going to get some flak for saying this) are accustomed to a higher level of design than Windows users are.

And there’s more to design than how big the icons are or where the buttons are placed. Way too many people have this notion that design is something you bolt onto an application after it’s finished; you make the program do what it should do, and then you call Joe the graphics guy from the other side of the building, who isn’t a real programmer but knows how to do some graphics stuff to make it all look pretty.

Back in the early days of the Mac, Apple released a rather hefty book called “Macintosh Human Interface Guidelines.” I had a copy of it for a long time. It’s quite thick, and covers almost every aspect of user interface design. Yes, there are a lot of bits about how many pixels wide an icon should be and where a button should be placed on a window, but it goes way beyond that, into program flow, error handling, and a lot more.

It’s a book I think all programmers should read, regardless of what environment they program for.

I don’t think Windows has ever had an equivalent to this book. Window prior to Windows 95 didn’t seem to have any such book, at least not that I can find. The earliest published document I can find for Windows was produced in 1995, and was quite short, covering nowhere near the depth of program design as the Mac version. A PDF is available here. I’m pretty sure Linux hasn’t either, though individual user interface shells may. (Gnome has one, and so does KDE; Unity seems not to.) And I think that helps contribute to the contempt that many programmers have for design, and to the notion that design is “pretty pictures that you put into the dialogs after the program is done.”


I wrote a reply on the list outlining some of the difficulties Windows programmers face when trying to port to the Mac. The considerations do include where to position user interface elements on the screen, of course; Mac programmers expect a certain consistency. But there’s a lot more to it. Here’s what I wrote:

The issue with Mac software isn’t one of following a list of guidelines, in my experience, so much as one of practicing good design.

The principles in the Apple Human Interface Guidelines tend to promote good design, but there are many applications that don’t follow them (even applications from Apple) yet still give the ‘user experience’ that Mac users want. It’s about good, thoughtful, humane design, not about how big the buttons are or what fonts are used or how many pixels away from the edge of the window the buttons are located.

“Design” is a difficult concept, and one that a great many programmers–even good programmers–don’t have a good grasp of. There are a lot of terrible applications out there (on all platforms), though in the years I’ve been using Macs, Windows, and Linux I’ve found that Mac apps generally tend to be better designed than apps for the other two platforms. Indeed, Linux in particular tends to reward inhumane application design, enshrining programs with great power but also with an obtuse, cumbersome, and heavy user interface that is opaque to anyone without a thorough understanding of the software. EMACS is arguably one of the greatest examples of software utterly divorced from humane design. (Before anyone accuses me of engaging in partisan holy wars, I started using MS-DOS at version 2.11, Windows at 3.0, and Macs at System 1, and I’ve been using Linux since about 1998. I first came to EMACS on a DECsystem-20 running TOPS-20; before that, I used TECO on a PDP-11.)

Humane application design extends way beyond pretty pictures in the splash screen and memorizing lists of rules about where to put buttons on a screen. The principles of humane design are probably outside the scope of one email on an email listing, but they include things like:

Clarity. A well-designed user interface strives, as far as is reasonably possible, for simplicity, obviousness, and clarity. Functions presented to the user should be done in a logical and comprehensible manner, with similar functions presented in similar ways and available options described in the clearest possible language.

Consistency. Different areas of the software’s human interface should be designed, as far as is possible, to be both visually and functionally similar. If the user changes from one mode to another, she should not be presented with a jarringly different interface that is arranged entirely differently. Functions that are common to all areas or modes of the software should continue to work in the same way. The Microsoft Office suite is an example of a set of programs with poor consistency; in each of the parts of the suite, the same functions are often located in different places, under different menu items.

Predictability. Humane software does not modify or delete the user’s information without the user’s express permission. Consequences of user action, especially action that might involve loss of data, should be clearly communicated. User choice should be presented in a way that clearly communicates the results of the choice; for example, an inhumane, poorly-designed dialog box might read “A network error occurred” with buttons reading “OK” and “Cancel,” as the user is presented with no clear way to predict what pressing each of those buttons will do.

Ideally, buttons should be labeled verbs, which help to communicate the consequences of making a selection as rapidly as possible. It’s not great design to have a dialog box reading “A network error occurred; try again?” with buttons labeled “Yes” and “No.” Better is a dialog box with buttons labeled “Try Again” and “Disconnect.”

Clear communication. There’s a great example of this in the Apple Human Interface guidelines. A poorly-designed error message for a text entry field might read “Improper data format entered.” A better error message might read “”Numeric entry only.” A well-designed error message might read “The ZIP code must be five numbers or five numbers with a dash and four numbers.” The software communicates what is expected in a way that is easy for the user to understand, even when (in fact, especially when) an error condition is encountered.

Resilience. The design of the software should strive, as far as is possible, to preserve user input and user data even in the event of some sort of error condition. This means, for example, that the software will not discard everything the user has entered up to that point if the user types an incorrect ZIP code; the software will not lose the user’s input without warning if the user leaves one mode and enters another mode (for example, if the user types part of a shipping address, then backs up a screen to change the discount code she has entered), and the software will always make it clear if data will be or have been lost.

Forgiveness. The user interface should, as far as is possible, be designed to forgive mistakes. This includes such obvious things as Undo functionality, which in this day and age even the most inhumane software implements because it’s become part of the cultural set of expectations from any software. Better implementations include the ability to Undo after the user has done a Save or a Revert to Saved (Adobe applications consistently implement this). Humane software will not irrevocably destroy a user’s data at the click of a wrong button, will attempt insofar as is possible to recover data in the event of a crash (applications like Microsoft Word are quite good at this, though it’s not always technically possible in, say, large graphics editing apps).

Familiarity. Good design does not have to be beholden to the past, but if you’re presenting the user with a completely unfamiliar experience, expect resistance. When a person gets into a car, she expects certain things from the user interface; replacing the steering wheel and pedals with a joystick and the windshield with a holographic projector might be appropriate for a concept car or a science-fiction movie, but probably isn’t for the next-generation Chevy Lumina. If you change things about the expected user experience, make sure you have a clear and compelling reason to do so; don’t violate the user’s expectations merely because you can. This, unfortunately, is the only place where many programmers feel design is important, and is where rules such as the fonts used in buttons and the distance the buttons are placed from the edge of the window come into play.

Responsiveness. The application should be designed in such a way as to remain responsive to the user as often as possible in as many conditions as possible, and throw as few roadblocks in the user’s way as possible. This goes beyond simply shifting CPU-intensive operations into their own thread, and encompasses a number of architectural, coding, and human interface choices. For example, humane software is modeless wherever possible; use modal dialogs that block user activity only where absolutely necessary and where no other design decisions can be made. Make it clear what window or data is affected by a modal dialog (this is a place where I believe the design and implementation of Windows falls short, and the Mac’s “sheet” window is a significant human interface win.) If you must use a modal window, seek wherever possible to allow the user to clear the fault within the modal window, rather than forcing the user to dismiss the modal dialog and then go back a step to fix whatever the problem is.

There’s a lot more, of course, but the basic point here is that good design isn’t something that you glue onto a program with pretty icons and controls that follow all the rules. It’s something that has to be baked in to an application from the ground up, and for better or for worse it is my observation that the users’ expectations of good design techniques tend to be higher on Macs than on other systems.

Woohoo! A cease and desist email!

This is actually the second time I’ve received a cease and desist demand in regards to a Web site that I run. And boy, is it a strange one.

So some of the readers of this blog may be aware that I run a Web site called Fine Tuned Mac, which is a Macintosh technical troubleshooting forum. It was born when C-Net bought the largest Mac forum site, MacFixIt, so that they could shut it down and direct traffic to their own rival Mac site.

Anyway, this evening, the following gem of an email appeared in my inbox, which I reproduce in all its glory for your entertainment:

From: brandprotection@ip-rosettastone.com
Subject: finetunedmac.com – Notice of Infringement of Intellectual Property Rights of Rosetta Stone Ltd. [Case #70995]
Date: December 1, 2011 9:37:35 AM PST
To: Franklin Veaux
Cc: Brandenforcement@RosettaStone.com
Reply-To: brandprotection@ip-rosettastone.com

To whom it may concern:

This is to inform you that a website you manage, finetunedmac.com, has come to the attention of Rosetta Stone Ltd. (“Rosetta Stone”).

Rosetta Stone’s automated monitoring software continually monitors, collects and stores instances of unauthorized use, sales or other violations of Rosetta Stone’s intellectual property rights on the Internet. Our records indicate that your site, finetunedmac.com, has employed an advertising or sales campaign that may have incorporated Rosetta Stone products and/or trademarks or terms confusingly similar thereto.

In order to ensure your compliance with our request, you should (i) delete “Rosetta”, “Rosetta Stone” and any variations thereof, from your search engine keyword list, and (ii) add “-Rosetta” and “-Rosetta Stone” as negative keywords (negative matching) to your search engine keyword list. If you have questions, the search engine websites explain how this is done.

We believe that there is no legitimate reason or basis for you to rely on any Rosetta Stone trademark, image or product in your marketing or sales campaigns, and encourage you to review all of your advertising campaigns and sites to avoid such practices in the future.

Sincerely,

BrandEnforcement@rosettastone.com
Rosetta Stone Ltd.


Now, there are a number of things about this email that jump out at me, the first and perhaps most relevant being that Fine Tuned Mac doesn’t have a marketing or advertising budget, and the second being that if we did have a marketing or advertising budget, advertising the site using Rosetta Stone’s logo or trademarks wouldn’t do fuckall for us, since our target demographic is Mac geeks rather than hipsters who think they can get laid if they learn Italian.

So I wrote them this reply. What do you think, too formal?


To whom it may concern:

Your IP department appears to have gone mad.

I can’t tell if it’s too much time spent listening to crappy language tutorials on CD or too much time spent shooting moodily lit photographs of said CDs to appear in Skymall magazine, but Fine Tuned Mac does not, and never has, used any Rosetta Stone image, product, brand name, trademark, or any other intellectual property for any reason.

In fact, I am quite baffled (German: verdutzt; French: déconcerté; Italian: sconcertato; Finnish: hämmentynyt) by your email. Try as I might, I can not make head nor tail of what you’re talking about. Fine Tuned Mac is a free forum-based Macintosh technical troubleshooting site. We have no marketing campaigns, and the only Google ads we’ve ever run have focused solely on Macintosh troubleshooting terms.

Now, I can perhaps, if I squint REALLY hard, perhaps see where you might have run off the rails, insofar as there are troubleshooting threads on the Fine Tuned Mac Web site that talk about Rosetta. However, what you may not know is that Rosetta is Apple’s trade name for their proprietary real-time interpreter that permits machine code written for PowerPC processors to run on Intel-based computers. If you’re unfamiliar with any of those terms, you might find a Google search enlightening.

Should you have a problem with Apple’s use of the word “Rosetta,” I respectfully (well, as respectfully as I can manage, anyway) suggest you take this up with Apple’s intellectual property lawyers.

I trust this concludes your interest in Fine Tuned Mac.

Regards,
Franklin Veaux

From iPhone to Android

A few weeks back, I decided I needed to replace my aging iPhone 3G.

I got the 3G when it first came out. My roommate at the time and I spent quite a while waiting in line in front of the Apple store, only to be told when we were two places from the door that the stock for the day had been sold out. t took several more days of waiting in line before we were able to get our hands on one.

The iPhone 3G was the first smartphone I’d ever owned. I’ve been a cell phone user for quite some time, since the days of giant handsets with one-line LED displays, but I’d never owned anything even remotely approaching a smartphone before. For me, the iPhone was a game-changer. I have a notoriously bad sense of direction–it is not impossible for me to get lost just a few blocks from my home–and the GPS feature alone in the iPhone was a huge improvement in my quality of life.

Having real Web access was also a big deal. I do a lot of IT work, and the ability to get a call from a client and check the client’s Web site right there on the spot even if I’m not in front of a computer is huge.

But over the past few months, the 3G hasn’t been cutting it for me. The GPS is getting a little wonky, and the battery isn’t holding a very good charge any more, and the iOS 4.2 update made the phone feel a bit sluggish. On top of that, the amount that AT&T was charging me every month was enough to give me a nosebleed.

I spent a few weeks looking at several options: upgrading to an iPhone 4 and staying with AT&T, upgrading to an iPhone 4 and jumping to Verizon, and getting an Android phone.

Then Google announced the open hardware development kit for Android, and that significantly tilted the balance toward Android. The Google hardware kit for Android phones is based on the Arduino prototyping board, which I already have experience developing and programming for.

I went into T-Mobile and found that I could save quite a lot of money every month with a contract from them if I went to Android, so that’s what I did.


The phone I got and will be talking about here is the HTC Sensation 4G, running Android 2.3. It’s been an interesting, and at times rough, transition. I’ve been surprised by a number of things about Android, both pleasantly and unpleasantly.

But before I get into that, let me talk about what Android isn’t.

OPEN: IT’S THE NEW CLOSED

Android isn’t a religion. To hear many folks talk about it online, you’d think that the choice of cell phone operating systems was a religious or philosophical choice. Android, we’re told gravely, is “open.” The iPhone operating system is “closed.” To use Android is to celebrate freedom and democracy and other wonderful things; to use an iPhone is to toil under tyranny and totalitarian rule.

It’s hooey, of course. Android isn’t open, at least not in the way the religious folks say it is.

Oh, it’s open in the sense that the source code is available, kind of, eventually, when Google says it is. This sort of freedom isn’t really equal, though; Google decides who gets it when, and which partners get to have it first.

But the thing to remember is that from the perspective of the folks who make cell phone software, you aren’t the customer. The handset makers are the customer. Android is open–for them. You, as the person who buys the cell phone, get exactly as much freedom and openness as the handset maker lets you have.

On my HTC Sensation, for instance, the cell phone bootloader is locked down tighter than a nun’s–ahem. It was possible, if I wanted to, for me to jailbreak my iPhone. My Sensation? Nope, no can do. Not even the Cyanogen team has figured out how to root it yet.

The same is true for some other Android phones as well. Supposedly, HTC has had a change of heart and will be unlocking its phones in the future. It’s not clear whether this will apply to me; I’ve read one article online that says all HTC phones will be unlocked, and another that says only HTC phones not tied to a particular network or under contract with a particular carrier will be unlocked.

On the iPhone, the fact that I could, if I chose, jailbreak my phone never mattered to me; I never saw any good reason to. With Android, the fact that I can’t jailbreak it is kind of a bother, and that brings me to the second issue with Android.

SON OF THE REVENGE OF CRAPWARE: IT CAME FROM BEYOND THE GRAVE

With Android, we’re told, there is more openness in software, too. Android programmers do not have to go through any particular approval process to get their apps on your phone. The iPhone App Store is tightly regulated; apps that Apple doesn’t like aren’t available. The Android app store is an open bazaar; anyone can make any sort of app at all.

That’s not 100% true. The carriers have coerced Google into removing apps they didn’t like from the Google app store.

More to the point, though, the openness is really more for the handset maker’s benefit than for yours. With Android, we are back to the bad old days of Windows XP and Windows Vista, where each computer maker tended to stuff their computers so full of demos and third-party software and their own support applications that the term Craplets (crap applets) was devised to describe them.

Most computer manufacturers came to their senses, eventually, and cut it out. It didn’t help that some of this crapware, like HP’s support application that they bundled onto their computers, contained security vulnerabilities that let hackers pwn HP computers.

But Android phones often come so stuffed with pre-bundled crapware that, in my case at least, nearly half the available application memory is occupied right off the bat. Worse, unlike desktop crapware, the Android crapware can’t be removed without jailbreaking the phone. I’ll talk about some of that crapware in a bit.

So my experience with Android has been interesting. In the rest of this post, I’ll run down the differences I’ve found between using an Android phone and using an iOS phone, and rate the quality of everything from the handset design to the apps to the user interface. If that sounds like your thing, click here to read more!