clever/you - thoughts about mobile

Smartphones & Lighting Consoles

Mon, 13 May 2013 23:31:01 +0100

Before I started this whole programming lark, I used to work in theatres designing, rigging, and programming lighting. Just as we’ve seen smartphones bring rapid developments to the mobile space, the same technology (touch interfaces and embedded technology) has brought a lot of change to lighting.

For example, here’s a couple of desks I used to program on a lot - an ETC Express and a Strand 300.

They have a couple of things in common: lots (and lots) of buttons and faders, and a user interface that is a little…functional (think ASCII and DOS).

But here’s the latest and greatest in lighting control - the ETC Eos Ti:

…what’s changed? Well, a lot fewer faders for one thing. And there’s the two giant touch-screens up top (think two iPads glued into a lighting console). Oh, and the secondary touch-screen used as a color palette amongst other things on the right hand side. The rise of tablets and touch interfaces has brought benefits far beyond the world of mobile.

ITV, Samsung, and Exclusivity Deals

Mon, 13 May 2013 12:39:00 +0100

For a very long time, I used a Samsung Galaxy S2 as my Android phone (I engineer iOS apps, but it’s good to know what’s going on the world outside Cupertino). Unhappy with the long, long waits for software updates from Samsung, I switched a few months ago to the Nexus 4.

Being produced by Google, the Nexus 4 is the flagship Android device - so naturally you’d expect it to be an advertisement for all things Android. Unless, that is, you want to watch ITV on it.

For the benefit of those not in the UK, ITV is one of the largest TV networks in the country. Last week, they made a change to their Android app: for the next few months, at the very least, it is exclusive to Samsung devices. Here’s what ITV had to say:

> The fragmentation of the Android ecosystem is well known. Therefore, as a commercial broadcaster, it makes sense for us to partner with the leading manufacturer of Android devices to further increase our technical knowledge of the operating system.

This makes little sense: the Nexus 4, for example, is the recommended device for the development of the Android OS itself. If I was developing an Android app and wanted to maximise compatibility I’d probably target the reference device as standard.

Although ITV frame this as a technical decision, we should probably be realistic - maybe Samsung provided financial or development support to maintain some level of exclusivity. Either way, I personally don’t see an benefit for either party.

Why it’s not great for Samsung

Personally, I don’t see Samsung getting their money’s worth here. Are people going to buy Samsung handsets so they can download the ITV Player app? Presumably not, because the exclusivity period ends in a few months. People will buy Samsung handsets because Samsung spend far more money than anybody else advertising them. And, as other people have noted, it doesn’t do Samsung many favours with regards to their Google relationship.

Why it’s not great for ITV

The ITV Player app isn’t exactly doing very well on the store:

…if you are going to limit it to select handsets on the basis that you want a more stable experience then you’d better have made some improvements. Unfortunately, this doesn’t seem to be the case judging from the reviews. Additionally, many existing users who are running older versions of the player on non-Samsung devices are providing one-star reviews expressing their displeasure.

It comes down to this: exclusivity deals are not, in of themselves, a bad thing (although Trusted Reviews has a great article that offers a counterpoint to this). They can provide cash-limited companies with money to develop interesting and exciting apps. But turning a previously widely available app into an exclusive deal: that’s not so good. Users don’t like it, and I don’t see the benefit for brands…especially if your disgruntled, locked out users start giving you bad press.

A Guide to BaaS

Wed, 08 May 2013 15:53:00 +0100

Introduction

Some of my most popular posts are those about mobile backend providers Parse and StackMob. It’s been a few months since I last looked at them, and since then much has changed - so I’ve decided to take a comprehensive look at both the large and small players in the mobile backend space.

What is BaaS?

BaaS stands for backend as a service, and is used to describe a company that provides a way for front-end developers to ‘plug in’ to cloud storage, user management, push messaging, and the like without having to write and support their own server architectures.

If you’ve read some of my other blog posts you’ll know I’m a fan of BaaS. It’s not for everyone - large apps with millions of users, in particular, will of course benefit from their own internal systems - but if you’re starting out and need a quick and efficient data storage system that works across multiple platforms you can’t go wrong with BaaS.

The BaaS industry has come to be quite closely associated with mobile, partly because many companies sprung up in response to a need by native application developers for secure, reliable data management systems. There’s nothing to stop you using a BaaS provider to power your desktop web apps, but I’ll be mainly focusing on mobile here since that’s my field of interest.

BaaS Providers

Wikipedia lists some fifteen different BaaS providers - some large, and some very tiny. There are two main players in the market, the Facebook bound Parse, and StackMob. In addition, a number of smaller players are all vying for your business.

I’ve chosen to look at five different BaaS platforms and compare their strengths and weaknesses. Each provider has a brief review, followed by a pricing comparison and some general recommendations for what to look out for. Hopefully you’ll find it useful - and I’m always happy to answer questions either through Tumblr or Twitter (@objclxt). You can either read on, or jump to the provider you’re interested in:

Parse
StackMob
Kinvey
FatFractal
QuickBlox
Helios

Parse

Although not the oldest in the game, Parse is probably by far the most well known BaaS provider, if only due to it’s acquisition by Facebook last week.

Features

As standard, Parse offers support for data synchronisation, push notifications, social integration, and custom code via server-deployed JavaScript. Parse has official client libraries for iOS, OS X, Android, JS, Windows 8 (desktop and phone), and .net. There are also many third party libraries available for languages such as Ruby, PHP, Python, Go, and the like. Currently, Parse’s first-party libraries are all closed source, which is a shame (hopefully this will change under Facebook). Parse is also well known for its excellent documentation, which includes complete sample applications and walk-throughs.

Server-side code is supported through Parse’s Cloud Code feature, which is JavaScript based. In addition to your own custom code, you can also plug into third-party modules to directly integrate with services such as SendGrid, Stripe, Twilio, Mailgun, and the like. Parse also recently added support for static hosting, which allows static and JS based pages to be served up quickly and easily.

Pricing

Parse charges on a per-API request model, plus storage. Anything below 1 million requests is free, which for many low-usage projects will be more than sufficient. Their standard ‘pro’ plan provides 15 million API requests, 15 million push notifications, and 10GB of storage for $199 per month. Enterprise plans are also available with dedicated SLAs and the like.

To put that in some perspective, 15 million API calls a month lets you support 50,000 active users at 300 calls per month.

Who Uses It?

I do! Also, a number of large brands and agencies, including IDEO, Cisco, Hipmunk, BBDO, and Deloitte (it should come as no surprise that agencies tend to be big users of BaaS - they often lack backend expertise at scale, and many of their apps are for short-lived campaigns).

Pros

Acquired and backed by Facebook (…or a con, depending on your viewpoint)
Wide range of well supported SDKs
Excellent documentation

Cons

Acquired and backed by Facebook (…or a pro, depending on your viewpoint)
Client libraries are closed source
Custom ‘cloud’ code somewhat limiting compared to other providers

Stackmob

Stackmob has been in the BaaS business for a while, and along with Parse are one of the bigger players in the space. They aggresively compete, to the point where StackMob posted a “migrate from Parse tutorial” the day after Parse’s acquisition.

Features

Stackmob offer broadly the same feature-set as Parse, but with a few additions such as distinct production / development environments, API versioning, and a more comphrehensive custom code framework that supports server-side Java or Scala. Many of these advanced features are made available on a modular basis in the StackMob marketplace (but more on that below). Both the Android and iOS client libraries are open source, and available on GitHub.

Pricing

