PIR distinguishes between those listed in NameBase, and those who use NameBase. This distinction is based on the conviction that individuals and groups who have some measure of political, social, or cultural power, automatically forfeit their privacy rights to the precise extent that their power influences the lives of others. This principle is not only philosophically sound, but it is also a legal principle. For example, U.S. libel law makes a distinction between a "public" person and a "private" person.
Names in NameBase are cited because the name appeared in a publication that was distributed to the public. In a few cases, we have included in-house rosters from intelligence-related or policy organizations, even when these were not generally available to the public. We consider governments and foreign policy -- regardless of which governments are involved -- to be of legitimate interest to the average world citizen. In our view a government agent, secret or not, has no more right to privacy than, for example, an agent of organized crime.
Those who use NameBase deserve privacy, even while those listed in NameBase do not. Sometimes a user is also listed. In such a case, we distinguish between the two roles that this person plays with respect to NameBase. To put it another way, we don't disclose who has been searching for what, even when that searcher happens to be listed in NameBase.
We keep access logs of searches for seven days, but we don't share them without a court order. These logs indicate the Internet domain that launched the search. Normally it is difficult to identify the person behind this domain. However, with the trend toward cable and DSL access, both of which use static IP numbers, this could be changing. In any case, we use our access logs only to detect abuse of our site, and to improve our search interface. Logs more than seven days old are deleted.
Obviously, users with passwords identify themselves by using their password. This is the equivalent of an "opt in" situation. In most cases, you can perform the same NameBase search without using your password. If your service provider is large enough (such as AOL), we would have no way of knowing who did the search. Similarly, the entire NameBase database can be downloaded, and searched off-line.
NameBase does not issue cookies to the typical visitor. One exception is if you use your password to specifically request a cookie, as an alternative to entering your password for every new NameBase session. The same password can be used to delete this cookie, or to check on your cookie status. This use of a cookie is identical to the "opt in" situation of entering a password, except that it performs the password log-in automatically and silently, with every search, in order to flag the search as "unrestricted." If you want some searches to be more anonymous than others, then you should not request a cookie, and you should use your password accordingly. The version of the password in your cookie has been one-way hashed for security. It expires when your password expires.
Our other use of a cookie is for the 20 percent of visitors who try out the proximity search with a browser that does not support Java. When this happens, we set a "nojava" cookie that has no unique information in it at all. This allows our program to anticipate the need for an alternative approach to the Social Network Diagram on the next search, and furnish the same diagram in the form of a GIF client-side image map. If you opt for a proximity search without a diagram, this "nojava" cookie changes to a "nodiag" cookie.
Proximity search cookies expire in one month if they were set by clicking on an option. If Java is not supported and no option is selected, the "nojava" cookie that is generated automatically is a session cookie that expires when the browser program exits.
Unlike Google, which sets a cookie that expires in 2038 for anyone who visits any page of theirs and doesn't already have a Google cookie, we feel that our use of cookies is careful and reasonable. Google uses a unique ID number in their cookie, and with this number they also log the Internet address number, date and time, search terms, and browser information. This is both unnecessary and scary.
In three places we use an invisible "counter" GIF on our pages. These are not "web bugs" because they come from the same domain (a web bug is defined as the use of this technique by a third party). The purpose of two of these "counter" CGI programs is to trigger the cartoon and box rotation on our home page and another page. The third one sets the automatic session cookie described in the previous section.
You may notice a slash and a unique number after these counter programs, or after using the cookie-setting programs in the proximity search. It looks like "...cgi/XXXXX," where XXXXX is a number that changes each time. This number is ignored by us. It happens to be our process ID number, but any changing number would work just as well. The only purpose in appending this number to the URL is to fool your browser into thinking that this file or GIF is new. If your browser thinks it already has the information in its cache, it won't request an update from us.
We also use some one-pixel invisible GIFs on our pages to hide a link that traps personal spiders. Professional spiders usually honor our request to stay out of our cgi-bin directory. But inconsiderate amateurs on broadband often set loose a personal spider, which if allowed to continue uncontrolled, could overload our server and deny access to others. Spiders that we detect in cgi-bin are locked out of our site.
There is also a per-day numerical limit on the number of files anyone can fetch from our site. We exempt only four spiders from this limit, because those four give us significant referrals. The number of worthless spiders has become problematic on websites such as ours. For every 100 fetches, we average 70 from spiders, and 30 from live users. Most of the 70 fetches from various spiders play no role in bringing the 30 users to our site. We generally delete the accumulated first-time "forbidden" blocks once per week.
Information submitted on PIR forms for registration purposes is considered private by PIR. We normally would not share your email address or other information with anyone. Occasionally we may refer a researcher to a resource person, if we think the resource person might be helpful, and would have no objections. This might happen only if we are familiar with your expertise in a particular area of research, and even then it's rare that opportunities for such referrals arise. If you prefer that we not do this in your case, you should indicate this in the comment line on the form.