Archive for November, 2009
Bruce Got Hacked – Why Email Should Be Geo-Restricted
by Brad on Nov.12, 2009, under GeoIP, Security
I received a call from my uncle Bruce 2 days ago – after saying hello I was greeted a friendly yet frantic “I’m in big trouble Brad, my computer has been hacked!”. After getting most of the details of what happened and realising that it was quite unlikely any bank details or other highly confidential details were compromised I arranged to leave work early and see what we could do.
While I spend a considerably amount of my time at work making sure our website is secure I had yet to personally have experienced the wrath of an online scammer. I was intrigued to say the least. Once I arrived we scoped out the problem – one of my uncle’s email accounts had been compromised when he inadvertently tricked into giving away his password. After reviewing the situation it was quite a simple mistake to make, as they had impersonated his email provider in a similar nature to previous contact he had regarding setting his BlackBerry.
It was quite interesting to see how the scammers work. They seemed to have a limited interest in trying to get money out of my uncle directly; they were more interested in trying to impersonate him. By using a line similar to: “I’m stuck in Africa at an art fair with no money, please can you send me £500 so I can get back” they actually managed to get about 3-4 responses from friends offering to help. I’m fairly sure they will also sell entire contact list to spammers for a reasonable fee.
After trying some common techniques for re-enabling access to his account we hit a wall. The scammers had changed all the details required to change an account, such as the alternate email address and secret question. Lucky for Bruce he had his email account linked to his BlackBerry. This they key we needed: by sending a password reset email back to the same address we were able to forward the email to another temporary email address and then follow the usual password reset steps. I say we used a temporary email as there was a chance that this wasn’t going to work, hence we didn’t want the scammer to be aware of another email address, should he check the sent items.
During the password reset process we were asked to provide country information. The scammer would have been asked the same question and it would appear that this is checked against a geo-ip database, hence they were forced to put in a reasonable location of Senegal. They may have been in a surrounding country and were exploiting the errors in the geo-ip database, however the general region seems correct based on the information provided when they were asking for money.
So this makes me ask the question – why can’t we lock our email accounts, such that it is only accessible from certain regions. Banks have this feature for credit cards, and even if they do get a bit over zealous sometimes and block my card while I’m on holiday, it is still a good system. It is my opinion that the leading webmail providers should include an option so that any access from unauthorised regions should be blocked – or at least prevented from making system changes.
For example in my case I would like to restrict access to Europe, North America, Australasia and possibly the Middle East (Another trip to Dubai would be nice!). Additionally I could state that changes to my account may only be done from the UK and Australia. Should I urgently need to make a change there are family and friends that I could call to make the change on my behalf, or simply use a VPN to gain access via a local ISP.
I would also like to be clear that this would be on a per account basis. I would not like to suggest that we block key internet services from developing countries, as that would surely result in even more hardship for the honest citizens of these regions. The system would not be perfect due to the limitations of GeoIP, however it would have most likely protected my uncle seeing as the hack seems to have originated from a place he has not visited.
Enhancing Touch Controls – Doom for iPhone
by Brad on Nov.10, 2009, under iPhone
Since I now catch the train to work instead of riding my Ducati or bicycle I have a bit of extra time in the mornings and nights. I had thought about reading on the trip but so far I have a better toy – iPhone gaming. Maybe a Kindle for Christmas will peak my enthusiasm for reading, so I’ll wait for that.
In the meantime I’ve become addicted to the Doom port for the iPhone. This has only happened in the last couple of days after a recommendation from a colleague. My previous addictive game was GeoDefence Swarm, which I would highly recommend, although that will have to take a back seat to Doom for the time being.
I’ve played quite a lot of Doom in my time, although almost all of it was either single player with God mode on, or Deathmatches with guys from school over our 14.4kbps modems (the good old days of init strings). The iPhone port has actually got me playing the single player game properly for the first time ever – 16 years after it’s initial release.
Perhaps the biggest issue with the game is the control system, the touch screen is quite hard to use at first. After playing most of episode 1 (8 levels) I have added something that is quite useful. The biggest problem with the control system is not the responsiveness, it is the lack of any markings on the screen that help your fingers back to the centre points of each control area. I experimented with Blu-Tack, and while it worked ok my fingers would get caught up if I applied to much pressure. It would also obstruct the screen when not playing Doom.
I went to my local phone mobile phone store and picked up a cheap iPhone screen protector for £3. These generally come with cut out sections for the ear piece and the home button. These two parts are actually almost the perfect shape for each of the control areas when using the “Ultimate” control scheme – the left area requires a rectangular shape, while the right requires a circular disk. Placing these in the correct area results in subtle raised ridges that enhance the controls considerably.
The great thing about this solution is there is no chance of damaging the phone, and then when your bored of Doom simply peel off the stickers. If you are worried about the stickers coming off prematurely simply place the full screen protector over the top, which will firmly hold them in place without effecting much else. For such a cheap price so far this is working well, hopefully it will help me get through the Shores of Hell
Performance issue with IE7 caused by background images
by Brad on Nov.05, 2009, under Web Development
While updating the visual design of blinkbox.com a few months back we noticed something wasn’t right in IE7 – the performance was terrible. IE 7 has been around a lot longer than many of the other browsers we currently support in our level 1 tier, and is starting to show its signs of age.
The problem manifested itself mainly as a one second or more delay when hovering over images. Typically this would be a trivial operation for a browser, as it was simply applying the :hover classes for the element.
A bug was raised and I started the investigation by checking the usual culprits, such as incorrect binding of javascript events, HTML issues, CSS selectors that had run wild, and so on. A search on Google yielded no usable results that helped, either. Since none of these had improved the performance of the page, I started to get a bit more aggressive with my bug hunting.
I removed all the images from the page and this worked, although that wasn’t a solution that we could use. After carefully working through it, it turned out to be an issue with only the background images that we were using.
Now there was nothing really special about the background images, just simple PNGs, 1 pixel wide with repeat-x on them, which are then used to form a gradient. Standard stuff for a web page.
Technically, all of our gradients are bundled together into one image and then positioned using CSS, so I checked to see if that was the cause of the problem. One of the options of our image bundling system is the ability to have the images split up and served as separate files. After giving that a go it was apparent that it had no effect.
My next thought was that perhaps the number of repeating images were to blame. I made a quick check by disabling the repeat-x, and the site started running like normal. Realising that this was the issue I used the gradient generator to output wider images (20px), and voilà, the performance issues were sorted for good. So, if you are going to use a lot of gradients, and would like to keep your site running smoothly, then make sure they are more than 1px wide, as IE7 just can’t handle it.
*Of note blinkbox.com uses over 4ooo pixels of vertical gradients site wide, so this might be an extreme case


