The Refined Geek

You don’t have to read far on this blog to know that the relationship I have with Apple swings from wild amounts of hate to begrudging acceptance that they do make some impressive products. Indeed I’ve been called everything from an Apple fan boy to an Apple hater based on the opinions I’ve put forth on here so I think that means I’m doing the right thing when it comes to being a technology critic. Of course that means taking them, and their fans, to task whenever they start getting out of line and it appears that the latest instalment of Apple fans going wild comes care of the iOS 6 Maps application which I’ve abstained from covering here previously.

For the uninitiated Apple decided to give Google Maps the boot as the default mapping application on their handsets and tablets. The move was done primarily because their negotiated agreement with Google was scheduled to come to an end soon and Apple, for whatever reasons that I won’t bother speculating about, decided that instead of renewing it they’d go ahead and build their own maps application, including the massive back end cartography database. Now they’re no stranger to building a maps application, indeed whilst it used to say “Google Maps” it was in fact an Apple developed application that used the Google APIs, but the application was an unmitigated disaster. In fact it was so bad Apple even got Tim Cook do one of those “we’re admitting there’s a problem without admitting it” open letters pointing to alternatives that were available.

I held off on commenting on the whole issue because since I don’t use an iPhone any more I didn’t want to start trashing the app without knowing what the reality was. Plus I’m not one to bandwagon (unless I’m really struggling for good material) and it felt like everything that needed to be said had been said. I almost caved when I started reading apologist garbage like this from MG Siegler but others had done that work for me so re-iterating those points wouldn’t provide much value. However one bit of unabashed fanboyism caught my eye recently and it really needs to be taken to task over what they’re saying:

Situation: Apple cannot get Google to update its maps app on iOS. It was ok, but Google refused to update it to include turn-by-turn directions or voice guidance even though Android had these features forever. Apple says, “Enough” and boots Gmaps from iOS and replaces it with an admittedly half-baked replacement. The world groans. Apple has egg on its face. Google steps up it’s game and rolls out a new, free new maps app in iOS today that is totally amazing, I’m sure to stick it in Apple’s face… Ooops

Bottom line: Apple took one for the team (ate some shit) and fooled Google into doing exactly what Apple has been asking for years. Users win.

Time to get some facts on the table here. For starters way back in the day when Apple first wanted to bring maps to their platform they approached Google to do it however the terms that Google wanted (better access to user data was their primary concern) meant that an in house developed app was never to be. They could agree on good terms for the API however and so Apple developed their own application on the public Google API. This meant, of course, that they were limited to the functionality provided by said API which doesn’t include the fun things like turn by turn navigation (voice commands however are on Apple’s head to implement).

Instead of capitulating Apple decides to build their own replacement product which isn’t completely surprising given that they’ve done this kind of thing before with services like iTunes and the App Store. Claiming that it was done to fool Google into developing a better app however is total bollocks as if they were doing that they wouldn’t have spent so much money on in-sourcing so much of the infrastructure. Indeed the argument can be made that they could’ve bought/licensed one of the top map apps for a fraction of the cost in order to accomplish the same task. So no Apple didn’t do it to get Google to develop an application for them, they did it because they wanted to bring more applications into their ecosystem.

Google’s revamped map app proved to be extremely popular rocketing to the number 1 spot for free applications after just 7 hours of being available. I (in a slightly rhetorical/trolling way) put the feelers out on Twitter to see what Apple fans would have to say about that particular feat and was surprised when I got a reply within minutes. Whilst their arguments didn’t hold up to mild scrutiny (and I didn’t change their opinion on the matter) I was honestly surprised just how defensive some people can be of a product that even the company who developed it has admitted was bad. Especially when the replacement has been, by all accounts, pretty spectacular.

Apple’s trademark secrecy about its plans and intentions is what feeds into these kinds of wild theories about their overall strategy for their products and their highly dedicated fan base too often falls prey to them without giving them some routine fact checking. I don’t blame them in particular however, it’s hard to see fault with a company you admire so much, but this kind of wide-eyed speculation doesn’t do any good for them. Indeed give it a couple weeks and no one will care that there’s yet another map application on iOS and this whole thing will get filed alongside antennagate (remember that?).

I’ll be honest I had to look over my past posts of Windows Phone 7 to figure out where I used to stand on Microsoft’s latest grab for the smartphone market. Initially I was sceptical, figuring that this was Microsoft’s extremely slow reaction to their competitors gnawing away at their market share. I acknowledged the fact that Microsoft has the power of numbers working for it with masses of developers poised to take advantage of a mobile platform but recognised the fact that if they were serious about the mobile space they’d be invested in it already. Finally I came to like the platform when Microsoft upped the ante with the default feature set, including features for free that their competitors had long been charging for. However after that initial glowing review I hadn’t heard a lot about the Windows Phone 7 had been a rousing retail success nor its dismal failure so I figured it was just going to fade off into obscurity, much like their Kin did before it.

Today however brought the first bit of news that I’d heard about the platform in a long time. Whilst there wasn’t a massive land rush to acquire Microsoft’s latest offering there was a respectable amount of sales:

Sales are ramping well as our reputation is growing for offering users a unique experience and are in line with our expectations – especially when compared to other new platform introductions. With a new platform you have to look at a couple of things, first of all customer satisfaction. As I mentioned before, we’ve seen great response on the complete mobile phone experience.

