Calling Abroad

I just got my mobile phone bill … a 25 minute call to a Netherlands landline has cost 25 quid – a pound a minute.

The EU roaming caps apply to non-domestic travel, but seemingly not for the ‘home’ network.

As far as I can tell, if I had a French pay-as-you-go SIM and used that to call the same number, it would have been around a third cheaper (I think, in June, 30p + VAT per minute)

In other words, if you’re going to use mobile, it’s considerably less expensive to use a foreign disposable SIM in the UK to call another country, than it is to use a UK contract phone to do the same.

That’s absurd, no?


As I become older (!), wiser (?) and generally less interested in fiddling about with the innards of software, I’ve become acutely aware of aspects of software development which are more often than not the cause of issue.

Software design is intrinsically an ass-covering occupation. With most budgets and with even the most skilled developers, bugs will be created. Our role is to minimise the frequency and impact of bugs; to work on a basis of zero bugs is (with current development environments) a largely futile exercise.

Computer programming is largely about a series of transitional actions. Functions take an input and produce an output. Cause and effect. This is why unit tests feature in so many programmers’ armouries – they offer a systematic, highly repeatable way of testing that a given function works as expected.

The complexity of functions can be guessed from the number of external inputs they take. The ease of testing is reduced every time the number of inputs increases. This becomes far more complicated when global scope or environment variables come into play – something often overlooked when testing.

So, when building up functions my first soon is to remove as many variable inputs as possible. I treat globals as positively evil, and avoid them unless necessary. Functions with many inputs are also treated with caution. What is a function doing with so many variable inputs? It usually suggests a chain of conditional statements – perhaps the function needs to be split.

Optimisation is another poisonous part of programming. Generally if a cache or other optimisation mechanism is implemented it adds an aspect of unpredictability to the application – another input (or factor) we need to consider when writing and testing. Most developers will implement some form of optimisation without giving it a second thought – a global database connection for instance persists state between functions, which gives an unexpected input for testing purposes.

I accept that optimisations in most cases are both necessary and quite tolerable, provided the developer is aware of them and takes necessary caution around them.

I start with a perfect system – the kind we might hear about in compute science theory. All functions perform one action only, in isolation. There are no globals. Everything is real-time (no offline mode or synchronisation). Then I begin to unravel the optimisations applied. Caching. Globals. Offline mode. Each of these is treated as an unwelcome guest; an unfortunate consequence of our imperfect environments. They are necessary – we live in the real world – but every single one is a potential source of headaches.

This might all sounds like a pursuit of the unachievable dream. I did after all start by saying that zero bug policies are futile, but I do believe we can make as much effort as is reasonably possible to head in that direction, and my personal goal is to avoid as many optimisations as absolutely possible.

Websites + Passwords

If you have an account with any website, they should be making sure the password you use is nice and secure, so if any hacker comes by and breaks into their website your password (which you’ve probably – like everybody else – used on a hundred other websites) won’t be revealed.

One way the website can protect your password is called ‘hashing’. Instead of storing your password, the website stores a ‘hash’ of it. You type your username and password in the usual way, and the website does some clever maths behind the scenes to hash your password for you. The mechanics are pretty dull, but all you need to know for now is that your password is never kept on the website, so nobody can steal it. Nice and secure.

If you’ve ever forgotten your password, the website might offer a link “I’ve forgotten my password”. What happens next will give you some big clues as to the kind of security they use.

If they send you an email with a nice, long link to click ‘Reset my password’ this is usually a good sign.

If however, they send an email with “Hello, your password was kittens45” be warned. This means that the website kept ahold of your password all along. Good news for somebody looking to steal a bunch of passwords.

This might not seem like a big deal. So what if some hacker breaks in to that website, steals all the passwords and runs off laughing? Not too serious if it was just a cookery site or an online kitten album.

However, an awful lot of people use the same password for their GMail, Yahoo or other accounts. They might be using it for their utility bills online. The hacker now has your password. Suddenly that password leak becomes a bit more serious – your email might give other details about you, like your bank account or even more passwords to other sites. The hacker knows your username, your password and can probably now get to your mail, private photos, documents and other websites.

