The Simple Joy of “No Phones Allowed”

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

by an author

A few nights ago I saw Jack White in concert. It was a wonderful night, and a big part of that was due to a new rule he has imposed on all his tour dates: no phones.

When you arrive, you have to put your phone into a neoprene pouch, supplied by a company called Yondr, which they lock and give back to you. If you want to use your phone during the show, you can go into the concourse and unlock it by touching it to one of several unlocking bases. The concert area itself remains screen-free.

The effect was immediately noticeable upon entering the concert bowl. Aside from the time-travel-like strangeness of seeing a crowd devoid of blue screens, there was a palpable sense of engagement, as though—and it sounds so strange to say it—everyone came just so they could be there.

The most-significant observation in this article, in my mind, was that even putting a 20-second delay to people using their phones – that is, having to walk out to the concourse to unlock their bags – was sufficient to dramatically remove the temptation for their use. That’s amazing, but unsurprising: Veritasium recently did a video about boredom and how the desire to avoid ever feeling bored (despite its scientifically-demonstrable benefits), coupled with the easy access of instant stimulation from our smart devices, leads us into the well-known check phone, replace, check again cycle (or else “zombie smartphoning”).

I’ve been trying to be better about paying less-attention to my phone, this year, and it’s gone well… except that (as David also observes in the linked article) I’ve become more acutely aware of the feeling of the conversational/interpersonal “void” created when somebody else chances a “quick check” of their phone under the table. I used to blame social media mostly for this – and I still think that it’s an issue, and it’s certainly true that my Facebook/Twitter/Reddit-heavier-using friends are the biggest culprits for getting lost in their devices – but I’ve come to see it as a bigger, more-human issue, coupled with the availability of the new technologies around us.

Similar to how we eat too much fat, and sugar, and meat… simply because it’s available, we crave the stimulation that we can easily get from the device in our pocket to such an extent that we’ve become unhealthy in our habits.

Intercepting HTTPS Traffic from Android Emulator

Mostly for my own benefit, as most other guides online are outdated, here’s my set-up for intercepting TLS-encrypted communications from an emulated Android device (in Android Emulator) using Fiddler. This is useful if you want to debug, audit, reverse-engineer, or evaluate the security of an Android app. I’m using Fiddler 5.0 and Android Studio 2.3.3 (but it should work with newer versions too) to intercept connections from an Android 8 (Oreo) device using Windows. You can easily adapt this set-up to work with physical devices too, and it’s not hard to adapt these instructions for other configurations too.

Intercepting a HTTPS connection to DanQ.me on a virtual Android device.

1. Configure Fiddler

Install Fiddler and run it.

Configuring Fiddler

Under Tools > Options > HTTPS, enable “Decrypt HTTPS traffic” and allow a root CA certificate to be created.

Click Actions > Export Root Certificate to Desktop to get a copy of the root CA public key.

Fiddler's Connections settings

On the Connections tab, ensure that “Allow remote computers to connect” is ticked. You’ll need to restart Fiddler after changing this and may be prompted to grant it additional permissions.

If Fiddler changed your system proxy, you can safely change this back (and it’ll simplify your output if you do because you won’t be logging your system’s connections, just the Android device’s ones). Fiddler will complain with a banner that reads “The system proxy was changed. Click to reenable capturing.” but you can ignore it.

2. Configure your Android device

Android Device Manager - New Device

Install Android Studio. Click Tools > Android > AVD Manager to get a list of virtual devices. If you haven’t created one already, create one: it’s now possible to create Android devices with Play Store support (look for the icon, as shown above), which means you can easily intercept traffic from third-party applications without doing APK-downloading hacks: this is great if you plan on working out how a closed-source application works (or what it sends when it “phones home”).

Android emulator showing network settingsIn Android’s Settings > Network & Internet, disable WiFi. Then, under Mobile Network > Access Point Names > {Default access point, probably T-Mobile} set Proxy to the local IP address of your computer and Port to 8888. Now all traffic will go over the virtual cellular data connection which uses the proxy server you’ve configured in Fiddler.

Android network proxy settings

Drag the root CA file you exported to your desktop to your virtual Android device. This will automatically copy the file into the virtual device’s “Downloads” folder (if you’re using a physical device, copy via cable or network). In Settings > Security & Location > Encryption & Credentials > Install from SD Card, use the hamburger menu to get to the Downloads folder and select the file: you may need to set up a PIN lock on the device to do this. Check under Trusted credentials > User to check that it’s there, if you like.