Another is phone manufacturer sales – phones being bought and stocked by mobile operators and retailers on their way to customers. We are pleased that phone manufacturers sold over 1.5 million phones in the first six weeks, which helps build customer momentum and retail presence.

We know we have tough competition, and this is a completely new product. We’re in the race – it’s not a sprint but we are certainly gaining momentum and we’re in it for the long run

Some quick maths will tell you that 1.5 million handsets in 6 weeks works out to roughly 36,000 handsets sold per day. Whilst this pales in comparison to Android’s 300,000 activations and is a drop in the bucket when compared to Apple’s 230,000¹ it’s still a decent number considering the giants that they’re going up against. Since they managed to release well before the holiday buying period it will be very interesting to see how their holiday sales figures turn out as that will be telling as to how much momentum this particular platform has.

Still though for any developer looking to develop for the mobile world Windows Phone 7 is probably the last platform on their list. Developing for Apple arguably has the best potential for revenue generation from direct sales with Android providing better results from ad based programs and both of them have audiences much larger than Microsoft’s 1.5 million loyal fans. Whilst the barrier to entry might be lower for a long time Microsoft developer anyone really serious about mobile development will take the time to learn a more popular platform. The time invested in learning a new platform is nothing compared to the number of people you’ll be able to reach by developing on something other than Windows Phone 7.

Yet again I find myself back on the fence, unable to say with conviction how I feel about Windows Phone 7. In reality it looks like a solid product and the relatively decent number of sales in its first month and a half of life is definitely promising. However it’s coming to the party about a year or two late with Apple and Google both providing very mature platforms with a large, established fan base. I’d still love it if the platform became popular as it would reduce the amount of work I’d have to do but the harsh reality is that even if it does happen it’s a long time away and they’ve got a long way to go before they’re matching the numbers that Google and Apple have enjoyed for so long.

¹It’s now estimated at up to 270,000 per day, but I couldn’t find a source that states that directly.

Now I don’t consider myself to be some uber-programmer, more like your garden variety enthusiast who knows how to work his way through a Google search to find what he’s after. Still I’m often amazed to find those who call themselves programmers (and even more worrying, convince others to pay them) falling for things that really should be obvious to anyone with half a brain about them. Sure I’m not immune to making some serious logic errors or just plain WTFery but something as fundamental as not sending your users’ passwords across the Internet in such a way that anyone with freely available packet capture software or even a Firefox plugin can read them is one of those things that really should go without saying. Traditionally this is done by encrypting the connection between you and the user using SSL so that anyone listening in just sees garbage and not your user’s password.

Securing a web connection between a user and your server, in the Microsoft world at least, doesn’t take too much configuration to get it working. For my pet project it was little more than adding a line of code at the top of the API implementation, installing a SSL certificate on my server and creating a client access policy file to enable cross domain communication. All in all I went from an API that sent everything in clear text to a fully secured API in a little under 2 hours with a good half of that being spent googling and sussing out which SSL provider I was going to go with. Still it seems that nearly every month I hear of at least one big start-up or long running service that fails to implement encryption for their login details, potentially endangering their users.

The first such company that I heard about was Foursquare, a popular geo-social networking application. Now I had been using that application for quite some time before I heard about them not encrypting anything so you can imagine how I felt when I found out they had let that little detail slip their minds for well over a year. Sure they were quick to fix it but who knows it would have gone unfixed had no one said anything about it. Their close rival Gowalla also neglected to implement any sort of secure communications for almost 3 years, making me wonder how something like that could go unnoticed for so long.

It doesn’t just stop there either. Last month saw not one but two companies being outed as passing login information around in clear text. The first was Napster (yeah even I’m surprised they’re still around) who not only has no encryption on their login forms but also sends users their login credentials when trying to get them to renew. Then just 2 weeks later it was revealed that the recent hit photo sharing app Instagram was also spreading information over the web that it shouldn’t be. To Instagram’s credit they were quick on getting a fix out, but it still seems like a fundamental error to make when you’re sending sensitive data over the Internet.

For all the vitriol that I’m launching at these companies I can understand the mindset that leads up to this kind of mistake happening. For the longest time I developed everything without SSL as it made debugging the whole application that much easier. Even with Fiddler’s SSL decrypting feature it still doesn’t seem to work quite right when cracking open encrypted communications so the solution of just turning SSL off works much better. Then when it comes time to deploy not only is your app not configured to use SSL all your API calls are made to the unsecured endpoint. If you follow good coding practices the latter shouldn’t be too hard to fix (your API URL should be a global variable) but getting the web server to serve out a SSL connection can take a bit of wrangling to get done, especially if you don’t control the web server yourself. So you deploy the code and hope that no one notices as at least 5 companies have gotten away with such things for years at a time.

Security is one of those things that’s always the lowest priority until something happens that forces your hand. It’s one of the most laborious aspects of developing a system as it’s usually not very interesting and only serves to increase the amount of work you have to do. Still it is so fundamental to get these things right from the get go that it still shocks me how many multi-developer companies manage to let things like that slip through the cracks. Perhaps it’s just my system administrator background that’s made security such a primary focus for me but really it should be one of the prime considerations for anyone looking to build a system with users on the Internet.