Hi,

I've recently started working with Limesurvey and I came across this "issue" that when I use anonymous surveys all the replacement fields in the token table gets sets to an empty string.

I would like to keep my surveys anonymous but would like to personalize the survey to the respondents. E.g. I would like to include the respondent's class name in certain questions. However this is not possible with the current implementation.

For what I could gather tokens are not saved so it would still be impossible to identify the user unless I include some very specific information in the respondent's answer, but that would be clear to the respondent as per the note on privacy when using anonymous surveys.

So my question is, is there any particular reason you chose to overwrite these values in em_manager_helper.php on line 3336-3343?

It's no problem to change this myself but would like your opinions on why this design was chosen.

cheers

/Jeppe

Yes, a reaaly GOOD reason, if we don't remove this value, then the survey CAN NOT be anonymous.

You can use this value with a specific number in a Équation question type.

If you want to use ths value in your surevy : your survey CAN NOT BE really anonymous. Then set it to non anonymous.

Denis

Thanks for your reply.

I am not sure I would totally agree with, so if you could please elaborate.

As I see it, it depends on how you use it but either way the respondent will be aware of which information is being submitted. The token or any other user information is not saved in the survey_dynamic table like when it is not anonymous.

If I included the token in an answer then yes it would not be anonymous. But a clause in the privacy statement already handles this issue by telling the respondent that the only way they could be identified would be if they submitted any information that could identify them like an email or token in this case.

The way we will be conducting surveys is across several hundred courses so it would be impractical to create the same survey for each course several times a year. So instead we are creating 1 survey for use on all courses. However we still need to know which course(s) the students attended to filter the responses. Because of that we would like to include some background data for each user (e.g. course name and course id), and the only feasible way to achieve this would be through the token table and then add that as an answer to a question in the survey. In my opinion this approach would be just as anonymous as if we created a single survey pr. course only difference is that the current implementation does not allow what I would like to do.

Other commercial solutions do allow this while still categorizing the survey as being completely anonymous. This was why I was wondering why you chose this implementation.

If one had a malicious intend there would be other easier choices to circumvent this in Limesurvey. My suggestion does still keep the survey transparent for the respondent even if one were to include user identifiable data in the survey, that is unless I'm not seeing something important.

/Jeppe

gaffu écrit: To cut a long story short: If you are able to show any personal information from the tokens table within a survey, then this survey can NEVER be anonymous.

Since anonymity is essential for lots of Limesurvey users, we will always try to keep the anonymity at a maximum, e.g. by not letting the admin reference any token field at an anonymous survey.
gaffu écrit: If you were able to access token data at anonymous surveys, you could for example set the user's email address as default answer of a hidden text question and voila, anonymity is gone.
gaffu écrit: Theoretically you are correct, but as said, if you could do that, this would break anonymity.
gaffu écrit: If you argue that there will always be a way to break anonymity, why not just set the survey to be non anonymous while telling the participants that all information is treated confidential?

Are you able to use the additional attribute information at the email templates?

I understand your point of view of trying to keep anonymity at a maximum though at the cost of flexibility.
Mazi écrit:
Yes if it is personal information unique to that person, though if the information is not unique like which course they attended and assuming more than 1 student attended the course, then it would still be anonymous, but I do agree that most information should be blanked out only leaving the additional fields left, at least that would limit it but not prevent people completely.

Anyways I'm just asking as I've been doing some modifications to limesurvey and could not completely figure out the implications if I were to modify that piece of code I mentioned.

(And yes I can use them in the email template).

Thanks for your responses.

gaffu écrit: In this case you can try to create your own invitation link at the email templates and pass the class information by URL into a hidden question.

Yes I suppose that could work, though I would still have to do some kind of check probably when the token is being validated to avoid users changing the value either on purpose or by mistake (e.g. copy/pasting the url from a text mail).

Thanks for your input.

/Jeppe

You can achieve some extended validation by passing two arguments and then at Limesurvey, check the two passed parameters and set conditions on all following questions to NOT show if a certain combination like "string1" + numberX or "string2" + numberY is found.
Additionally, you can show a text display question with a warning like "invalid parameters passed".

Yes that would work. Though it would require a bit more maintenance. I haven't really worked with conditions but will definitely have to look into it and perhaps add some extra functionality like md5 (if nothing similar exist) so the calculation could be done without any manual input. E.g. passing class and md5 with secret salt then do the calculation as part of a condition.

Cheers.

Sounds like a good idea. When you are done, please document your approach here so others can benefit from your findings, too: docs.limesurvey.org/Workarounds%3A+Surve...tions+for+LimeSurvey

Thanks!