Installing a Root CA in Android.

Test your configuration by visiting a HTTPS website: as you browse on the Android device, you’ll see the (decrypted) traffic appear in Fiddler. This also works with apps other than the web browser, of course, so if you’re reverse-engineering a API-backed application encryption then encryption doesn’t have to impede you.

3. Not working? (certificate pinning)

A small but increasing number of Android apps implement some variation of built-in key pinning, like HPKP but usually implemented in the application’s code (which is fine, because most people auto-update their apps). What this does is ensures that the certificate presented by the server is signed by a certification authority from a trusted list (a trusted list that doesn’t include Fiddler’s CA!). But remember: the app is running on your device, so you’re ultimately in control – FRIDA’s bypass script “fixed” all of the apps I tried, but if it doesn’t then I’ve heard good things about Inspeckage‘s “SSL uncheck” action.

Summary of steps

If you’re using a distinctly different configuration (different OS, physical device, etc.) or this guide has become dated, here’s the fundamentals of what you’re aiming to achieve:

  1. Set up a decrypting proxy server (e.g. Fiddler, Charles, Burp, SSLSplit – note that Wireshark isn’t suitable) and export its root certificate.
  2. Import the root certificate into the certificate store of the device to intercept.
  3. Configure the device to connect via the proxy server.
  4. If using an app that implements certificate pinning, “fix” the app with FRIDA or another tool.

AMP Is Poisonous

If you’re a web developer and you haven’t come across the Google AMP project yet… then what stone have you been living under? But just in case you have been living under such a stone – or you’re not a web developer – I’ll fill you in. If you believe Google’s elevator pitch, AMP is “…an open-source initiative aiming to make the web better for all… consistently fast, beautiful and high-performing across devices and distribution platforms.”

I believe that AMP is fucking poisonous and that the people who’ve come out against it by saying it’s “controversial” so far don’t go remotely far enough. Let me tell you about why.

AMP logo in handcuffs

When you configure your website for AMP – like the BBC, The Guardian, Reddit, and Medium already have – you deliver copies of your pages written using AMP HTML and AMP JS rather than the HTML and Javascript that you’re normally would. This provides a subset of the functionality you’re used to, but it’s quite a rich subset and gives you a lot of power with minimal effort, whether you’re trying to make carousels, video players, social sharing features, or whatever. Then when your site is found via Google Search on a mobile device, then instead of delivering the user to your AMP HTML page or its regular-HTML alternative… Google delivers your site for you via an ultra-fast precached copy via their own network. So far, a mixed bag, right? Wrong.

What’s poisonous about Google AMP

Ignoring the facts that you can get locked-in if you try it once, it makes the fake news problem worse than ever, and it breaks the core concepts of a linkable web, the thing that worries me the most is that AMP represents the most-subtle threat to Net Neutrality I’ve ever seen… and it’s from an organisation that is nominally in favour of a free and open Internet but that stands to benefit from a more-closed Internet so long as it’s one that they control.

Google’s stated plan to favour pages that use AMP creates a publisher’s arms race in which content creators are incentivised to produce content in the (open-source but) Google-controlled AMP format to rank higher in the search results, or at least regain parity, versus their competitors. Ultimately, if everybody supported AMP then – ignoring the speed benefits for mobile users (more on that in a moment) – the only winner is Google. Google, who would then have a walled garden of Facebook-beating proportions around the web. Once Google delivers all of your content, there’s no such thing as a free and open Internet any more.

So what about those speed increases? Yes, the mobile web is slower than we’d like and AMP improves that. But with the exception of the precaching – which is something that could be achieved by other means – everything that AMP provides can be done using existing technologies. AMP makes it easy for lazy developers to make their pages faster, quickly, but if speed on mobile devices is the metric for your success: let’s just start making more mobile-friendly pages! We can make the mobile web better and still let it be our Web: we don’t need to give control of it to Google in order to shave a few milliseconds off the load time.

We need to reject AMP, and we need to reject it hard. Right now, it might be sufficient to stand up to your boss and say “no, implementing AMP on our sites is a bad idea.” But one day, it might mean avoiding the use of AMP entirely (there’ll be browser plugins to help you, don’t worry). And if it means putting up with a slightly-slower mobile web while web developers remain lazy, so be it: that’s a sacrifice I’m willing to make to help keep our web free and open. And I hope you will be, too.

