| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 18253 | Bug reports | Survey participants (Tokens) | public | 2022-07-14 10:35 | 2022-08-27 14:58 |
| Reporter | Joffm | Assigned To | c_schmitz | ||
| Priority | none | Severity | minor | ||
| Status | feedback | Resolution | reopened | ||
| Product Version | 5.3.x | ||||
| Summary | 18253: In an anonymized survey you can access TOKEN:ATTRIBUTEs | ||||
| Description | I do not know if it is a feature or a bug. | ||||
| Steps To Reproduce | Steps to reproduceCreate a token-based survey with a participant and some additional attributes. Expected resultI should have thought that there is no possibility to access any information of the participants table in the survey. Actual resultNow you can set the survey to "anonymized" but circumvent it by entering some personal data in the attributes. | ||||
| Tags | No tags attached. | ||||
| Bug heat | 16 | ||||
| Complete LimeSurvey version number (& build) | 5.3.10. 220419 | ||||
| I will donate to the project if issue is resolved | No | ||||
| Browser | |||||
| Database type & version | 10.4.21-MariaDB, but not relevant | ||||
| Server OS (if known) | |||||
| Webserver software & version (if known) | |||||
| PHP Version | 7.4.24 | ||||
 |
LS shows this behaviour still in 5.3.20. |
 |
This is a very concerning behavior and no data from the token table should be possible to transfer to the survey if the survey is "anonymous", as then it is not. |
 |
Well, anonymous responses and token attributes are not opposites. Anonymous responses: your survey is set to anonymize responses - there will be no way to connect answers and participants. Still, you can access the token attributes while taking the survey. |
|
|
Please let me know what you think. |
|
|
"Still, you can access the token attributes while taking the survey." Then the survey is NOT anonymous. I can use some kind of ID (Name, Email, etc.), from the token table, save it into the answer table. So THERE IS a way to connect answers and participants. In this case, all the text about anonymity at the beginning is totally wrong and misleading. We can't claim that if we allow to pass or access any attribute from the token table to the survey or answer table. "Well, anonymous responses and token attributes are not opposites." For a anonymous mode within in Limesurvey, there can't be any possible connections between the token table and the answer table. In my opinion even the information of who completed the survey and who didn't should be able to be connected with the token table. I am really, really, really suprised by this answer and that this seems to be a feature rather than a bug. |
|
|
Well, that depends on how the survey is coded. I will leave the discussion to @c_schmitz |
|
|
Correct. But we can't show the standard paragraph for anonymous surveys, which comes from Limesurvey: "If you used an identifying code, please rest assured that this code will not be stored together with your responses". How can we claim this? Correct: We can't! Because the programmer can easily pass the token, etc. to the response table. "There is no way of matching identification access codes with survey responses" --> Also obviously not true. And you don't even need to hack the Limesurvey code. A simple {TOKEN} is sufficient. How can we call this an anoymous mode? correct: We can't. |
 |
With enough criminal energy, I see several other ways to disable anonymity. The text is for normal users who don't want to cheat their participants. In the end, whoever uses and maintains the software is responsible to keep their data protection promises ("With great power comes great responsibility"). |
|
|
In my opinion it is a huge difference if someone uses "enough criminal energy" to disable anonymity or if they use a simple built in feature that is documented and accessible to anyone with half a brain. I don't think we can use the statements in the anonymity text if we allow expression manager to access data from the token table. Then let's just take out the whole anonymous mode completely, because the way it is it doesn't serve any purpose and might lead to false expectations. Just because someone can break something with enough criminal energy, I don't think we should make false promises. I am quite surprised about this "laissez-faire" approach to data protection and anonymity. |
 |
The anonymous mode is working correctly. It's about the token that is not saved into the response set. The participants attributes can be needed for questions wording in an anonymous survey. It's not the first time this issue pops up. |
|
|
Thanks, jelo, totally agree. The description of this feature is 'Anonymized responses' and it exactly doing that in the way of a simple solution. The text ("If you used an identifying code, please rest assured that this code will not be stored together with your responses [..]") has no meaning in the way that a survey admin could show any text to the survey participant to promise anonymity. |
 |
