Option to Disable IP Logging

The following code in settings.php should make sure the IP address cannot be logged: I can't see that it would cause any problems.

$_SERVER['REMOTE_ADDR']='0.0.0.0';

Given the simplicity and effectiveness of this hack, is it worth developing, testing and maintaining code to do the same thing?

Perhaps it should be added to the settings.php file but commented out (lots of things are) with a "to do X, uncomment this line" comment?

Will do and will report if there are problems, so the line could be added.

It would be nice to stop the *logging* of IP addresses without stopping their *use*. (This is particularly the case with the ability to use IP addresses to guess at location, as done by FolkJam.org).

One question is why is the IP address logged in a bunch of places if it isn't used. Aside from the contact form (moving the number of submissions per hour to a high number is a workaround for its use of IP addresses), where else should we be attentive to possible side effects of setting $_SERVER['REMOTE_ADDR']='0.0.0.0' ?

~ ben :: Agaric Design Collective :: http://AgaricDesign.com

Hm. Here's an idea. Could a contrib module set the IP address to an md5 of itself? That way it's still unique, so flood control works, but it's hard/impossible to track back to the original person.

Someone with a more paranoid security mind, would that work? :-)

This is still important.

I hear from the Indymedia Worcester group that Akismet, for one, gets flaky without IP addresses, so for a site that has to allow anonymous content but cannot allow IP logging of its users (the classic Indymedia setup), the settings.php hack to set all IP addresses to naught is not a practical solution.

Constant scrubbing looks like the only current approach to help protect users from intrusion of their privacy.

Really, though, it should be an option to simply tell Drupal core, at least, not to log IP addresses in the first place.

Any thoughts on this or Crell's idea to use one-way encryption of IP addresses?

~ben

People Who Give a Damn :: http://pwgd.org/ :: Building the infrastructure of a network for everyone
Agaric Design Collective :: http://AgaricDesign.com/ :: Open Source Web Development

subscribing

I don't think a one-way encryption would stop the government in this case. The problem is there are only 2^32 IP addresses to go through, so even somebody with a below-average computer could calculate and compare all possible values within a few hours, especially if they're targeting a single user. Maybe there's somebody with more experience with encryption that has a good idea.

By the way, I'm able to calculate md5sums (not doing any comparisons or output) of a /8 subnet in about 3 minutes running on a celeron processor under a xen vm with a PHP script. Obviously those are not ideal conditions for cracking. It's just to point out the government wouldn't take long to map IP addresses to hashes.

What about using a semi-random fudge factor? e.g., sha1(floor(time() /3600) . $ip_address)? That would keep the hashed address changing every hour, which would only marginally impact the flood control.

The base problem is that if the site is tracking users (flood control), it has to do so in some unique way. If it's done in a unique way, it's potentially trackable. You'd have to completely disable flood control and a few other things if you wanted a completely anonymous site.

I created an IP anonymizer module -- http://drupal.org/project/ip_anon -- to scrub logged IP addresses on each cron run. The retention period is configurable per table so e.g. you can clear out session IPs immediately but leave IPs in the flood table for an hour.

Since the IPs are still recorded in the database at least temporarily, forensic methods might still be able to recover them from the hard disk. Ideally in Drupal 7 there could be an option to disable IP logging in the sessions, comments, accesslog and watchdog tables. In flood and poll_votes tables IPs are actually useful so I'm not so concerned.