StackMob recently changed their pricing model from a usage based to a more generous ‘freemium’ model. Basic API access is both free and unlimited, but additional functionality can be ‘unlocked’ through the StackMob marketplace (if you’ve used Heroku this marketplace model will be familiar to you).

The downside of this is that depending on what you need this can end up being very expensive. For example, let’s say we want to support custom code and 5 million push messages a month. Both of these features are included in Parse’s Pro package, but with StackMob you’ll need to purchase each module separately. This ends up costing $399 for the push and $199 for the custom code, or a total of nearly $600. That’s three times as expensive as Parse for broadly equivalent functionality.

As a result, using StackMob could require some careful planning to make sure you only use the modules you absolutely require. Don’t forget to think about your future requirements when pricing up or you might have a very expensive surprise!

Who Uses It?

According to StackMob’s rather limited case studies page, the platform is used by Atari, ShopKeeper, and Meexo, amongst others.

Pros

Unlimted API calls as standard
Open source client libraries
Good documentation

Cons

Free plan has unlimited API calls, but missing functionality such as HTML5 hosting
Paid modules quickly add up

Kinvey

Based out of Boston (woo), Kinvey have been around for a couple of years with their BaaS offering. They were recently selected as a Facebook Technology Partner.

Features

Kinvey offers the usual plethora of data storage, user management, push notifications, and social integrations. They also offer versioned APIs and usage analytics. Additionally, Kinvey’s enterprise plans support existing authentication systems such as LDAP or OAuth, along with data links into products such as Salesforce CRM.

Pricing

Kinvey bases their pricing on the number of active users. An ‘active user’ is defined as one that has made an API request that month. I’m not the biggest fan of this model, because it can makes apps with large numbers of users but with small backend requirements rather expensive. Kinvey do offer API pricing as an alternative, but you’ll need to get in touch with them directly to discuss further.

Who Uses It?

A number of marketing agencies use Kinvey, presumably on behalf of their clients, as well as Johnson & Johnson.

Pros

Enterprise-level features such as LDAP, Orcale, Salesforce, and OAuth support (for those on enterprise plans)
Agencies can benefit from Kinvey’s referral program

Cons

Default ‘active user’ pricing model not suitable for all apps
No ‘custom code’ support a la Parse or StackMob, although backend business logic is supported

FatFractal

FatFractal also seem very responsive to customer requests and feedback - I actually got in touch to ask whether they supported bulk data export whilst writing this post, and they implemented it into their system overnight.

Pricing

Currently, FatFractal provide up to 3 million requests and 5GB of storage free of charge whilst in public beta. Their gold plan provides 12 million API requests and 15GB of storage for $200 per month. You should, however, be aware that unlike other providers, FatFractal charge for outgoing bandwidth overages. The gold plan include 12GB of outgoing bandwidth, and it’s $0.15/GB after that. I doubt for most people this would be a problem, but if you’re building an app that’s going to require significant bandwidth (video sharing, perhaps) you’ll need to take this into account.

Who Uses It?

In FatFractal’s defence, they are still in beta and have a limited client list as a result. They have a number of testimonials from smaller developers and agencies, and list a couple of minor apps in production.

Pros

Responsive customer service, and quick to reply to feedback
Very developer-centric business, which may appeal to some

Cons

A smaller player in the business
At the time of writing, still in beta

QuickBlox

QuickBlox’s unique selling point is its discrete ‘modules’, such as video and text chat, leaderboards, and the like. More experienced developers may find this restricting.

Pricing

QuickBlox’s pricing is probably best described as ‘opaque’. Their free tier offers unlimited API calls, and a 10GB traffic/storage limit. If you exceed this limit you’re offered three options - switching to an enterprise account (which requires a sales call for a quote), paying the hosting costs your app is consuming plus a 10% management fee (which, again, requires a sales call to get a quote), or cross-promotion sponsorship (…yep, that needs a sales call too).

It is a shame that QuickBlox are not willing to put any pricing information above their free tier on their site.

Who Uses It?

A variety of small apps, mainly being developed by marketing agencies, including the Official Dane Cook App(?) and a fan app for Liverpool FC.

Pros

Modular approach may be appealing to novice developers

Cons

Must call their sales team to get any pricing information

Helios

Helios is Heroku’s answer to the rise of ‘all in one’ BaaS providers. It’s an open-source backend framework that you can deploy directly to Heroku, or your own hardware if you prefer. It’s written by the highly respected Mattt Thompson, and combines data synchronization, push notification, in-app purchase, analytics, and passbook management into a single attractive GUI. There’s no single client library - rather, a collection of existing libraries such as AFIncrementalStore that integrate into the backend system.

Pricing

As an open-source framework, Helios is completely free. You’ll need to pay for hosting though - either on your own hardware, or through a provider such as Amazon Web Services or Heroku. Since Helios is backed by Heroku I’m going to use that as a benchmark for pricing - a basic setup with a production database and several dynos will be around $120 per month.

Who Uses It?

Many popular apps use Helios’s discrete client libraries - I’m not aware of any apps currently using Helios itself.

Pros

It’s free!
Totally open source, with hosting flexibility
Created by one of the best mobile developers out there

Cons

OK, not really BaaS as you’re going to have to manage it!
Currently best suited to iOS apps only
If you’re not comfortable with basic server admin this isn’t for you

Cost Comparison

I’ve tried to break down both the free tier limits and the price you might expect to pay for ‘typical’ use with each provider. I’ve defined ‘typical use’ as an app with 40,000 active users, 12 million API calls per month (or 300 per user), and 500,000 push notifications.

	Parse	StackMob	FatFractal	Kinvey	QuickBlox
Free Tier Limit	1m calls	‘unlimited’ *	1m calls (whilst in beta)	100 app users	10GB traffic
‘Typical’ use	$199	$399+ *	$200	$293	Unknown

* StackMob’s free tier has unlimited calls, but additional functionality that is free with other providers (such as HTML5 hosting or custom code) may cost extra. I have included StackMob’s Push module ($399) in estimating typical cost, but other modules such as custom code will add on to this figure.

Conclusion

FatFractal seems to be quite developer focused and led, whereas QuickBlox seem to be going after marketing agencies and judging by their lack of clear pricing information aren’t particularly interested in the indie space. I think Kinvey have a pretty exciting product, and their focus on enterprise integrations mean those building internal B2B apps may want to consider them.

I was initially very excited with StackMob’s new pricing structure, but the modular model they’re going for means it becomes very expensive to match Parse’s $199 plan functionality. Once you’ve added collaboration, push messaging, custom code, and hosting into StackMob’s package it becomes a very expensive proposition.

Finally, of course, there’s Parse. If you harbour negative feelings torwards Facebook you might have already made up your mind - personally, I’ve been really impressed with the speed at which Parse have added to their product, and I enjoy working with their client libraries. Who knows exactly what Facebook will do with Parse long term, but post-acquisition they’re still adding new features such as HTML5 hosting.

Don’t forget, the usability of the client libraries is just as important as the features and pricing. You’ll be working with your chosen provider’s APIs and SDK a lot - you want the experience to be pleasurable. I recommend taking a look at sample code, and maybe trying out the various libraries yourself.

Hi Nick, I am considering using Parse for a project and I read your post evaluating backends. You seem to really love Parse and have really looked at the other platforms too. Basically my biggest concern is getting started with Parse and finding out half way through that I can't finish my app. What is your experience with scale on Parse? It seems like you can also do a lot with StackMob but what about Parse makes it your top choice? I have to say I am not a dev...