So, we know websites should be at least keeping your passwords safe and hashed. If they’re not doing that, you have to wonder what other security lapses they have made. People invest enormous chunks of their private lives online, and we have precious few indicators of how seriously websites take the issue of security. Some are surprisingly relaxed – and it’s your personal data they’re toying with. Oh, if only I could tell you some horror stories…

Next time you use a website, quickly try the ‘Forgot my password’ link. It (usually) doesn’t actually change your password, and the email they send to you can give an immediate clue about their attitude to your security.

* Notes for the technically minded:
– If you hash, make sure it’s a good one. MD5 is weak and easily cracked.
– Determined hackers might also interfere with the login page and capture the password from there, but most recent cases have shown the password tables to be much juicier pickings.
– The website might be encrypting the password rather than hashing it. I’ve yet to find a ‘regular’ website that does this though – all that I’ve challenged where a password has been returned have simply been keeping it in the clear.

No website

The menu of our local café enthusiastically gives the phone number, email and Facebook page on the front cover. No website.

Our local butchers had an event recently. “Photos are on our Facebook page.” Their website has become a neglected feature which basically serves to redirect the user to Facebook. Their world now happens in Facebook. All roads to that business lead inside.

A quick search elsewhere reveals this is not uncommon at all, and it’s hardly surprising. Facebook had undoubtedly made the barrier for publishing content much lower than ever before – connecting with customers is now a trivial task with instant feedback and gratification.

However, at the risk of sounding like an anti-social-network, Facebook bashing lunatic, I urge these businesses to consider two things. First, can people find the information they need if they don’t have a Facebook account? Second, if Facebook closes its doors or loses its appeal, how easy is it to pull all that content back out and place it somewhere else?

The first issue can be tested. Log out of Facebook and try visiting your own page. Can you see everything? Could a visitor contact you without needing an account? If not, you may be dissuading those customers who have no interest in signing up to Facebook – they’ll simply go elsewhere.

The second is rather more theoretical. Facebook is currently in good health and isn’t likely to be replaced any time soon. It does happen though – Google displaced Altavista. Netscape used to have the dominant browser. Myspace was a hugely popular website but is now largely a memory.

Business owners (like most people) will tend towards the easiest option. Facebook allows the humble user to become an instant publisher: photos, videos and messages are all easy to distribute; interaction with users becomes an incredibly straightforward task.

We could say Facebook has made publishing on the web easy – I think it’s rather more that the current alternatives are too weak, or that they don’t engage well enough with the customers. If we – the do-gooders genuinely believe that Facebook is an evil walled garden (do we, really?) then we ought to be working to lower the barriers for its competition rather than simply sounding the impending doom of all those who follow it.

Now in HTTPS

This blog should now be served over HTTPS. As of today, I’ve switched all traffic coming in on regular ol’ port 80 to its more secure cousin, 443.

In human terms? Most websites use ‘HTTP’ – your computer asks for a page (or an image, or anything else) and the server dutifully sends it back. In most cases, nothing is encrypted which means that everything you see and do on a webpage can be viewed by a third party.

If you’re in your local coffee shop using their free wifi, somebody could well be watching everything you do.

HTTPS is the secure version of this. By using this, everything between your computer and the website itself is encrypted. Nobody in-between can tamper with, or listen in on what you are looking at.

Why is this important? It’s just a blog.

Quite right – most people probably don’t care that they can now read this site over a secure connection – they’ve nothing to hide. 🙂

However, anybody making comments or registering an account here will potentially be giving their email or other personal details as part of the process. Furthermore, I write articles on this blog from various locations and I want to ensure my own details and credentials are not stolen.

What are the downsides?

For starters, HTTPS slows down websites a little. It’s not much (maybe a tenth of a second) but it is a measurable side-effect.

Second, the technique used does not work for Internet Explorer users on Windows XP (and a few other cases). This is potentially still quite a big audience, but the stats for this blog show that it’s of little concern in my particular case.

Third, it costs a bit of money to get a certificate. Not a huge amount, but greater than zero.


All in, I do think the benefits outweigh the negatives and, while the use on a blog is of marginal benefit, I have plenty of other sites and web apps which I am also trialling on SSL.