How can I prevent users submitting a completely anonymous survey more than once?

How can I prevent users submitting a completely anonymous survey more than once. I mean if they have participated in the survey then how can I prevent them.

1) I know I can do so with the help of cookies but the user can clear of the cookies or use a different browser. Moreover another employee / user can use the same computer to submit the survey

2) I can log the IP address but in case of DHCP it is not possible. Moreover users from the same laptop will have two different IP address when they connect to LAN and when they go wireless

3) I can generate a random code say 10 character code and sent to the end user so that they will fill up the code at the start of the survey and then set the flag at the end of the submission

4) As the survey is completely anonymous it is not possible to retrieve any user information viz name, e-mail id, employee id, user id, etc. nor logging in using their intranet id and password. This is our company policy

I am more inclined to option 3, can you throw some light on how to send a unique identifier to all participants. I am using Lotus Notes as the Mail Client
Who is Participating?
Sjef BosmanConnect With a Mentor Groupware ConsultantCommented:
And there is the browser's URL history, so one can find the previous user's survey...

One can't make this airtight, I think, using no login at all. Better throw in a committee to study the code, and some independent observers or a solicitor (notary), but even then...

I'm still in favour of Option 5 (of course). I'd open up the database, show the code, so the specialists can verify that there are no sneaky things in it. Also, ALL documents should be visible so anyone can see that there are no names in the document. And session logging in log.nsf should be switched off ;-)

gnoonConnect With a Mentor Commented:
Think in real. A unity is a person not a computer. If you can identify person, you can achieve this mission.
You can invite an employee by mail. Attaches a ticket number (uniq number) in the mail. Employee must uses that ticket number to submit his survey. So, you can check for the 2nd submit.

To send mail to lotus notes mail, it's not difficult if you have a SMTP server in your company.
gnoonConnect With a Mentor Commented:
In real, an employee can have more than 1 employee id because he may be moved to another status (from experiment), or department. So, you may be not able to use employee id to generate the ticket number because the person will have 2 ticket numbers.

However, it's only one in theory. You may need to filter only active employee ids to generate ticket numbers.

At the end of this article "General Purpose Hash Function Algorithms" ( having source code of hash function in java.
Once you get ticket number, attachs it the URL of survey page. Then send this URL to employee.

For example

ticket number = 52gh13
survey URL = http://yoursite/survey.jsp
employee survey URL = http://yoursite/survey.jsp?tk=52gh13

Hope you can understand my point and able to imagine the next step, but it should starts at sending invitation mail to employee .. right?
Never miss a deadline with

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

SysExpertConnect With a Mentor Commented:
Option 3 is your best bet, but it is not really anonymous if you can track the Random Code, unless you delete if from the Doc.

Another option is to Store a hash of the User ID temporarily, and delete it after the Survey is done.

I hope this helps !

moorhouselondonConnect With a Mentor Commented:
One way would be to get them to type their name in, then calculate a Message Digest 5 or md5 hash for that name.  The advantage of md5 is that it is a "trapdoor" encoding.  There's no way to take an md5 hash and get back to the original string.  

However, and it's a really big however, it is very easy for someone who knows the passkey to type in someone's name to see whether it generates the md5 result seen in the survey results table.  You would need to validate each user anyway because what's to stop someone filling out two surveys, the first one using Donald Duck as their name.

There are libraries around for slotting md5 into your code.
moorhouselondonConnect With a Mentor Commented:
Sorry, got called away.

My reference to "passkey" is that you would probably want to add some kind of character sequence to the submitted names to make the output different to what one would expect e.g., 123Donald Duck where only the programmer knows that 123 is prepended to the string before running the encryption.  
marilyngConnect With a Mentor Commented:
I like the idea of sending the user a random "ticket" number along with a link to the survey database via email.  However, maybe the best way in Notes is to have the survey open to a splash page/form with a login for the Ticket number.  You save that ticket number in a separate form, and in a view so that all submits from the login page check the view before proceeding to the survey.  If the random ticket number has been used, then the survey doesn't open.

If the database is set for anonymous access, and the form is also set for anonymous access, then the form's $updatedBy field will only contain "Anonymous" and the value of 1.  The survey form's property also needs to be set to "anonymous" access, too.

Then the survey is truly anonymous, and you have a way to prevent users from submitting twice.  

I think if you use the random ticket code to submit the survey, then there is a way to link the user to the random code.
Sjef BosmanConnect With a Mentor Groupware ConsultantCommented:
Option 3 and "completely anonymous" are only compatible if the person who creates the codes throws them away after sending and cannot read the user's mail database.

In other words: it's impossible. There's always someone to trust, so why not trust the administrator. Depositor access to the database should work normally.

Option 5 I'd like to add: two databases and an agent. The user fills in a form of the first database, when transmitted the id-portion will stay in that db and the survey data will be moved to a survey database by means of the agent. The survey data will have to be removed completely from the original document. I think this is a better way to separate person and data.
Sjef BosmanConnect With a Mentor Groupware ConsultantCommented:
I forgot to mention that the user has to log in for Option 5, in order to identify himself.
marilyngConnect With a Mentor Commented:
I like the ideas.  However, if the user suspects that the form he or she is filling out contains their information, they might be less likely to complete the survey honestly, or at all.

I've done a few of these, and everytime the survey and the user stuff appeared on the same form, there was little I could do to assure the user that the submitted survey was separated from their login information.   Because it appears that the submitted form contains it.   It was the appearance, that is, it appeared that they could be linked to the survey, no matter what was done after the fact to separate the identifying information.

I think if the survey appears to be anonymous, then the user is more comfortable participating in it.

And you are right, "completely anonymous" is difficult, especially if you're trying to limit the use to one entry.
moorhouselondonConnect With a Mentor Commented:
This is the low-tech way to do it.  What's needed is the electronic analogy of this:-

To ensure a person fills out the survey once you need to dish out sealed envelopes containing unique numbers in them.  The envelopes are shuffled in front of each recipient ("here y'are, pick an envelope, any envelope"), and there are more envelopes than recipients, which means that the last recipient doesn't get handed the last envelope.  (This guarantees anonymity).

The recipient signs to say they have received an envelope.  The total number of envelopes, minus those unused is checked to ensure it tallies with the number of signatures received.  The recipient types in the number contained in the envelope - which is validated, they then complete the survey.  If the number they type in fails validation then they can't complete the survey.
qwaleteeConnect With a Mentor Commented:
So here's the rub. If you are honsest, they may still not trust you. But, if you make an effort to make them trust you, then you end up doing it in a way where you COULD, if you wanted, track responses back to the user (i.e., you are not honest).

So, it comes down to:
a) you must make them think it is reaosnably trustworthy, even if their trust is based on misconcpetion
b) you yourself must be scrupulously honestm since the only way to guarantee once-only submissions while allowing (a) is for you to correlate surveys to the user in some way, but then choose to ignore the correlation

