masthead image

Technology Blog

The Flaws Of Building IP Address Based Applications

Tuesday June 9 2009, 03:32 PM

Suppose you are building a voting booth application. One of the things you want to avoid is letting a user vote multiple times to skew results. How do you prevent this from happening?

This is a chicken and egg problem if you are an Internet developer. The chicken is the user and the egg is the computing device. What's in between is the egg yolk which is the IP address.

Client devices attach to the public Internet via an Internet Service Provider. With most of the world using mobile devices such as a smart phone, laptop or netbook, along with computing devices in locations like the office, home, or university, the problem building applications to uniquely identify a user to a device and IP address is an interesting one.

The short answer to "How do you prevent a user from voting multiple times?", is, "you can't".

Client Devices Cannot Be Guaranteed To Be Associated With A Unique IP Address

Before we even get into this, lets be certain that there is no reliable way to guarantee that an IP address is associated with any client device. An IP address is just a number that identifies a computing device. This IP address is subject to change.

For example, dial up companies rotate IP addresses from an IP pool, thus never guaranteeing a device to have a static IP address. Companies can use Dynamic Host Configuration Protocol (DHCP) to dynamically allocate a pool of IP addresses. As a device goes online, an IP addresses is assigned and when it goes offline it is released back to the address pool. Cable and DSL companies use a similar technique with longer lease times thus simulating a static IP address. Devices can be also be anonymous through proxies.

Therefore, you cannot guarantee a device will always be associated with a particular unique IP address.

Users Cannot Be Guaranteed To Be Associated With A Unique IP Address

You cannot guarantee a person will be associated with an IP address either.

Users can move from device to device. They can be at home on their desktop computer. They can be at the office on their laptop. Computing devices can also be shared among many users, like in a school setting.

Therefore, you cannot guarantee a user will always be associated with a particular IP address.

So What Does Our Voting Application Have To Do?

If you agree with the above two assertions, really the only thing you can do as a developer is create user accounts based on a semi-unique identity (email address) and password. Then, limiting the user to vote on only one topic.

Users who register get an email sent back to their email account. They are then asked by permission to be included as a member to your application. If agreed, they are certified, if they don't, they are removed from the application.

Anonymous users in this case cannot abuse the voting application because, well, they are not allowed to vote. Thus you won't have some joker come in voting repeatedly without approval.

In essence, you base the vote per account. Now sure, there is also the case where a user can create multiple accounts (based on different email addresses) but that is something really you cannot control. For example, how do you know if someone who is using your application from IBM in Tokyo isn't the same person given all IBM Tokyo users may be using the same IP address? Sure, internally IBM will know what device and likely who that person was at the time of login and use. But to you the application developer with a server on the public Internet, you aren't going to know that information.

ISPs, universities, and companies have the ability to collect and associate a user account and IP address to a computing device. As a server application that is made public, you don't have that kind of information coming to you.

As an application developer you could ask the HTTP server for IP information such as:

  • HTTP_CLIENT_IP
  • HTTP_X_FORWARDED_FOR
  • HTTP_X_FORWARDED
  • HTTP_FORWARDED_FOR
  • HTTP_FORWARDED

But I see little point in creating code using this information because as described above, you cannot guarantee unique user to unique IP address.

Summary

When building public Internet applications, the best you can do to identify your user is to force them to register providing their email address and password. Everything in your account is not people based, but account based. People can create multiple accounts associated with multiple email addresses. There is no way for you to limit that and thus it is possible for your traffic and user counts to be skewed. Examples of this are on social networks like Myspace, Facebook, and Twitter.

Implementing any opt-in Internet application that attempts to uniquely identify a person based upon IP address and vice versa, is a waste of effort and rarely guaranteed.