Incompetence or arrogance?

Image by Loutron Glouton via Flickr

Respected security analysts and consultancies have now confirmed what many industry watchers, pundits and commentators suspected last week - that the 'upgrade' pushed to tens of thousands of BlackBerry mobile devices in the UAE by telco Etisalat was, in fact, not what it seemed to be, an 'upgrade for Blackberry service. Please download to ensure continous service quality.'

Interestingly, this rather flies in the face of the somewhat belated statement made by the telco itself, which I reproduced in full here at the end of last week. That statement rather annoyed a number of BlackBerry users who found it facile and lacking the one element that tens of thousands of frustrated customers whose mobile devices were affected wanted to see - an apology. Many of those users say their BlackBerrys were rendered inoperable or suffered significantly downgraded performance. A number reportedly bought new batteries for their BlackBerrys, believing the battery was at fault when, in fact, it was the software update they had accepted from the operator.

A press release was issued on the 15th July by security company SMobile Systems. The company, which positions itself as 'the leading provider of security solutions for mobile phones and maker of the only antivirus and antispyware applications in the world for BlackBerry devices, has released a solution for the (in their words) 'recent spyware-laden update sent out to BlackBerry users on the Etisalat network'. That press release in full can be found here.

The company's release claims, 'The BlackBerry Spyware, which intercepts email and drains battery life quickly, was pushed as an update to BlackBerry's on the Etisalat network. Sent to users as a wide-area protocol (WAP) message, the Java file intercepts data and sends a copy to a server without the user's knowledge.'

That is an extraordinary claim to make regarding a piece of software that Etisalat's official statement says was software 'required for service enhancements particularly for issues identified related to the handover between 2G to 3G network coverage areas.'

It is perhaps worth noting that the Chairman of SMobile Systems, quoted in the release, is a former White House Deputy Chief of Staff and so, we must reluctantly admit, carries some weight.

SMobile is not the only expert testimony that claims the notorious update is other than it seems. Besides the many people who believe that the Etisalat network is 100% 3G now and therefore does not present 2G to 3G cell handover problems, there are also a number who point out the fact that BlackBerrys haven't experienced cell handover issues for some time now - in fact, the only online references I can find to the handover issue date back to 2006.

Added to this, you have those who have examined the code - Qatar based programmer Nigel Gourlay was quoted widely in the initial coverage of the issue, but his assertions that the network update was in fact an attempt to install monitoring software have been backed up by respected security blog Chirashi Security - a white paper analysing the code in some detail, written by Sheran Gunarsekera, is linked here.

That white paper asserts that the code is a monitoring application. It also points out that the application was not properly implemented, pointing out that the application developers had not used any form of source code obfuscation - in other words, it shouldn't have been as simple to trace, upload and analyse the code as it in fact was. The code, according to the White Paper, is set up to hide itself from the user, attach itself to network events and report these to the service-provider's server and look out for control messages that enable interception of user messages. If enabled, the application will forward a copy of emails sent by the subscriber to the service provider's servers.

Damningly, the White Paper asserts that the code 'was not mature enough to be deployed. This is especially relevant if Etisalat planned to conduct full-scale legal interception on BlackBerry users.'

The Chirashi White Paper is scrupulous to point out that the application only forwards outgoing emails and not other message types and then only when the application has been enabled to do so - it does not report on emails by default. But it does make the point that the version of the interceptor software it analysed should not have been deployed - particularly not as part of a legal interception.

The White Paper also strays out of geekland into my domain when it asserts, in the context of requiring legal interception software to meet two criteria, to do no harm and to be thoroughly tested: 'A service provider should always be prepared for the worst. In case things do not work out as planned, there needs to be a dedicated PR team who is ready to step up and deal with the public. Users should not be lied to or ignored, they will accept it better if they know the provider is well within legal rights to perform such interception.' (The italics are mine, BTW)

Security company Veracode also analysed the upgrade last week, asking whether the fact that the implemented update contained both .jar and .cod versions was down to 'arrogance or incompetence?'. That's an area explored by a journalist from the region's leading telecommunications magazine, Comms MEA, here. Again, Veracode's Chris Eng reports that the clear purpose of the update, in his expert view, is to install a piece of software that, when activated, will forward user data to a third party server, presumably owned by the service provider.