Here's how to do this, if you wish. Have each survey include a "token," which can be a randomly generated number, a sequentially generated number, or a hash of the username (preferably hashed via @HashPassword to make it less traceable).

Create a document in script for each user. You only need three fields filled in: FORM, USER , and TOKEN.  You can guess what TOKEN is. You are NEVER going to let anyone view this in Notes, and you will NEVER display the USER field in any view or form.
Set the form to automatically open in edit mode.
Add a COMPUTED field to the form (not when composed, not for display).  Name it USER and have its value calculate to "" (null string).
Optional: Add another COMPUTED field to the form (not when composed, not for display).  Name it TOKEN and have its value calculate to "" (null string).
Create a view with a single hidden sorted column, which is the TOKEN value.
Create an agent that will send a memo to each user, with alink constructed as follows:

"http://" + serverName + "/" + dbName + "/" + viewname + "/" + TOKEN

Now, if a user tries to put in a URL without the token on the end, the user will get the view which actually displays nothing. If an invalid token is put in, you get an error form the server (entry not found in index). If a validd token is put in, it finds THE MATCHING DOCUMENT, so the user can';t submit two different documents, only updates to this document. In additiion, if you put in the "option" I described above, then as soon as the survey is saved, that token code becomes invalid, so the user can't even go back in to the same survey document again. Also, when the user saves the surveym the user name is wiped out, so even if someone gets to the database, the only thing they can tell is which users have unfilled-out surveys pending (and by process of elimination, the names of those who responded, though no regular way to see which submission is theirs, unless they are the only survey on record).

Note: Someone could theoretically guess the UNIDs of the doucments, and get hold of someone else's unfilled out survey that way. In older versions of Notes, the NOTEID coudl be used the same way. It may also be able to hack in a replication conflict, allowing the same document to be submitted twice, though you shoudl be able to normally weed out the conflict documents.

A user coudl also use $First as the token, and walways get to the first document.  Yoru way around that is to have the view include both unfilled out surveys AND another special "error" form. Have the sort bring the error form to the top of the view.  That way, $First points to an error document instead of a survey document.

Your ACL should allow Anonymous=Editor to make this work, but Default=No Access. Seems backward, but it does what you want.
avanworldAuthor Commented:
It's a tough task to accept a solution. All answers are equally competitive. Anyway I have given points to all questions without any discrimination. Thanks for all of us
avanworldAuthor Commented:
sjef_bosman, I will implement your approach.

"In God we trust. All others require a digital certificate - Unknown"
>"In God we trust. All others require a digital certificate - Unknown"

I'd add the following important disclaimer:-

(So long as Microsoft <> God)


ty for the points
All Courses

From novice to tech pro — start learning today.