I recently had occasion to buy a product from an online company. Having added the item to my basket, I went to the checkout and entered my credit card details, then pressed the confirmation button to move on to the 3-D Secure section (more familiarly known as “Verified by Visa” or Mastercard’s SecureCode).
I was quite surprised when my card was then rejected. So I tried again, in case there had been a timeout between the merchant and the merchant account provider. Still no joy.
My next step was to contact the vendor to ask if there was any reason why my card had been rejected. It transpires that the company use geolocation functionality to obtain your location from your IP address and then compare the town with the town you gave as your credit card address. The vendor told me that it had proven effective in combating fraud, as quite often the fraudsters won’t be based in the same city as the credit card owner.
I can certainly understand the premise behind the implementation, and any attempts to reduce fraud only serve to help the consumer, and keep the vendor’s costs down. The trouble is, geolocation data just isn’t that reliable.
Nowadays, many people are quite happy to purchase items using their mobile phone or tablet over 3G (or 4G if you’re lucky) whilst they are on the move. As you move around, your phone may pick up a different broadcast tower, and depending on your provider, your IP address could change as the broadcast towers reregister you with the network. In any case, even if this doesn’t happen, the results are unlikely to be accurate. The reason is simple.
Whether you are connecting to the internet over a mobile technology or via broadband through your Internet Service Provider (ISP), the ISP typically has a range of IP addresses that they hand out to their customers on a time-based period, although often the IP address will be retained for some time. As they keep a block of IP addresses for use, these aren’t necessarily assigned to a particular geographical region. Furthermore, although the W3C have been defining an API for geolocation there is no clear definition of how your location should be, or can be identified.
A case in point: I used two different online services (IP2Location and IPLigence) to check my location based on my IP address. I first tried it with my broadband connection, expecting them to give me the same, but erroneous answer. Surprisingly, both gave completely different results: one in Worthing, West Sussex, and one in Sheffield, South Yorkshire, from the same IP address. As a control, I introduced another service to check it to see if one of the first two was just low quality, Free Geo IP. This came out with my location as Wolverhampton, in the West Midlands. So, from three different sources, I got three different geographical locations, none of which, I should point out, is my home town.
I then tried the same test using my mobile phone over 3G. Again, I got different results, but this time only two: Westminster, in London; and Newbury, in Hampshire. And, unsurprisingly, none of those are my home town either. And I can honestly say that I am sitting in my office writing this, and don’t have anything fancy like TOR switched on, so these are genuine results.
So whilst I commend the online vendor for trying to combat fraud using various techniques, and according to them, successfully, I can’t help but wonder how many consumers have been turned away from their site precisely because of the poor quality of the geolocation data. In any event, I’m not keen on IP addresses being tied down to a particular location: my location should be an explicit personal decision to divulge, not that of some clever computer hackery.
Irrespective of my personal opinion, geolocation data just isn’t reliable enough to use to validate a consumer’s location. Quite aside from the lack of accuracy, shopping on the move or from a place of work would also mean that your purchase could potentially be blocked. Until the technology matures, implementing it in this manner causes more problems than it cures.
0 Comments