All of this leaves me wondering quite what on earth Etisalat thought it was doing. And quite how our media is standing by and allowing Etisalat to simply claim that the great big elephant in the cupboard is in fact a pair of shoes.

Nobody I know has a problem with legal interception. I think most of us would recognise that it is highly desirable that the security agencies employed by our governments have access to the information they need in order to protect society in general. Those agencies are constantly monitoring network traffic, legally and within the charters and frameworks that govern their activity. We need them to be competent and we desperately need to believe in their competence and efficacy.

Similarly, we need to trust our telcos. As a commercial entity operating in a regulated and competitive free market environment, even the biggest telco has a duty towards its subscribers and a duty to tell the truth - not only to earn the trust of its customers, but to underpin the level of trust required by investors and multinational companies who wish to trade in that environment. Mendacity and silence are not good enough - people are still facing problems with their terminals even now because there has been no clear attempt to reach out to customers and fix this issue - let alone roll back the update. There are critical issues related to privacy and security that the operator has refused to address - and questions are now being asked by a wider community about the long-term implications for BlackBerry security in general as a result of this whole farago.

Finally, there is the issue of responsibility. Someone was responsible for this Keystone Cops attempt to police BlackBerrys and the subsequent lack of timely and appropriate response that turned a customer service problem into a full-blown case study in how fumbled issues management rapidly evolves nto crisis management and how ignoring a crisis simply, in today's commercial environment, won't do.

Text

There's an increasing body of anecdotal evidence that many companies are cutting back on staffing, although they're not going around telling the papers and, from the coverage we're seeing, the papers aren't really asking that much. There seem to be an awful lot of low-profile tens and fifteens behind those few high profile five hundreds.

What I have found amazing are the stories of people who have been told by text that they don't have jobs any more. An SMS the night before, telling them not to bother turning up at the office.

Sacked by text message! It doesn't seem to be the kind of thing you'd find in the 'Good HR Handbook' does it?

Salik: Wading Through a Mountain of Forms

I was thinking about refusing to babble on about Salik, the Dubai congestion charge, any more simply because everyone's talking about it so much it's in danger of getting boring.

But then I have been giggling quietly to myself so much this morning, I had to share. As predicted in posts passim, Salik is turning out to be far too much fun to ignore.

When you apply for your tag (as I did on Sunday), you fill out a form with your name, address, mobile number and car registration. If the databases were smart, you'd be able simply to give your vehicle registration number and everything else would be pulled from the database. Which rather points to the fact that the registration database isn't linked to Salik. Which rather points to manual data entry of those forms. Which rather points to delays in getting accounts activated.

So I called the nice Salik people on 800 SALIK (800 72545) and asked why I hadn't yet received my SMS advising me that my account was activated, as advertised. And they said there was a data entry backlog and I should kick my heels for a further 2-3 days.

Today's Gulf News (Emirates Today, for some reason is suddenly silent about Salik) reports a four day delay from readers, with one unhappy chappie saying he applied over a week ago and still hasn't got his SMS.

Oh dear, oh dear. There are only three more shopping days to Salik day and I have only yet seen two cars on the roads wearing their Salik tags. Media reports are a little confusing, but it would appear that 200,000 tags have been distributed in total, with reports of sales of 80,000.

Now. Let us assume that each form can be data entered in an average of two minutes (including downtime, error checking & toilet breaks, I think that's more than reasonable). That would mean 333 forms could be processed by one operator in a working day. So 80,000 forms would entail 240 man-days of data entry. If you had a massive data entry operation with 50 people working on entry, you're looking at 6.6 days' work.

However, we've got 200,000 tags out there and, this being Dubai, most people haven't bought their tags yet. Let us assume, then, that the 80,000 already sold have been data entered (although mine hasn't!). From today, we have another 120,000 tag applications to enter. That's going to take our 50 data entry operators ten days. So they'll be entered around about the 12th July given that no more applications are received.

I am, of course, more than happy to be told my calculations are incorrect and do point out that this is all speculation, guess-work and conjecture. But that's what people do when they're not being told what's happening...

So someone, somewhere is likely sitting underneath a huge and growing pile of forms while retailers will be facing the prospect of a weekend of increasingly angry customers demanding their tags and the call centre's in danger of getting flooded and people whose accounts aren't activated are probably going to start triggering fines or just be too scared to go through the gates...

It's all kicking off rather nicely, isn't it? What larks, Pip!