Prefilling a form with individual data securely

Support
, ,
1

1. What is the problem? Be very detailed.

Following scenario: We collect data from respondents using Central/Enketo. Later, we want to collect data again using a different form ("follow up survey"). In both forms, respondents fill in the form themselves. Also, both forms start with a "Respondent Access Code" text field that uniquely identifies the respondent.

Now in the second form, some fields should be prefilled from the previous submission. I am aware that this is possible with secondary instances, however, to my understanding, the data in secondary instances is technically public, as it's just an attachment to the form that all browser clients receive in the background. For data privacy and security reasons, we would like a respondent to technically only have access to his/her own individual previous data.

Is there already an way of doing something like this?

I am imaging, for example, being able to have dynamic external secondary instances that are downloaded from a custom URL, like https://example.com/data_xyz?respondent_access_code=<respondent_access_code>. But this is not possible, right?

2

Hi @vlehn, it might be possible to do something like this by launching an external app from Collect and then using the external app to populate multiple fields. But I think this would require a lot of custom software development. Nothing exists "out-of-the-box" to do this in Collect.

If your access codes are not too complex it would be easy to exploit a basic system like this. For example by scripting to test every possible combination...

https://example.com/data_xyz?respondent_access_code=001
https://example.com/data_xyz?respondent_access_code=002
https://example.com/data_xyz?respondent_access_code=003
and so on...
1 Like
3

Hello Dan,

thanks for your response!

The external app solution with Collect is very interesting and I was not aware of the approach. But this will then also not work with Enketo. A certain amount of custom development would be okay, but I can't see a real solution pathway yet...

I agree with the exploitability of simple access codes, they would indeed need to be complex enough.

Greetings,
Vitus