While I understand the concerns brought up by @holch, I second the statements by @c_schmitz: The anonymous setting first of all means that we do not store the token with the responses. @jelo summed up the situation pretty well: There may be cases requiring some token attribute details within the survey. It is up to the survey admin how they deal with it. If they use this to break anonimity, it is the survey admin not playing fair and cheating on the participants, it is not a fualty software design. To give you another example: We have set up a 360° survey and have additional attributes to define the user roles like self, boss, employee. Depending on that, different email text snippets are used as well as different question texts. BTW, since even using real email addresses at anonymous surveys is raising concerns for some people, we have created a plugin that allows you to easily overwrite participant details at the token table, see https://survey-consulting.com/product/anonymizer-limesurvey-plugin-to-anonymize-limesurvey-surveys/ |
|
|
@Mazi: "But I need it" is not a good argument. ;-) For situations like this, you already have the normal mode. You can access anything in the token table there. Now an anonymous mode that allows to access all information in the token table and store it to the response table has nothing to do with anonymous. Oh, the token is not stored in the answer table by default? Great. But with a simple {TOKEN} you can still store it in the response table. So why having this fake anonymous mode anyway? Some of you argue that you have to trust the survey admin to not do that. So far so good. This is what I would call "ethical anonymity" and we practice this in market research for decades. I am fine with that. But we do not communicate to participants that we can't do it, we promise them that we won't do it. There is a small but important difference in that, don't you agree? Now imagine you are a normal survey respondent, you read the default text about anonymity. I am sure that you will read it as it is, "please rest assured that this code will not be stored with your responses". Now, I am learning from this bug report, we can't even remotely assure the respondents about this, because it is technically not possible at the moment. And I am not talking about someone with "criminal" energy hacking Limesurvey or finding a tricky and genius way around it. No, it is a normal Limesurvey feature called Expression Manager or Expression Script or whatever it is called today. A simple {TOKEN} or {TOKEN:NAME} or {TOKEN:ATTRIBUTE_x] written into a hidden question and all the promissed made in the standard text is gone. The survey owner might not even do it in bad faith to include the token into the response table with {TOKEN}, they just don't think about it. So at a minimum we should get rid of this standard text, and allow the survey admin to include their own text. If they then make false promissed, at least it is not falling back on Limesurvey. I have never really used the anonymous mode, because for most of what we do we NEED the connection to the token table. So this hit me by surprise (and I might have given even wrong advice in the forum, because it would never come to mind that the anonymous mode is so ridiculous :-) ). In any of our projects I would probably never say "rest assured that the code will not be stored/connected with your responses". What we do in market research is telling respondent that we won't analyse their responses in connection with their personal data, which is quite different. Respondents need to trust us that we won't, while when you read the standard text respondents will think we simply can't, even if we would want to. So I still do not agree with this not being an issue, especially together with the standard text that Limesurvey shows. Respondents will expect that there is no way (at least no built in way) to make a connection between their access code and their responses on a technical level, which is clearly not the case. So I still feel really uncomfortable with the way this "anonymous mode light" is presented to the respondents. To be honest, given the ease of getting around it with standard tools of Limesurvey, in my opinion this mode is useless as it is as is. People still need to trust the survey admin not to pass the token into the response table. Not much difference to the normal mode, where they need to trust to not analyse the results together with their personal data. I am surprised that even @Jelo thinks this is just fine. So I guess the majority doesn't see an issue with this and as this bug report was set to "resolved already, I guess there is no need to any further discussion. It doesn't affect me personally, as I would never use this mode in research practice anyway. But I find it dangerous to "sell" this "feature" as an "anonymous mode". Yet another reason to stay away from it. Anyway, a great weekend to everyone. |
|
|
@holch The access code is not saved in the response set. Qualtrics calls that function "anonymous link", which e.g. still saves IP-Address and location data by default. The info texts, which LimeSurvey is showing be default to explain modes should be removed. The survey creator/conductor should write the explanations to ensure that everybody understands the options. If you are forced to write an explanation, you need to understand the stuff. |
|
|
@jelo But in connection with the info text shown by default we create expectations that can't be met with the current "anonymous mode" in Limesurvey, which I see as an issue. Regarding Qualtrics "anonymous link": Can you pipe identifying information into the results table like you can in Limesurvey? |
|
|
@holch, I agree to "So at a minimum we should get rid of this standard text, and allow the survey admin to include their own text.". We are often asked how to adjust or remove this text which is not easily doable. You have to edit the template and/or translation file or add some JS to overwrite the details. @c_schmitz, that being said, what do you think about adding a setting to Implementing a) is rather straightforward, that could be a them option or survey setting. |
|
|
@holch Qualtrics offer functions "AnonymizingResponses" to remove data from the response set during the survey. |
 |
If we can use and save {TOKEN:TOKEN} in response data : we muts not call it anomnymous. Why not
Some real user really need Survey manager user can update survey content but can not access token part. |
 |
I agree with @DenisChenu: will need good explanation and wording of the concept.
|
|
|
Take one step back. To whom do you want to communicate that difference? If you want to communicate that to respondents, do you want to enforce a infobox in the survey? A infobox which cannot be removed via themes? The software cannot ensure anonymity. Many times respondents breaks it (e.g. enter personal data in text fields of surveys). What LimeSurvey is missing, are variables, which are not saved/removed in the response set, after hitting submit. For the topic of this bugticket a setting "Remove participants token/panel information and IP address from responses" would be a start. |