Sat, 04 May 2013 12:13:37 +0100

This is a good question - I use Parse for large-scale apps with 500,000+ user accounts, and I haven’t noticed or had any reports of poor performance. Parse do limit you to around 40 API calls per second on their Pro plan, although that’s more than enough for most use cases. If you architect your app smartly you can always reduce the number of calls you need to make.

In terms of architecture, both Parse and StackMob are pretty solid. To be honest, Parse and StackMob are pretty comparable, and it’s more personal preference than anything else that means I use Parse. StackMob have changed their pricing structure quite a bit since I last compared them though - I am writing a very long comparison of a number of BaaS providers to get on the blog later this month.

The issue you’re more likely to run in to, on both Parse and StackMob, is that you’ve designed your app to manipulate data in some way that isn’t very easy to do on a BaaS platform (versus having direct access to your own database). But if you go in up-front knowing that you’re only really able to get at your data via a REST API / client libraries (vs stored procedures, direct DB access, etc) you’ll probably be fine.

Hope that helps you out!

Parse / Facebook: What Now?

Sat, 27 Apr 2013 14:18:00 +0100

You’ve probably read that this week Facebook acquired Parse, the mobile BaaS service. I’ve been using Parse for quite a well in production, and if you’ve read any of my previous posts you’ll know I quite like the service (see here, here, and here).

So what now? Does Facebook acquiring Parse change anything? Well, if you go by the press releases, no - it doesn’t. But perhaps there’s more too it than that. What should you be doing if you’re either an existing customer (like me), or someone who’s been thinking of using the service? Here’s my own thoughts on the subject.

You Already Use Parse

A lot of what you do next is going to depend on your own gut feeling. Some people have quite a visceral reaction to Facebook - I’m not one of them. What I will say is that the last time Facebook bought something I used (face.com) they ended up shutting down the APIs. But Parse is considerably bigger, and more importantly is used by some sizable customers. I personally don’t see Facebook cutting them off - and I suspect new customers will be welcomed for some time as well.

The bottom line is this: whenever you use any third-party provider to manage critical infrastructure in your apps you’d better have an escape plan. Companies get acquired, go bust, or retire products all the time. This isn’t an issue unique to Parse. If you’re not planning for the worst you’re sowing the seeds for a big headache in the future.

Parse already offer a mass-export feature that gives you all your data in JSON. You can use this, along with the Parse APIs, to migrate over to another provider fairly easily (although some scripting on your part may be required). One provider (Stackmob, who I’ve reviewed here before) even have a semi-automatic migration tool available.

You’re Deciding on a BaaS Provider

Again, this is going depend on how you feel about Facebook. If you’re not a fan, you’ve probably already made your choice. Here’s my two cents: even if Parse keep supporting existing customers, it’s almost certain that at some point in the future the product is going to change in a fairly significant way. I don’t see Facebook gaining any value from running Parse as an entirely separate entity.

I really like Parse as a product - I’ve used it in several production apps. Would I use it now? I’m not sure. I don’t necessarily think any of the competitors out there (Stackmob, Appcelerator, Kinvey, Fat Fractal, to name a few) are any more secure. If anything, financially speaking Parse is now top of the pile.

So…what?

I appreciate I haven’t really provided many direct answers. One thing this should really re-inforce, regardless of your BaaS provider, is that you need a back-up plan. To help with that I’ll be posting a new backend-as-a-service comparison in the coming weeks, updated to take into account all the recent changes in the marketplace.

Mantle: Easy JSON Models in Objective-C

Thu, 25 Apr 2013 16:38:00 +0100

OK, so it’s not a very exciting topic - but still, it can often be a pain to convert JSON into Objective-C objects. There’s a lot of boilerplate code, and you invariably end up with something like this:

…and that’s just to decode from JSON. If you need to subsequently archive your object back to JSON you’ll end up with even more brittle and lengthy code, thanks to encodeWithCoder and its counterparts. Finally, you’d better hope your JSON never changes, because in the example above if there’s no url field in the dictionary an exception is going to get thrown.

I had to deal with this problem recently - I was working with a quite complex JSON API, and I needed something to help me manage my models. Fortunately, Github have open-sourced a framework used in their own Mac application called Mantle. Mantle aims to simplify the process of working with JSON in Objective-C, particularly in places where something like Core Data might be overkill. It works without NSCoder, and uses @property declarations to provide default implementations.

Here’s an implementation of the Article example above, but rewritten to use Mantle:

A really simple JSONKeyPathsByPropertyKey method maps JSON to properties, and reversible transformers allow things like dates, URLs, or other custom formats to be both encoded and decoded easily. The value transformers also handle missing or nil fields, meaning you don’t have to worry about exceptions.

I’m really enjoying using Mantle, and it’s made my code cleaner to read and easier to maintain. The source for Mantle, along with pretty comprehensive documentation, is available on GitHub, and you can use it in your own projects via the ever reliable CocoaPods.

iOS Debugging: Three Timesaving Tools

Tue, 16 Apr 2013 11:31:00 +0100

Debugging is twice as hard as writing the code in the first place
Brian Kernighan - The Elements of Programming Style

Debugging your own code may be a chore, but debugging somebody else’s can be downright painful. A particularly bad experience last week reminded me that debugging is as much a skill as writing code itself - and just like programming, there are lots of tools that can make it both easier and even enjoyable.

Here are three really useful tools that I use when debugging iOS applications.

Technical Note 2239

Hidden away on Apple’s developer site is Technical Note 2239, or iOS Debugging Magic. It’s packed full of tips and tricks to help the frustrated iOS debugger get to grips with XCode. Unfortunately, it’s also slightly out of date, written for iOS 4.1, XCode 3, and GDB (rather than the newer LLDB debugger now standard for iOS development).

Still, it’s still broadly applicable, and it’s the only place on Apple’s site where recursiveDescription, a category extension on UIView that lets you print out a view’s complete hierarchy, is documented. This alone justifies its existence:

DCIntrospect

Command line debugging is extremely powerful, but as many web developers will tell you being able to visually debug can be just as useful. Although Apple provide some tools to do this (such as the Core Animation Instrument), a number of third party options are available to help with layout problems.

DCIntrospect is one such popular library - designed to be used with the iOS simulator, it enables a number of keyboard shortcuts to allow dynamic manipulation of views.

Installation is particularly straightforward, so DCIntrospect is a good option if you need to quickly debug more complex view hierarchy or display problems.

PonyDebugger

PonyDebugger is one of the more complex iOS debugging tools - it requires both a client on device and a server on your development machine - but it’s arguably worth it in the long run. Once installed, you can remotely debug network traffic, Core Data, and view hierarchies using Chrome’s Developer Tools. It’s maintained by the good people at Square.

The networking traffic tools in PonyDebugger supplement, rather than replace, a traditional proxy. Because networking traffic is forwarded rather than sniffed traffic sent over HTTPS/SSL is viewable without needing any special certificates. The Core Data browser is also a nice touch, and is directly integrated into the traditional Chrome dev tools ‘resources’ tab. One particularly nice feature of PonyDebugger is its ability to convert an app’s view hierarchy into a HTML-like format that can be immediately edited, just as you would a normal web site within Chrome’s developer tools.

All of these features do come at a cost, namely a somewhat complex installation - I’d recommend using CocoaPods to handle the client library. You should take care for both DCIntrospect and PonyDebugger to only enable them in your debug builds, as you definitely don’t want either library to end up in your production code.