Like others, I’m just hoping that Sir Tim will feel the urge to say something about this development soon.

Pocket Searching

Pocket dialling was bad enough. I once received a phone call from a friend whose phone called me – as the last number he’d dialled – just as he was putting on a harness in anticipation of doing a bungee jump. So all I got to hear was rustling, and shuffling… and then a blood-curdling scream. Nice one.

A cat on a mobile phone.
Hello? Yes, this is cat. Just thought I’d press some buttons and see who I got.

But in this age of smartphones, the pocket search has become a new threat. Thanks to the combination of touchscreens, anticipatory keyboards (I use SwiftKey, and I’m beginning to think that it knows me better than I do myself), and always-online devices, we’re able to perform quite complex queries quite accidentally. I’ve got a particular pair of trousers which seems to be especially good at unlocking my phone, popping up a search engine, typing a query (thanks to the anticipatory keyboard, usually in full words), and then taking a screenshot and saving it for me, so that I can’t later deny having searched for… whatever it was.

This morning, while cycling to work, I searched for the following (which I’ve reformatted by inserting line breaks, in order to transform it into the sort-of poem you might expect from sombebody both insane and on hallucinogens):

thanks again
and it all goes on
and I will Also
Also A bit LIKE THAT
THE ANSWER is
That you are looking at your Local Ryanair
and a ripening
and a ripening
I can assure are a BIT
and see the new template by clicking here
for
for YOU GUYS
GUYS HAVE YOU ANY COMMENTS
ON MY WAY BACK FROM YOU
And the other side and I will have the same
as a friend or relative
relative humidity
humidity
to you
you are here car
car
and
and embarrassing
embarrassing
the best thing is the first three years and over
over?

Maybe my phone is gradually becoming sentient and is trying to communicate with me. I for one welcome our new robot overlords.

Phone Security == Computer Security

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.

Nokia E7, showing lock screen.
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.

Pattern lock configuration on an Android mobile phone.
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).

iPhone showing the PIN lock screen.
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.

A finger swipes-to-unlock a Samsung mobile phone.
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 –

Cardless Cashpoints

My mobile banking app, showing me a special six digit code.
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.

Cash machine: "Do you wish to carry out a Get Cash or Emergency Cash transaction? [No] [Yes]"
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.

Entering a 6-digit code from a mobile phone into a cash machine.
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.

A cashpoint asking for the PIN a second time, and then asking for the amount of money to withdraw.
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.

Cash machine: "Please take your cash and your receipt."
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?

One Hundred And Sixty

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.

Searching For A Virgin

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.

Idea: mobile app that uses camera and shifts colour-balances to make colours “visible”

This self-post was originally posted to /r/ColorBlind. See more things from Dan's Reddit account.

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!

I have multiple GMail accounts. I’d like to see a different notification icon for each. Any suggestions?

This self-post was originally posted to /r/androidapps. See more things from Dan's Reddit account.

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.

What’s Wrong With My Phone

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)
  • Open-source development likely to thrive
  • User can probably “brick” device
  • Full potential requires learning investment
  • Harder to monetise platform, as a developer
“New model” device (e.g. iPhone, Android)
  • Easy for non-technical users
  • 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!

A New Sensation

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: mightprobablylikelycouldperhaps. 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.

Mobile One-Time-Passwords in Ruby

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.

Off To Norfolk!

[this post was lost during a server failure on Sunday 11 July 2004; it was finally recovered on 12 October 2018]

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).

I’ll drop a blog entry or two while I’m gone.

In the meantime: Merry Christmas, y’all.

Justification Of What You All Already Thought About My Sanity, And About Orange’s Competence

[this post was lost during a server failure on Sunday 11 July 2004; it was partially recovered on 21 March 2012 and fully recovered on 13 October 2018]

As I promised a few days ago, I called Orange today to complain that I hadn’t ever recieved 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 recieved. A new multimedia message. The body of which was as follows:

You
have recieved a Multimedia Message, which your handset unfortunatley
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?

  1. Orange send me a message to apologise for having charged me for receiveing 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.
  2. I complain at length to Orange that I never receieved 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.
  3. 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.
  4. There is no accompanying text message.

Shall I ring them up and complain again?