The explosion of smartphone ownership over the last decade has put powerful multi-function computers into the pockets of almost
half of us. But despite the fact that the average smartphone contains at least as much personally-identifiable information as its owner keeps on their home
computer (or in dead-tree form) at their house – and is significantly more-prone to
opportunistic theft – many users put significantly less effort into protecting their mobile’s data than they do the data they keep at home.
Too late, little Nokia E7: I’ve got physical access to you now.
I have friends who religiously protect their laptops and pendrives with TrueCrypt, axCrypt, or similar, but still carry around an unencrypted mobile phone. What we’re talking about here is a device that contains all of the contact
details for you and everybody you know, as well as potentially copies of all of your emails and text messages, call histories, magic cookies for social networks and other services, saved passwords, your browsing history (some people would say that’s the
most-incriminating thing on their phone!), authentication apps, photos, videos… more than enough information for an attacker to pursue a highly-targeted identity theft or
phishing attack.
Android pattern lock: no encryption, significantly less-random than an equivalent-length PIN, and easily broken by a determined attacker.
“Pattern lock” is popular because it’s fast and convenient. It might be good enough to stop your kids from using your phone without your permission (unless they’re smart enough to do
some reverse smudge engineering: looking for the smear-marks made by your fingers as you unlock the device; and let’s face
it, they probably are), but it doesn’t stand up to much more than that. Furthermore, gesture unlock solutions dramatically reduce the number of permutations, because you can’t repeat a
digit: so much so, that you can easily perform a rainbow table attack on the SHA1 hash to
reverse-engineer somebody’s gesture. Even if Android applied a per-device psuedorandom salt to the gesture pattern (they don’t, so you can download a prefab table), it doesn’t take long
to generate an SHA1 lookup of just 895,824 codes (maybe Android should have listened to Coda Hale’s advice and used BCrypt, or else something better still).
An encrypted iPhone can be configured to resist brute-force attacks by wiping the phone after repeated failures, which replaces one security fault (brute-force weakness) with another
(a denial of service attack that’s so easy that your friends can do it by accident).
These attacks, though (and the iPhone isn’t bulletproof, either), are all rather academic, because they are
trumped by the universal rule that once an
attacker has physical access to your device, it is compromised. This is fundamentally the way in which mobile security should be considered to be equivalent to computer security.
All of the characteristics distinct to mobile devices (portability, ubiquity, processing power, etc.) are weaknesses, and that’s why smartphones deserve at least
as much protection as desktop computers protecting the same data. Mobile-specific features like “remote wipe” are worth having, but can’t be relied upon alone – a wily attacker
could easily keep your phone in a lead box or otherwise disable its connectivity features until it’s cracked.
The bottom line: if the attacker gets hold of your phone, you’re only as safe as your encryption.
The only answer is to encrypt your device (with a good password). Having to tap in a PIN or password may be less-convenient than just “swipe to unlock”, but it gives
you a system that will resist even the most-thorough efforts to break it, given physical access (last year’s
iPhone 4 vulnerability notwithstanding).
It’s still not perfect – especially here in the UK, where the RIPA can be used (and has been used) to force key surrender. What we really need is meaningful, usable
“whole system” mobile encryption with plausible deniability. But so long as you’re only afraid of identity thieves and phishing scammers, and not
being forced to give up your password by law or under duress, then it’s “good enough”.
Of course, it’s only any use if it’s enabled before your phone gets stolen! Like backups, security is one of those things that everybody should make a habit of thinking
about. Go encrypt your smartphone; it’s remarkably easy –
The mobile app presents you with a special six-digit code that is used to withdraw the cash.
RBS Group this week
rolled out a service to all of
its customers, allowing them to withdraw cash from an ATM without using their bank card. The service is based upon the same technologies that’s used to provide emergency access to
cash by people who’ve had their cards stolen, but integrates directly into the mobile banking apps of the group’s constituent banks. I decided to give it a go.
The first step is to use the mobile app to request a withdrawal. There’s an icon for this, but it’s a bit of a mystery that it’s there unless you already know what you’re looking for.
You can’t make a request from online banking without using the mobile app, which seems to be an oversight (in case you can’t think of a reason that you’d want to do this, read on:
there’s one at the end). I opted to withdraw £50.
Next, it’s off to find a cash machine. I struck out, without my wallet, to try to find the nearest Royal Bank of Scotland, NatWest, or Tesco cashpoint. The mobile app features a GPS
tool to help you find these, although it didn’t seem to think that my local Tesco cashpoint existed, walking me on to a branch of NatWest.
The readout of the cash machine demonstrates that the roots of the “Get Cash” system lie in the older “Emergency Cash” feature: the two are functionally the same thing.
As instructed by the app, I pressed the Enter key on the keypad of the cash machine. This bypasses the usual “Insert card” prompt and asks, “Do you wish to carry out a
Get Cash or Emergency Cash transaction?” I pressed Yes.
The number displayed upon the screen is entered into the cash machine.
The ATM asked for the PIN I’d been given by the mobile app: a 6-digit code. Each code is only valid for a window of 3 hours and can only be used once.
The cash machine asks for the PIN a second time, and then asks for the sum of money to be withdrawn.
I’m not sure why, but the ATM asks that the PIN is confirmed by being entered a second time. This doesn’t make a lot of sense to me – if it was mistyped, it’d surely fail anyway (unless
I happened to guess another valid code, within its window), and I’d simply be able to try again. And if I were an attacker, trying to guess numbers, then there’s no difficulty in typing
the same number twice.
It’s possible that this is an attempt at human-tarpitting,
but that wouldn’t be the best way to do it. If the aim is to stop a hacker from attempting many codes in quick succession, simply imposing a delay would be far more effective (this is
commonplace with cash machines anyway: ever notice that you can’t put a card in right after the last transaction has finished?). Strange.
Finally, the ATM asks what value of cash was agreed to be withdrawn. I haven’t tried putting in an incorrect value, but I assume that it would refuse to dispense any cash if the wrong
number was entered – this is presumably a final check that you really are who you claim to be.
It feels strange taking money and a receipt from a cashpoint without first having to retrieve my card. I spent a few minutes after the experience with a feeling that I’d forgotten
something.
It worked. I got my money. The mobile app quickly updated to reflect the change to my balance and invalidated the code: the system was a success.
The banks claim that this will be useful for times that you’ve not got your card with you. Personally, I don’t think I ever take my phone outdoors without also taking my wallet with me,
so the chance of that it pretty slim. If my card were stolen, I’d be phoning the bank to cancel the card anyway, so it wouldn’t save me a call, either, if I needed emergency cash. But
there are a couple of situations in which I’d consider using this neat little feature:
If I was suspicious of a possible card-skimming device on a cash machine, but I needed to withdraw money and there wasn’t an un-tampered ATM in the vicinity. It’d be nice to know
that you can avoid having your card scanned by some kid with a skimmer just by using your phone to do the authentication rather than a valuable piece of plastic.
To send money to somebody else. Using this tool is cheaper than a money order and faster than a bank transfer: it’s an instantaneous way to get small sums of cash
directly into the hands of a distant friend. “Sure, I’ll lend you £50: just go to a cash machine and type in this code.” I’m not sure whether or not this is a legitimate
use of the service, but I can almost guarantee that it’ll be the most-popular. It’ll probably be reassuring to parents of teenagers, for example, who know that they can help their
offspring get a taxi home when they’ve got themselves stranded somewhere.
What do you think? If you’re with RBS, NatWest or Tesco, have you tried this new mobile banking feature? Do you think there’s mileage in it as an idea, or is it a solution in need of a
problem?
When I first went to university, in 1999, I got my first mobile phone. Back then, messaging features on mobiles were a bit more simplistic than they are today.
For example, phones were only just starting to appear that could handle multi-SMS messages. For those without this feature there was a new skill to be learned.
With practice, we got to be particularly good at cutting out messages down to the requisite number of characters to fit into a single SMS: just 160 characters.
We even learned how to meaningfully split messages in our heads, with indicators (ellipses, or numbers showing message parts), to carry longer concepts. (4/19)
Even when multi-message capable phones came out (I got one in 2000), these skills were still useful. At 10p or 12p per message, you soon learned to be concise.
Nowadays, this skill has lost its value. With more and more people having “unlimited SMS” plans or enormous quantities of credits, there’s no need to be brief.
If you’ve got an iPhone, you don’t even get told how long your message is, I hear. You just keep typing. And that’s not uncommon on other kinds of handset too.
Your phone’s still splitting your message up, in the background. Putting markers in, so that other phones can understand. And these markers are human-readable.
Just in case your message is going to a phone that’s over about 12 years old, your smartphone makes sure that the markers would be understood by humans. (9/19)
So now we’ve got smartphones talking to each other in a language that humans designed to talk to one another in. Does that feel really strange to anybody else?
I looked at my phone while I wrote a message, today. I noticed that number in the corner, that indicated that my message would span 3 texts. And I didn’t care.
Why would I? It’s a vestige of an older form of communication. Someday, it’ll look as primitive as the paintings on the walls of caves, daubed by early humans.
But for now, I remember. And, somehow, the skill I learned all those years ago – a trick that’s alien to almost anybody younger than me – has a new, fresh use.
Twitter. 140 character messages. A little bit less than a text, which seems strange. Are they really trying to make us even more brief than those early
phones?
The skill is still the same. Think ahead. Prune. Plan. Snip. And, if you absolutely must span several messages, make it clear to your reader so that they know.
I see a whole new generation of people learning this skill that I once learned. It’s not the same (it never will be): they don’t pay 10p every time they tweet.
But you know what? It’s just as pointless now as it was the first time around. If you want to say something, say it. If 36p is too much, risk a 10-second call!
And in the case of the Twitter generation: if your message doesn’t fit on Twitter, then it probably doesn’t belong on Twitter. I’m a 160-character-or-more man.
I’m not sure I’m cut out for the Twitterverse with its 140-character limits. But it’s nice to remember how to think in 160, just like I have in this blog post.
You just can’t rely on GMail’s “contacts” search any more. Look what it came up with:
Not a result I'd commonly associate with the word "virgin".
With apologies to those of you who won’t “get” this: the person who came up in the search results is a name that is far, far away, in my mind, from the word “virgin”.
In not-completely-unrelated news, I use a program called SwiftKey X on my phone, which uses Markov chains (as I’ve described before) to
intelligently suggest word completion and entire words and phrases based on the language I naturally use. I had the software thoroughly parse my text messages, emails, and even this
blog to help it learn my language patterns. And recently, while writing a text message to my housemate Paul, it suggested
the following sentence as the content of my message:
I am a beautiful person.
I have no idea where it got the idea that that’s something I’m liable to say with any regularity. Except now that it’s appeared on my blog, it will. It’s all gone a little recursive.
I’m not colourblind, and I’m not really a mobile developer, so maybe there’s something I’ve missed, but I’ve got an idea for an app and I thought I’d run it by you guys to
see if there’s something I’ve missed.
Mobile processing power is getting better and better, and we’re probably getting close to the point where we can do live video image manipulation at acceptable framerates (even 10
frames/sec would be something). So why can’t we make an app that shifts colours as seen by the camera to a particular different part of the spectrum (depending on the user’s
preferences).
For example, a deuteranomat (green weak, difficulty differentiating through the red/orange/yellow/green spectrum) might configure the software to shift yellows and greens to instead
be presented as purples and blues. The picture would be false, of course, but it would help distinguish between colours in order to make, for example, colour-coded maps readable.
I was thinking about how video cameras can often “see” infa-red (try pointing a remote control at a video camera and pressing the button), and present it to the viewer as white or
red, when I saw a documentary with some footage of “how bees see the world”. Bees have vision of a similar breadth of spectrum to humans, but shifted well into the infa-red range (and
away from the blue end of the spectrum). In the documentary, they’d filmed some flowers using a highly infa-red sensitive camera, and then they’d “shifted” the colours around the
spectrum in order to make it visible to normal humans: the high-infa-reds became yellows, the low-infa-reds became blues, and the reds they left as reds. Obviously this isn’t what
bees actually experience, but it’s an approximation that allows us to appreciate the variety in their spectrum.
Can we make this conversion happen “live” on mobile technology? And why haven’t we done so!
The first of the two apps mentioned in this article – “Gmail Notifier” – sounds perfect, but doesn’t seem to exist any
more.
GMail Notifier + Widgets looks like it might do it (it’s designed to do different icons
depending on labels). Does anybody have any experience with this?
Or any other suggestions? I’m running CM7.1 on a HTC Sensation, in case it matters.
In my review of my new HTC Sensation earlier this month, I tried to explain how
my new phone – with it’s swish and simple interface – didn’t feel quite… geeky enough for me. I picked up on the way that it’s process management works, but I’ve since
realised that this is only symptomatic of a deeper problem. This is entirely to do with the difference between traditional computers (of which my old N900 was one) and modern consumer-centric devices (which, inspired by the iPod/iPhone/iPad/etc.) try
to simplify things for the end-user and provide strong support for centralised repositories of pre-packaged “apps” for every conceivable purpose.
To take an example of the difference: my N900 ran Linux, and felt like it ran Linux. As a reasonably-sensible operating system, this meant that all of the applications on it
used pretty much the same low-level interfaces to do things. If I wanted, I could have installed (okay, okay – compiled) sshfs, and be reasonably confident that every application on my phone, whether it’s a media player or a geocaching application
or whatever, would use that new filesystem. I could store my geocaching .gpx files on an SSH-accessible server somewhere, and my phone could access them, and my geocaching
app wouldn’t know the difference because I’d have that level of control over the filesystem abstraction layer.
Similarly, if I installed a game which made use of Ogg Vorbis to store
its sound files, which therefore installed the Vorbis codecs, then I can expect that my media player software will also be able to make use of those codecs, because
they’ll be installed in the standard codec store. This kind of thing “just works”. Okay, okay: you know as well as I do that computers don’t always “just work”, but the principle is
there such that it can “just work”, even if it doesn’t always.
On these contemporary smartphones, like the iPhone, Android devices, and (I assume) modern BlackBerrys, the model is different: individual applications are sandboxed and packaged up
into neat little bundles with no dependencies outside of that provided by the platform. If you have two applications installed that both use sshfs, then they both have to
include (or implement) the relevant bundle! And having them installed doesn’t automatically give sshfs-like functionality to your other filesystem-accessing tools.
It’s not all bad, of course: this “new model” is great for helping non-technical users keep their devices secure, for example, and it means that there’s almost no risk of dependency hell. It’s very… easy. But I’m still not
sure it quite works: I’ll bet that 90% of users would install an application that demands dubious levels of permissions (and could, for example, be stealing their address book data for
sale to scammers) without even thinking about the risks, so the security benefits are somewhat nullified.
In summary:
Pros
Cons
Traditional-computing device (e.g. N900)
User actually “owns” device
Applications to be combined (e.g. pipes, automation, new middleware)
More secure (in theory) as platform exposes little
Centralised “app store”/”marketplace”
Potentially limiting for technical users
Only as secure as the user is savvy.
Centralised “app store” store can act as a “lock in”
Needless to say, the new model devices are winning, and already tablet computers powered by the very same platforms as the mobile phones are beginning to be seen as a simpler, easier
alternative to conventional laptops. It’s to be expected: most of today’s users don’t want a learning curve before they can use their smartphone: they just want to make some calls, play
Angry Birds a bit, keep up with their Facebook friends, and so on.
But I hope that there’ll always be room for a few folks like me: folks who want to tinker, want to play, want to hack code for no really benefit but their own pleasure… and without
having to shell out for a developer license in order to do so!
I’ve recently gotten a new phone – a HTC Sensation running
Android 2.3, and I thought I’d offer up a few thoughts on
it. But first…
Hang on: what was wrong with your old phone?
Well-remembered! You’re right, of course, that last year I got a Nokia N900, and that it was the
best mobile communications device I’d ever owned. I don’t care so much about a slim profile or an “app store”, but I do care about raw power and geeky hardware features, and the N900
delivers both of those in spades. I’ve had several phones that have, at the time, been the “best phone I’ve ever owned” – my 7110 and my N96 both also earned that distinction, whereas my 7610 and my C550 – the latter of which had only one redeeming feature – fell far short.
Nokia N900 with keyboard extended
Awesome though it is, with it’s beautiful hardware keyboard, mighty processor, FM receiver and transmitter, Bluetooth and IR, etc., and completely unlocked,
tamper-friendly architecture, the N900 suffers from one terrible, terrible flaw: for some reason, the engineers who built it decided to mount the Micro-B USB port (used for charging,
tethering, mounting etc. the phone) not to the hard plastic case, but to the fragile inner circuit board. Allow me to illustrate:
A cross-section of a Nokia N900, showing how the USB port is mounted directly to the circuit board, and doesn't touch the hard plastic case.
Why is this a problem? Well, as Katie explained to me at the New Earth housewarming party,
most of her other friends who’d had N900s had encountered a problem by now, whereby the USB cable used to charge the device eventually puts a strain on the connection between the port
and the board, tearing them apart. “Nope,” I told her, “I’ve never had any such problem with mine.”
A cross-section of a Nokia N900, showing the USB port snapped off by the USB cable.
Looks like I spoke too soon, because that very week, I managed to break my N900 in exactly this way. My theory: that girl is cursed. I shall be attempting to
exorcise the anti-technology demons in her the very next time I see her, possibly in some kind of ceremony involving high-voltage direct current. In any case, I found myself with a
phone that I couldn’t charge.
So you replaced it?
No, of course not. My N900 remains a fantastic palmtop and a great device. It’s just got a minor problem in that it’s no longer possible to charge or “hard”-tether it to anything any
more. The latter problem was an easy one to fix: a separate battery charger (I already carry a spare battery for it, so this was no hardship), bought for about £4 on eBay, made it easy
to keep the device rolling. The second problem’s not so much of an issue, because I tend to do all of my synchronisation by Bluetooth and WiFi anyway. But even if
these were an issue, it looks like a pretty
simple job to re-solder the USB port (and epoxy it to the case, as it should have been to begin with!). I might give it a go, some day, but my current soldering iron is a little big
and chunky for such fine and delicate work, and I’m a little out of practice, so I’ll save that project for another day.
The repairing of a Nokia N900 USB port
However, I’m a big believer in the idea that when the Universe wants you to have a new phone, it finds a fault with your current phone. Perhaps this is the geek equivalent of thinking
that “When God
closes a door, He opens a window”.
So: I’ve got myself a HTC Sensation, which narrowly beat the Sony Ericsson Xperia Arc after carefully weighing up the reviews. I’d always planned that I’d try an
Android device next, but I’d originally not expected to do so until Ice Cream Sandwich, later this year. But… when the Universe closes your USB Port, it
opens a Gingerbread shop… right?
The New Sensation
After a few difficulties relating to my name – it turns out that my mobile
phone network has recorded my name correctly in their database, and I can’t change it, but whenever I use their web-based checkout it asks me to enter a longer surname even though I
don’t have a surname field to change – I finally received my new phone.
HTC Sensation seen from the back, front, and side.
The first thing one notices about this phone is that it’s fast. Blindingly fast. I’ve used a variety of Android-powered HTC devices before, as well as other modern
touchscreen smartphones like the iPhone, and I’m yet to use anything that consistently ramps up high-end graphics and remains slick and responsive like this does. Its mighty dual-core
1.2GHz processor’s the cause of this, little doubt. I originally worried that battery life might be limited as a result – I don’t mind charging my phone every night, but I don’t want to
have to charge it during the day too! – but it’s actually been really good. Using WiFi, GPRS, GPS, playing videos, surfing the web, and other “everyday” tasks don’t put a dent in the
battery: I’ve only once seen it dip to under 10% battery remaining, and that was after 40 hours of typical use during a recent camping weekend (with no access to electricity).
It’s also been really well-designed from a usability perspective, too. Those familiar with Android would probably just start using it, but I’ve not had so much exposure to the platform
and was able to come to it with completely fresh eyes. Between Android 2.3 and HTC Sense 3, there’s a nice suite of “obvious” apps, and I didn’t have any difficulty synchronising my contacts, hooking
up my various email accounts, and so on. There are some really nice “smart” touches, like that the phone rings loudly if it thinks it’s in a bag or pocket, more quietly after you pick
it up, and silences the ringer completely if you pick it up from a table and flip it from face-up to face-down. These simple gestural touches are a really nice bit of user interface
design, and I appreciate the thought that’s gone into them.
Browsing movies for HD streaming on the HTC Sensation.
The Android Marketplace is reasonable, although I feel as though I’ve been spoiled. On the N900, if there was an application I needed, I usually already knew what it was and where I’d
find it: then I’d either apt-get it, or download the source and
compile it, right there on the device. For somebody who’s already perfectly confident at a *nix command-line, the N900 is fab, and it feels a little restrictive to have to
find equivalent apps in a closed-source environment. It’s not that the pricing is unreasonable – most of the applications I’ve wanted have been under a quid,
and all have been under £4 – it’s just that I know that there are FOSS alternatives that would have been easy to compile on my old device: I guess it’s just a transition.
On the other hand, the sheer volume of applications so-easily available as the Android Market is staggering. I’ve been filled with app ideas, but every idea I’ve had but one or
two already exist and are just waiting to be installed. It’s a little like being a kid in a candy store.
It’s also taking me quite some time to get used to the way that process management works on an Android device. On Android devices, like the iPhone/iPad, returning to the home screen
doesn’t (necessarily) close the application, but it might – that’s up to the developer. If it doesn’t, the application will probably be “paused” (unless it’s
a media player or it’s downloading or something, then it’ll likely keep going in the background). And when you re-launch the same application, it could be
simply unpausing, or perhaps it’s relaunching (in which case it may or may not restore its previous state, depending on the whim of the developer)… You see
all of the keywords there: might, probably, likely, could, perhaps. Great for most users, who don’t want to have to
think about what their phone is doing in the background, but it feels like a step backwards to me: I’m used to being able to ALT-TAB between
my currently-running applications, to know what’s running, when (and I can always use top and find out exactly what resources a process is eating). Putting all of this process management into the hands of
developers feels to me like giving up control of my device, and it’s a challenging change to undergo. Yes: despite the openness of the platform, Android feels just
a little out of my control compared to what I’m used to.
Hacker's Keyboard, my preferred keyboard layout for SSH, etc.
Switching from a physical to a virtual keyboard for the first time is a significant change, too, and it’s slowed me down quite a lot, although applications like SwiftKey X – with its incredibly intelligent personalised predictions – and Hacker’s Keyboard – which gives me back some of the keys I was “missing” – have helped to ease the
transition a lot.
In summary: the HTC Sensation seems to be a fantastic device, and I’m really enjoying using it. I’ve got a few niggles to contend with, but these are all things that were destined to
catch me out upon switching away from a platform as open as the N900, and they’re not severe enough to make me give up and get an N950 instead: I’m reasonably confident that I’ll come
to love the Sensation and we’ll go on to be very happy together.
But will it become my latest “best phone ever”? Time will tell, I guess.
I recently came across the Mobile One-Time-Passwords project, which aims to make a free, secure alternative
to commercial two-factor authentication systems (like SecurID). The thinking is pretty simple:
virtually everybody now carries a mobile phone capable of running basic applications, so there’s no reason that such an application couldn’t provide the processing power to generate
one-time-passwords based on a shared secret, a PIN number known only to the authenticating party and to the server, and the current date and time stamp.
Great!
But it turns out that despite there being libraries to produce server-side implementations of the technology in PHP, Perl, and C, nobody had yet bothered to write one in that most
marvelous of programming languages, Ruby.
Well, now I have. So if anybody’s got the urge to add one-time-password based security to their Rails or Sinatra
app, or would like to write an MOTP client for their Ruby-capable smartphone: well, now you can.
Geeky winnage! This evening I wrote a pair of applications enabling me to use my new Bluetooth-enabled mobile phone as a remote
control for WinDVD, the DVD playing software I use on my computer.
Not just a geeky project, this is fuelled by a genuine need: every Troma Night, when the pizza arrives, we end up scrambling for the keyboard
in order to pause the film, or I find myself wandering back and forwards, trying to set the volume to an audible-to-all but not-deafening level. With the aid of this new funky toy, I
can do this from my seat. Toy.
I’m looking forward to other ideas for uses for this technology. Tools already exist to allow you to control your media player and
PowerPoint presentations using a Bluetooth mobile phone, but I’m sure that there are more useful applications that I can use in order to improve my own, personal geeky life.
Claire and I are leaving Aberystwyth for Norfolk! Off to spend Christmas with her folks before heading up to Preston on Boxing Day to be with my family.
Have barely begun wrapping presents. For that matter, I still haven’t had delivered my mum’s present. Or one of Claire’s. Damned freaky postmen. Or something.
In any case, I’ll be in and out of internet access (well, technically, I’ve now put my Psion 5mx back into
active service, which, combined with my funky GPRS mobile phone, puts me online ‘everywhere’, but hey: I think I’ve downloaded a telnet client so wherever I go I *theoretically* have
e-mail access… we’ll see).
As I promised a few days ago, I called Orange today to complain that I hadn’t ever received the two messages for which I’ve had the cost refunded. The
first couple of people said that there was nothing that they could do, but a lot of harassment and a few calls later, and I persuaded them to send me the latter of the two messages,
which is apparently a Christmas greeting.
A few minutes later, my phone beeped to let me know that a new message had been received. A new multimedia message. The body of which was as follows:
You
have received a Multimedia Message, which your handset unfortunately
cannot support. Please refer to the accompanying text message and follow
the instructions to view the message from the web.
WTF???
Did I miss something here?
Orange send me a message to apologise for having charged me for receiving some messages from them, and give me a refund, even though I never received said messages. Can’t find any
mention of them on my bill, either.
I complain at length to Orange that I never received the messages that I wasn’t billed for (I don’t mention that I don’t seem to have paid – they might take the refund back out of
my next bill or something), and they promise to re-send it.
The message arrives on my multi-media phone – the phone that they know I have and apparently already sent this message to, once, but it’s in a format that my phone can’t
understand.
Today, Orange sent me a text message apologising for charging me for two picture messages earlier this year, and have apparently credited me 80p
as a gesture of compensation. The Register reports that this has happened to others, too, but I can’t help but feel that
Orange’s mistake is even larger than they thought it was – I never received these picture messages in the first place!
I’m tempted to call them and complain that I didn’t ever receive the two picture messages for which I’m having my money refunded, but as I’m not even sure that I was charged for them,
either (can’t see it on my bill), I’ll probably lose me free 80p if I do. Decisions, decisions.
I can understand the warnings that you should not drive while talking on your mobile phone, but this extract from a
report by the BBC about phone usage in Japan really says it all:
“People in Japan use their mobile phones to do much more than talk… …only this weekend, newspaper ads warned phone users to avoid walking and writing emails at the same time.”
![Cash machine: "Do you wish to carry out a Get Cash or Emergency Cash transaction? [No] [Yes]"](/_q23u/2012/06/IMG_5833-300x200.jpg "Cash machine: \"Do you wish to carry out a Get Cash or Emergency Cash transaction? [No] [Yes]\"")
Great!
But it turns out that despite there being libraries to produce server-side implementations of the technology in PHP, Perl, and C, nobody had yet bothered to write one in that most
marvelous of programming languages, Ruby.