Helios: A New iOS Open Source Backend

Wed, 03 Apr 2013 10:18:29 +0100

If you’ve read my previous posts you’ll know I’m a big fan of Parse and other Backend-as-a-Service providers. However, they’re not for everybody - especially if you need control of your own servers, or aren’t comfortable with out-sourcing your application’s data to a third-party.

With that in mind, I’m really excited about Helios, from Heroku and Mattt Thompson. Helios provides data synchronisation, push notifications, passbook, in app purchase, and analytics support ‘out of the box’. It’s open source, and - importantly - instantly deployable to Heroku (naturally). This means developers who are not willing or able to manage a full backend server stack can quickly get a full mobile backend platform running on a managed provider or hardware of their own.

Full source code and documentation is available on GitHub, and it integrates well with many standard libraries such as AFIncrementalStore. It’s good to see Heroku moving into the mobile backend space, and I’m sure there will be a number of Helios backed app in the iTunes Store soon.

Helios, the God of the Sun. Not the mobile backend.

State Preservation & Restoration

Mon, 18 Mar 2013 10:32:00 +0000

One of the new features in iOS 6 that hasn’t exactly been shouted out from the rooftops is state preservation, probably because on paper it’s far from exciting. However, having implemented it into an app I’ve realised there are some great benefits - not least of which is making your users happier.

What it does

State preservation is designed to solve the problem of app termination. The majority of iOS users don’t know the difference between application backgrounding and application termination. Anecdotally, many people who test the apps I work on are unaware that removing apps from the ‘recent apps’ list terminates them completely.

This can result in quite a confusing and frustrating experience: sometimes coming into an app will take you back to where you were last, and at others you’ll be back to square one. Some developers had attempted to solve this by keeping track of the current app state and attempting to restore it upon relaunch. Inevitably this led to a number of different approaches, some good and some bad.

The good news is that iOS 6 now offers state preservation out of the box, and enabling it is a simple two step process:

How to enable it

Step 1: Label your Controllers

To keep track of a user’s journey through an app you need to provide restoration identifiers for your view controllers. You can identify as many or as few controllers as you wish, but only controllers with restoration identifiers present will automatically instantiated and navigated to by iOS upon launch.

If you’re working with XIBs you can add identifiers within Interface Builder - and with Storyboards it’s even easier (since Storyboards already track a user’s progress through an app). In code you can simply set the restorationIdentifier property.

Step 2: Opt In to Restoration and Preservation

Currently, state preservation is ‘opt in’. To opt in you need to implement three methods in your application delegate, described below:

- (BOOL)application:shouldRestoreApplicationState:
Sometimes you might not want iOS to automatically restore the user’s state: perhaps your app has had a major UI update, and the area of the app your user was last in no longer exists. You should return YES to enable restoration.

- (BOOL)application:shouldSaveApplicationState:
As above, except this method is called when you application is terminated. Again, return YES to allow iOS to save the most recent state information.

- (BOOL)application:willFinishLaunchingWithOptions:
To support state restoration a new launching method has been introduced that complements the more traditional didFinishLaunching. willFinish is called before the state is restored, and didFinish is called afterwards. You’ll probably therefore want to split your launching code across these two methods: code that is required for your app to run should go in willFinish. Final completion code should go in didFinishLaunching. What counts as ‘final completion code’? Things like checking whether a user is logged in, where you might want to display a modal login page rather than your app itself, for example.

Backwards Compatibility

If you’d like to support iOS 4 and 5 users (where state preservation is not supported) you’ll need to watch out for a few things. Firstly, be sure to test that restoration identifiers are supported using respondsToSelector (if you’re using IB you can skip this step):

if ([self respondsToSelector:@selector(restorationIdentifier)]) {
        self.restorationIdentifier = @"Home Controller";
}

However, a more serious issue is how to deal with the new willFinishLaunchingWithOptions method, which is only available on iOS 6, into which you’ve moved most of your launching logic. You could put your launch code into both willFinish and didFinishLaunching and conditionally test the current version of iOS, but this is unnecessary duplication.

Instead, you can use this great little trick which Apple recommend in their WWDC videos:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [self commonLaunchInitialization:launchOptions];

    // Code that must execute in didFinishLaunching whether state restoration is enabled or not
    return YES;
}

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [self commonLaunchInitialization:launchOptions];
    return YES;
}

- (void)commonLaunchInitialization:(NSDictionary *)launchOptions {
    static dispatch_once_t pred;
    dispatch_once(&amp;pred, ^{
    // Your launch code here
});

If you are not familiar with Grand Central Dispatch you’re probably wondering what this code does. The dispatch_once GCD call is a clever method that is typically used when doing singleton work: it will execute it’s code block once only, and no nothing for any subsequent calls. This allows us to guarantee our launch logic will only be executed once, even though we’re calling commonLaunchInitialization in both didLaunch and willLaunch.

A Note on Testing

For reasons that will become quickly apparent, there are a few ‘gotchas’ involved with testing state restoration. Confusingly, terminating an app from the app switching pane disables restoration. Why? To prevent a mis-behaving or broken app from keeping a user stuck inside a loop. Perhaps the app has some terrible networking code that keeps the user locked inside a loading screen - resuming to that state would not be beneficial. Similarly, as you might expect state will not be resumed if your app didn’t terminate cleanly (i.e, it crashed).

So how do you test app switching? Well, when attached to the debugger you will want to exit to the home screen (by pressing the home button) and then terminate the app from Xcode (by hitting the ‘Stop’ button).

As seen around the office…ironically, the CD is the...

Mon, 11 Mar 2013 16:39:29 +0000

As seen around the office…ironically, the CD is the BlackBerry 10 Dev Kit…

Samsung Wallet: Meh

Fri, 01 Mar 2013 10:36:00 +0000

Over at Mobile World Congress this week, Samsung was busy announcing it’s new Samsung Wallet. Unfortunately, it’s pretty clear that Samsung rushed this out the door: there’s vast amounts of functionality missing, the developer documentation is poor, and unlike Microsoft or Google’s efforts it just feels a little half hearted.

App Only

Apple Passbook lets you distribute your passes in three ways: through a native app, through a web site, or via e-mail. The advantage of this approach is that brands without a presence on the app store can still offer consumers passbook enabled tickets, cards, and vouchers.

However, Samsung Wallet only supports distributing passes through a native app. To get technical, this is because to get a pass into Samsung Wallet you need to use intents, which allow apps to call actions within other apps.

No NFC

For better or for worse, Apple have chosen not to put NFC into their phones. Samsung, however, haven’t only put NFC into many of their Android devices, they’ve made it a unique selling point, spending millions of dollars on TV commercials waxing lyrical about S Beam sharing. So to not have Samsung Wallet support NFC is more than a glaring omission - it’s embarrassing.

Samsung’s stated reason for not supporting NFC doesn’t really ring true either - apparently, retailers don’t have NFC hardware. Except for all those contactless card readers in CVS, Walgreens, Boots, and the like.

1D Barcodes

1D barcodes are ‘old school’ barcodes, like this:

Apple Passbook doesn’t support them - Samsung Wallet does. Now, you might think that this was a point in favour of Samsung Wallet, but it’s not. I think it’s a big mistake. When Passbook was in developer beta, it too supported 1D barcodes. Apple removed support before releasing it to the public.

The reason for not supporting 1D barcodes involves how barcodes themselves are scanned. When barcodes were first released, scanners used lasers to detect the codes. The laser light bounces off the white bars of the code, and is absorbed by the black bars. By detecting the laser light bounced back you can read the barcode. This is fine when your barcodes are printed on card or paper - but when your barcode is being displayed on a piece of reflective glass you’ve got a big problem.

Although some retailers have upgraded their point-of-sale systems to more modern, optical scanners (that can also scan QR and other 2D barcodes), many are still using lasers. Trying to scan a 1D barcode on a phone with a laser will result in failure a lot of the time. Users will either blame the shop themselves (bad), or the handset manufacturer (even worse, from Apple or Samsung’s point of view).

Basically, expect a lot of angry tweets along the lines of “the Samsung Wallet app is terrible, nobody can scan barcodes off it” for retailers who choose the ‘easy’ path of 1D barcodes.

Conclusion

I don’t want this post to come off sounding as if I dislike Samsung - on the contrary, until upgrading to the Nexus 4 my primary Android device for a Galaxy S2, which I got along with very well. But I find many of Samsung’s ‘own brand’ applications to be generally sloppy, with little thought put into long-term sustainability.

As it stands, the developer documentation for Samsung Wallet is poor, and the way vouchers are requested/generated is confusing and ill thought out. I wonder whether Samsung will truly see mass-adoption in the same way brands have flocked to Passbook. It’s a shame, because I suspect given another month or so Samsung could have had a product that was far more professional and better received by the community at large.

New Computing Curriculum for England

Sat, 23 Feb 2013 23:55:17 +0000

The way computing is taught throughout schools in England is going to drastically change from next year - and, importantly, the proposed new curriculum is under public consultation. The consultation runs until April 16th, and anyone with an interest in computing education in the UK should consider reading through the proposals and contributing his or her thoughts.

The good news is the new Computing Curriculum is a quick, four page read. The bad news is that responding to it is something of a bureaucratic nightmare - but more on that later.

One of the biggest changes (outside of the overdue renaming of the subject from ‘ICT’ to ‘Computing’) is making programming of some sort mandatory for all students. The UK has, for the time being, got the jump on the USA. Let’s take a look at exactly what sort of coding is being suggested for the relevant age groups:

Key Stage 1 (5-7 years old)

By age seven, children should be able to “understand what algorithms are”, “write and test simple programs”, and “use logical reasoning to predict the behaviour of simple programs”.

The curriculum doesn’t prescribe how exactly this should be taught, and with what platform or software. The general expectation is that environments such as Scratch will be used.

Key Stage 2 (7-11)

By the end of their primary education, children should be taught how to “use sequence, selection, and repetition” in their programming projects, and be familiar with variables. They are also expected to demonstrate a basic understanding of algorithms, and how to test and diagnose errors in their programs.

Again, there’s no prescribed toolset, and Scratch would be more than able to fulfil all the curriculum requirements.

Key Stage 3 (11-14)

In secondary school students should continue to program, in “two or more programming languages, one of which is textual” (emphasis mine). They should also be fully versed in boolean logic, data structures such as arrays, and “use procedures to write modular programs”. More interestingly, students will be explicitly required to “understand at least two key algorithms for each of sorting and searching”.

How To Respond

Having read the curriculum in full you’ll probably have some comments to make. Unfortunately, the Department for Education have had to take their e-consultations tool offline, “due to technical problems”. It has been replaced with a thirteen page Word document which you must then upload via a rather confusing web form. It could be worse. It could also be a lot better.

So with that in mind, here’s how to respond in three ‘easy’ steps:

Download this Word document
To respond specifically to the new Computing curriculum fill out Sections 3, 4, and 7. Section 14 can be used for any additional comments, and you may also want to fill in Section 15, which provides feedback on the rather convoluted consultation process itself.
Once you’ve finished filling in the Word doc you can [upload it here] (make sure you indicate you’re responding to “Reform of the National Curriculum in England”), or e-mail it to NationalCurriculum.CONSULTATION@education.gsi.gov.uk

It’s that simple! I highly encourage you to take half an hour out of your day to respond - you have until April 13th, and the more people who comment the better.

Link Time: Objective-C Blocks Quiz

Tue, 05 Feb 2013 23:40:00 +0000

Link Time: Objective-C Blocks Quiz:

Parse have just posted a nice ‘know your Objective-C blocks’ quiz. I am sure this has nothing to do with the recent stability improvements in the Parse SDK (90% of my crash reports used to come in from Parse, but one of their recent SDK updates took that figure down to 0%)!

Don’t forget that even if you are using ARC there are some potential memory leak / circular reference problems with blocks that you can stumble in to as well!

Oops: Snapchat Flaw Leaks Personal Data

Mon, 14 Jan 2013 20:12:00 +0000

Snapchat has been getting a lot of press recently, so I decided to take a look at the app. In doing so, I came across a security vulnerability that allowed anyone to obtain a Snapchat user’s cellphone number and e-mail address without their consent. This is a serious security issue, as many Snapchat usernames are publicly available.

The Problem

Snapchat lets you find out if any friends who might have you in their contacts are using the service. To do this it needs your phone-number: on Android, this is obtained automatically. On iOS, however, you need to verify your number by sending a SMS to Snapchat with a unique code (partly to prevent abuse, but mainly because unlike Android, iOS does not allow system access to the device’s phone number). The Snapchat app makes a web service call to discover whether this SMS verification has succeeded or not. The call looks like this:

POST https://feelinsonice.appspot.com/ph/settings
username=john.smith
timestamp=1357768038866
req_token=13f413fwrf4[…]

The req_token is a little strange (it’s an obfuscation of two separate hashes), but fundamentally it contains the user’s authorisation details. If you’re interested you can find out more about how the req_token is generated here.

In response to that call you receive the following back:

{
    "message": "+16175551212",
    "param": "[base64 encoded username]",
    "action": "[base64 e-mail (optional)]",
    "logged": true
}

This information is used to display a user’s account information inside the app. Notice that the phone number for the requested user is returned. Normally the supplied req_token would be checked and compared with the supplied username to ensure a user’s private information wasn’t being handed out freely.

Unfortunately a bug in Snapchat’s backend system meant this call wasn’t being authenticated - by changing the username parameter of the POST request it was possible to retrieve any user’s phone number. The req_token simply isn’t checked or even looked at: given a username the system blindly returns a phone number.

As a good number of Snapchat users are using the service anonymously this is a very serious vulnerability. Many people have even posted their Snapchat usernames in reviews, tweets, or tumblrs. Depending on what you are doing in Snapchat you may not want other users to identify you. However, by taking advantage of this vulnerability anyone could easily find out a Snapchat user’s phone number and e-mail.

Disclosure

I disclosed this vulnerability to Snapchat shortly after discovering it, on Tuesday January 9th 2013. Snapchat were very responsive, and the issue was patched in less than twenty-four hours. I have confirmed that it is now fixed, and you can no longer abuse the call to obtain users’ personal information.

Conclusion

Security issues are to be expected with any large app or web service with millions of users. However, this error was very basic and shouldn’t have happened. That said, Snapchat were very receptive to disclosure, and it was patched almost immediately. Snapchat has grown exceptionally quickly, which I suspect has exacerbated some of their recent security problems.

Snapchat’s API is on occasion quite strange, and as security blogger Adam Caudill has pointed out out relies quite a bit on security through obscurity. I agree with Adam that Snapchat should consider using some of their recent funding to externally audit their systems and reduce the risk of this sort of thing happening in the future.

Collection Views

Thu, 22 Nov 2012 13:38:17 +0000

Making Life Easier Since 2012™

One of the great things about Cocoa / iOS development is also one of its downsides: you don’t need to know exactly what’s going on behind the scenes. Judging from some of the questions that come up on StackOverflow with surprising regularity, a sizeable number of users don’t realise that a UITableView is actually recycling views and cells to conserve memory.

This introduces a lot of problems when developers come to implementing things like galleries. Almost every other day there’s a question along the lines of “I put ten images into a scroll view and my phone crashed, what’s going on?”. Inevitably it’s down to memory simply running out. Until iOS 6 you were faced with several far from ideal options to fix this: write your own recycling system, use one of several open-source options (of varying quality), or hack a UITableView to pieces.

Collection views change that, in a good way. Some people describe them as “gallery views”, but that’s actually not the case - UICollectionView goes deeper than that. Unlike a table view, the display logic (how your items are laid out on the screen) is totally decoupled from the recycling logic. A collection view is paired up with a layout class that describes where and how elements should be positioned.

The most common layout - a gallery - is provided through the built-in UICollectionViewFlowLayout class, but by substituting your own layouts you are free to display your items however you want: cover flow, 3D-like layouts, circular layouts, pile layouts (à la Mail) - they’re all easily achieved by switching out the layout class.

Version Parity

There is, of course, a downside to all these benefits: collection views are only available on iOS 6. To be honest, for many people this shouldn’t be a problem. Some of the apps I work on show over 80% of users running iOS 6, and that’s only two months after it was released.

However, there’s good news for those looking to implement flow and gallery layouts - Peter Steinberger has put together a great drop-in replacement class for iOS 4.3-5 that has a 100% compatible collection view API.

Stop Writing Custom Galleries

The upshot of this is it would be absolutely crazy to implement your own recycling gallery view from scratch, even if you have to sub-class a collection view or write your own layout to get the effect you want. Setting aside the fact that in the vast majority of cases using a collection view will save development cost and time, you’re also backed by code that’s received far more testing time than your custom written class ever will.

The take away lesson: collection views are a fantastic addition to iOS, and you should be using them wherever possible in your apps rather than custom or third-party code. Learn to love them, and you will be rewarded.

John Browett Leaves Apple (Yay!)

Tue, 30 Oct 2012 00:00:25 +0000

John Browett Leaves Apple (Yay!):

John Browett, the man previously in charge of such fantastic retail experiences as Dixons and Currys, has left his role as head of Apple Retail after only six months. Well, the press release says ‘left’, but I suspect is was far from voluntary. I wouldn’t say I told you so, but…

Scott Forstall is also on the way out, which on the whole I think is a positive move. For some reason I always generally dislike Scott Forstall when he’s speaking at Apple events, and if the internet rumour mill is to be believed there was a fair amount of tension between his team and the industrial design team. I think it’s safe to say that Jony Ive being in charge of both industrial design and software user experience can only be a good thing.

(Update 27/4/12: since I wrote this, Parse have been acquired by Facebook. I’ve blogged...

Sat, 13 Oct 2012 19:49:00 +0100

(Update 27/4/12: since I wrote this, Parse have been acquired by Facebook. I’ve blogged about this here. StackMob have also changed their pricing policies, making a lot more of their services free to use. I’m writing an update to this post right now taking all of this into account!)

Parse Vs Stackmob - Round II

Parse and Stackmob are the pre-made pastry of the mobile development world: if your app needs a backend system to persist data you could build it yourself, manage the hosting, and support it. Similarly, if you’re looking to make a pie you could make the puff pastry yourself, a time-consuming process that isn’t exactly straightforward…or you could just go into the store and buy it pre-made off the shelf.

So if you’re a seasoned Objective-C developer but have no clue how to develop a robust, reliable back-end solution for your app you might want to consider finding something to do the heavy lifting for you. This is where Parse and StackMob, two popular ‘backend-as-a-service’ (or BaaS) providers come in.

A while back I compared both StackMob and Parse - in the five months since I wrote that post a lot has changed, so it’s time for another Parse vs Stackmob shoot-out! As always, I’m approaching both providers with iOS in mind, since that’s my background - however, most of what I’m looking at applies to iOS, Android, and mobile web alike.

If you’re still a little confused about this whole ‘backend as a service’ thing you might want to read my original comparison.

Parse: What’s New

In the last five months Parse has matured a lot - here’s some of the major improvements and additions:

Cloud Code

One of Stackmob’s biggest advantages was the ability to deploy and run code server-side code without requiring an intermediary host. This is one of those features that you’ll inevitably require at some point on your project, even if you don’t realise it yet. Custom server-side logic might be used for advanced validation, or triggering other actions.

With Cloud Code, Parse has taken a big step forward towards that goal: you can now create your own endpoints and hook into existing calls easily. That said, there are a couple of downsides:

Stackmob supports Java and Scala, whereas Parse only support JavaScript (in fairness, this is only a downside if you’re unwilling to pick up JS)
You can only use Parse’s Javascript SDK - nothing else

What does this mean? Well, you couldn’t create a piece of cloud code that called out an API on another system, for example. Hopefully this limitation will be removed soon. Another drawback of Cloud Code is the lack of a staging or development environment: whilst you could set up another application within Parse to test your Cloud Code it is far from ideal.

Other Additions

Parse has always had great documentation - this has been supplemented with a StackExchange like user questions section, which whilst at times slightly confusing (perhaps I’m being dense, but I couldn’t find a way to view all the questions I’d asked) is a welcome new feature. Other improvements include:

In-app purchase wrappers for iOS
Drastically improved JS SDK (for web apps)
Better control over push messaging (SDK only: the web interface is still a bit simplistic)
New PFImageView classes for iOS to assist with remote image loading, as well as new Parse-integrated view controllers (great for hackathons, maybe less useful for a highly customised app build)

StackMob

StackMob has also been busy making improvements:

Better SDKs

StackMob have radically re-thought their iOS SDK, and it’s heavily inspired by Core Data. In fact, you’ll basically be using Core Data to interface with StackMob. It’s a great way of doing things, although if you’ve got no experience with Core Data you might prefer the simple abstraction that the Parse SDK provides. With this new Core Data model comes background updating of objects, which is greatly appreciated.

As before, here’s the code you need to create an object, set a value, and update it:

Parse

PFObject *score = [PBObject objectWithClassName:@"Score"];
[score setObject:[NSNumber numberWithInt:1337] forKey:@"score"];
[score saveEventually];

StackMob

NSManagedObject *score = [NSEntityDescription insertNewObjectForEntityForName:@"Score" 
                                                       inManagedObjectContext:self.managedObjectContext];
[score setValue:[NSNumber numberWithInt:1337] forKey:@"score"];
[self.managedObjectContext save:nil]; // You'd normally do some error checking here

If you’re familiar with Core Data you’ll see straight away that StackMob is tightly integrated.

As always, StackMob’s SDKs are all open source, unlike Parse. This may or may not be of value to you - neither Parse nor StackMob’s SDKs are not without their bugs, and being able to dive into the source instead of waiting for a fix could save you valuable time.

Other Additions

The past five months have also brought some other incremental improvements to the StackMob platform, including:

Custom domains for hosted HTML
User roles and permissions
Push improvements (both SDK side and server side)
OAuth 2 support

Summary

If you were hoping for a decisive result you’ll be disappointed to know that yet again there’s no right answer as to which platform is ‘best’. Your choice will very much depend upon what’s important to you and your apps.

As before, on price Parse is the clear winner. Inexperienced developers will also appreciate the simplicity of Parse’s SDKs, but there’s no doubting the fact that StackMob’s Core Data powered iOS SDK is very powerful.

If you’re an indie developer, going to a hackathon, or looking for something to power your weekend project you’ll love Parse. Enterprise and commercial developers may be attracted to StackMob’s advanced server-side code functionality, and the distinct development/production environments on offer.

Regardless, I’d recommend trying both providers and coming to a decision based on what you’re more comfortable coding with and what features work best for you - with free tiers available there’s little reason not to.

"It definitely looks sound. I haven’t tested it because […] English law takes a fairly..."

Thu, 27 Sep 2012 22:39:20 +0100

““It definitely looks sound. I haven’t tested it because […] English law takes a fairly backwards view of doing this sort of thing, even with the best of intentions.”

- That’s me, interviewed in El Reg.

Did you know that the Computer Misuse Act makes it illegal to carry out any sort of XSS malarky, even if it’s a known problem or you’re trying to alert a company to the poor state of their web security?

More companies should consider running White Hat programs and rewarding those who discover issues with their site: consider following Google or Facebook’s lead.

Grant Shapps MP & Spam

Mon, 03 Sep 2012 12:38:00 +0100

The Guardian reported today about Grant Shapps, the Minister of State for Housing and Planning in the UK, who’s also tipped to be the new chairman of the Conservative Party. In other words, someone pretty high up in government.

It turns out that Grant had a little side business, called How To Corp Ltd - nothing necessarily wrong with that, except How To Corp appears to have been selling a number of supposed ‘SEO’ products that violate Google’s code of practice.

This has naturally caused quite a stir on Twitter. Some people, however, have questioned whether Grant has actually done anything wrong:

@dukecorky @johnprescott @grantshapps @saggydaddy Where is the scam and how is it leeching? Real what? Any laws or MP rules broken?
— Mike Broadbent (@CarrotHead) September 3, 2012

Fair enough - after all, breaking the Google Code of Practice is pretty small fry compared to some of the things MPs have got up to in the past.

However, I was curious: most people selling SEO software have to promote it somehow. And usually it’s promoted using spam. Was Grant Shapps a spammer? Spamming is a much more serious accusation, something everyone hates. Of course, finding out whether How To Corp had been spamming in the past would be difficult: spammers tend, for obvious reasons, to hide their tracks.

Except in this case - because Grant Shapps made a little slip up. A slip up that would seem to suggest that during 2004 How To Corp Ltd was a legitimate e-mail spammer.

An Important Note

One thing before I go on: I don’t have anything against Grant Shapps. I want to make this clear, because politics and Twitter tends to bring out the worst in people. Let’s be realistic here: many MPs from all parties have done and will do lots of dodgy things. Grant Shapps may be an excellent MP - I don’t know. You might, however, feel that how Grant Shapps ran his limited companies in the past is relevant to his current work.

2004

Our tale begins in 2004. Grant Shapps was at the time running two businesses: How To Corp Ltd, and PrintHouse Corporation. Since becoming a MP he resigned from both, but maintains some shares in PrintHouse. His wife is currently listed as the director of How To Corp.

At some point in 2004, How To Corp ran a bulk e-mail campaign that was reported as spam through the SpamCop service. This was a bit of a problem, because both PrintHouse and HowToCorp ran their websites off the same server. Legitimate PrintHouse e-mails were getting marked as spam.

It appears as if at the time both the PrintHouse and How To Corp websites were running off the same server. This meant e-mails being sent from printhouse.co.uk kept getting blocked by SpamCop - a bit of a problem for Grant. So how did he deal with it?

This is where things get interesting - what follows is a post Grant Shapps made to the SpamCop forums on April 13 2004:

Just started using SpamCop on several different accounts over the weekend and generally happy, but…

Today I reported some spam that was in my held folder and it appears that following that event my own email was somehow blocked. In other words, if I mail myself, it goes straight to my held mail folder.

So I took a look at the message source of my own message in the Held folder and it appears to have a reference to someone else’s server, which is the one being blocked. Nothing to do with my own server as far as I’m aware.

So is it possible to block yourself in error?

Here’s the message header and the offending IP address appears to be: 213.166.65.2 whilst my mailserver IP is 212.23.23.125 and is not on any block lists.

So what do I do from here??

Grant.
Return-Path: <michael[at]howtocorp.com> 
Delivered-To: spamcop-net-grant[at]spamcop.net 
Received: (qmail 19231 invoked from network); 13 Apr 2004 16:21:26 -0000 
Received: from unknown (192.168.1.101) 
by blade4.cesmail.net with QMQP; 13 Apr 2004 16:21:26 -0000 
Received: from dsl-212-23-23-125.zen.co.uk (HELO mailgate.printhouse.co.uk) (212.23.23.125) 
by mailgate.cesmail.net with SMTP; 13 Apr 2004 16:21:25 -0000 
Received: from mailgate.printhouse.co.uk (mailgate.printhouse.co.uk [213.166.65.2]) by  
mailgate.printhouse.co.uk (NTMail 7.02.3037/NY9765.00.9ea0b33f) with ESMTP id ejifeaaa for  
grant[at]spamcop.net; Tue, 13 Apr 2004 17:20:33 +0100 
Received: from [212.23.3.141] by mailgate.printhouse.co.uk (NTMail 7.02.3037/NY9765.00.9ea0b33f) with ESMTP id ejifeaaa 
 for grant[at]printhouse.co.uk; Tue, 13 Apr 2004 17:20:33 +0100 
Received: from [212.23.23.120] (helo=grant) 
by heisenberg.zen.co.uk with esmtp (Exim 4.30) 
id 1BDQcs-0005rA-9S 
for grant[at]printhouse.co.uk; Tue, 13 Apr 2004 16:19:06 +0000 
Message-ID: <024201c42173$0ab33990$781717d4[at]grant> 
Reply-To: "Michael Green" <michael[at]howtocorp.com> 
From: "Michael Green" <michael[at]howtocorp.com> 
To: <grant[at]printhouse.co.uk> 
Subject:  
Date: Tue, 13 Apr 2004 17:19:05 +0100
Organization: How To Corp 
MIME-Version: 1.0 
Content-Type: text/plain; 
charset="iso-8859-1" 

If you’re not technical the last part of his post probably doesn’t make much sense - what’s going on here?

Well, Grant claims he reported some spam which somehow resulted in his own e-mail getting blocked. Except the spam he’s ‘reporting’ appears to originate from someone with the email address michael@howtocorp.com - which, thanks to The Guardian, we know is Grant Shapp’s own e-mail address under his alias ‘Michael Green’.

Of course, it’s rather unlikely that Grant would report his own emails as spam. What almost certainly happened is somebody else reported emails coming from howtocorp.com as spam, which then caused SpamCop to block printhouse.co.uk emails as well. Grant then had to convince SpamCop to let his Print House emails through whilst not being found out as the owner of the howtocorp.com domain.

Some forum members picked this up - one poster wrote:

I’m having a bit of a struggle working out your “not associated with me” e-mail server statements. You say this sample is “an e-mail to myself. If so, please explain why the address of grant[at]printhouse.co.uk is not associated with the server called mailgate.printhouse.co.uk …. there sure seems to be some small connection there.

Query bl.spamcop.net - 213.166.65.2 DNS error: 213.166.65.2 has no reverse dns 213.166.65.2 listed in bl.spamcop.net (127.0.0.2) Been reported as a source of spam about 100 times

Grant then tries to claim the hundred of so reports of spam from howtocorp.com all came from him:

Yes, those 100 times were all me reporting that IP for spam I received

…this seems a little unlikely. Why would Grant report email from howtocorp.com, a domain he owned, as spam? I’ll let you decide.

Conclusion

In 2004 SpamCop received over a hundred reports of spamming from howtocorp.com, a company run at the time by Grant Shapps
As a result, e-mails being sent from printhouse.co.uk (a company run at the time by Grant Shapps) were also blocked
Grant Shapps then tried to get SpamCop to reverse the block by claiming he had nothing to do with howtocorp.com
If howtocorp.com were genuinely sending unsolicited marketing e-mails they would have been committing an offence under the Privacy and Electronic Communications Regulations 2003, which only allows e-mail marketing to be sent where individuals have agreed to receive them

Perhaps howtocorp.com didn’t spam, and had a genuine relationship with everyone it emailed in 2004. On the other hand, over a hundred people didn’t think so, and reported the company to spam prevention services. I’ll leave it at that.

PINs and Needles

Tue, 14 Aug 2012 14:17:47 +0100

It’s well known that the more complex your password the more secure you will be. Exactly how to achieve that complexity is a matter of some debate, but at least we can all agree that 1234 isn’t going to cut it as your Gmail password.

Alongside complexity sits enforcement: some providers, like Google, simply require a minimum password length. Others are stricter: Apple’s list of requirements is too long to reproduce here, but includes such gems as “passwords must not contain more than 3 consecutive identical characters” and “passwords must have at least one capital letter”.

Despite all this complexity enforcement, many users do indirectly use 1234 to access not just their Gmail, but their social networks, photos, text messages, and more. I am of course talking about the PIN, unchanged since its debut thirty-five years ago, and often the only thing protecting a cellphone.

A Short Historical Detour

The modern PIN was invented by a Scot - either John Shepherd-Baron or James Goodfellow depending on your sources, who both claim some credit to inventing the modern day ATM. Shepherd-Baron’s machine required users to authenticate themselves with a four digit numeric code. Why four digits? Shepherd-Baron claimed his wife vetoed a six digit PIN, as four digits was the most she could remember¹.

Even though ISO 9564 (the international standard for ATM systems) specifies PINs of up to 12 digits should be supported, the overwhelming majority of users and banks have stuck with Shepherd-Baron’s original suggestion of 4 digits.

But what does this have to do with phones? Twenty years ago, when SIM cards were actually the size of credit cards, making calls on the go could be an expensive business - your monthly plan was much more likely to come with 50, rather than 500, minutes. A way was needed to secure a phone and prevent someone running up a huge bill on a phone without the subscriber’s knowledge. A PIN was deemed to be the best option - after all, users were familiar with them from banking - and in 1992 in was mandated that phones should support a four digit security code.

What’s important to note is that at this point PINs didn’t really protect any data outside of an address book: phones made calls, and that was that. As time went on, more and more personal information made its way onto mobile, until we ended up with our phones basically containing carbon copies of our entire lives: our calendars, e-mails, social networks, photos, and more.

PIN Locking

Because a four digit PIN is self evidently not very secure (with only 9,999 combinations to try) both ATMs and mobile phones will lock users out after n number of incorrect attempts. Smartphones can even be setup to erase the entire devices after a set number of tries.

If you have had the misfortune of locking yourself out of your phone you’ll know you typically need to obtain a PUK (‘PIN Unlocked Key’) from your mobile operator. Here we see the first problem with PIN codes: you only need to read about Mat Honan’s recent experience to see that it’s not out of the question for an impostor to convince a customer service rep they’re you.

In fact, this is exactly what News Corporation did in the recent phone hacking scandal - by ringing up telcos and pretending to be subscribers, News of the World employees were able to convince telcos to release PIN codes to them, allowing unfettered access to voicemail accounts.

PIN Breaking

Whilst a four digit PIN is undeniably very insecure, there is of course one thing I’ve omitted - to make any use of it you’re going to need physical access to the phone in question.Still, this doesn’t offer us much hope, given how often phones can be misplaced, left at a desk, or stolen. Let’s assume we have access to the phone we want: how can we get into it?

Guess

Guessing is a risky gamble if you’re entering the codes directly onto the phone, as you may well be locked out. However, it’s not quite as risky as you might think - a University of Cambridge research paper suggests a significant minority use highly guessable PINs such as 1234 or their birthdate/year. Still, guessing is a very clumsy approach.

Brute Force

Given that a phone will typically lock you out after several incorrect attempts you may think you don’t have to worry about brute force. This was certainly true in the past - for a long time, PINs were stored directly on the SIM card. However, smartphones now typically store the PIN in flash memory - once you’ve imaged the phone onto another computer you can carry out an offline dictionary attack, given you as many attempts as you require.

Because a four digit PIN is so short, brute-forcing it is extremely straightforward. How straightforward? Here are some of Apple’s own estimates on how long it would take to crack an iOS 5 device with varying passcode complexities:

Complexity	Time
4 Digit PIN	13 minutes²
9 Digit PIN	2.5 years[^apple]
6 character password	5.5 years[^apple]

Android is not immune either - several forensic houses have documented brute force approaches that can break ten digit PINs in an hour or so. The only

Social Engineering

Whilst not limited to just PINs, the fact users have certain expectations around PINs and phone locking means some very simply social engineering tricks can work exceptionally well. Users are not conditioned to treat phone PINs in the same way as their banking PINs - banks have spent considerable sums of money educating users to ‘shield’ their PINs by covering up keypads.

Phones can also be swapped out with identical devices that display ‘dummy’ lock screens - customs apps that look and behave like a traditional look screen but with one major difference. Rather than unlocking the phone, these apps will transmit the PIN being entered by the user back to you. It’s also going to display an ‘incorrect PIN’ error regardless of what the user entered, and after three attempts it will ‘lock’ the phone.

So?

You may well wonder whether you need to care about any of this. You might never let your phone out of your sight, and the idea that somebody might go to the trouble of duplicating your phone to get access to your PIN may seem laughable.

On the other hand, at this very moment several highly paid executives of News Corporation are awaiting trial for perjury and conspiracy to pervert the course of justice, all relating to offences involving breaking into services protected by four digit PINs. Many of victims were not celebrities, but ordinary people who for whatever reason found themselves in the news.

We’re Stuck in a Hole

Unfortunately, the PIN isn’t going away. Why? Because an expectation has been established: PINs are quick and easy to enter, and allow access to your phone in seconds. Apple is more than happy for you to use an alpha-numeric password, but wave goodbye to your 9-button keypad and hello to a full QWERTY keyboard.

Not to say that manufacturers aren’t trying different things: Google have introduced facial recognition lock screens for Android, although their effectiveness is dubious at best (Jellybean now has an option to require ‘eye blinking’ whilst unlocking, which perhaps tells you how badly the first iteration worked when presented with a photo).

So what can we do to improve PIN security? Whilst users requiring the highest levels of security may well accept using a highly complex password instead, I suspect the average smartphone owner will not. Biometrics are one potential avenue, but without custom hardware such as fingerprint readers the technology simply isn’t there yet.

One thing is certain: until we part ways with the PIN we’ll continue to live in the strange situation whereby your e-mails, social networks, and other sensitive accounts will require a complex password to view through a desktop, but allow total unfettered access with a simple four digit code on your phone.

This sounds a little too apocryphal for its own good in my opinion. ↩
iOS Security White Paper, Apple Inc, May 2012, working under the assumption of 80ms per attempt ↩