Simple Survey Tool

[ssandino]

Currently we use the third-party tool Typeform for the recipients surveys. This setup has considerable drawbacks: costs ($800+ per year), data in US, flexibility, no multi-language, managing surveys for recipients (knowing who filled out what) and less privacy etc.

An option – which has been in discussion – is to create a standalone solution:

• based on a react app in a separate top-level folder in the repo (surveys/...)
• connected to the (new) tailwind components (for the moment we would use button and text field component)
• all answers saved directly in our Firebase DB in separate collection without any personal data (except UID, which does not allow for conclusions to real person), so it can be better analysed and used for real-time insights, similar to our financial transparency)
• make surveys accessible with a subdomain (surveys.socialincome.org/...)

What could be a good unique identifier for the surveys (also used in the URL to access it)? The most obvious option could be the randomly assigned document id, which is created by firebase for each user. This could also be helpful, if the state of the survey (i.e. submitted, started) should be written into the respective recipients document (and allowing this via firebase rules).

How would user XY with UID=S5bTLl2ZVeccOPJcJ788 access a survey:

surveys.socialincome.org/S5bTLl2ZVeccOPJcJ788/ -> overview of all surveys for XY
surveys.socialincome.org/S5bTLl2ZVeccOPJcJ788/onboarding -> onboarding survey for XY

Remember: Recipients don't have a login. So the UID should make sure that a) we know who filled it out, b) can connect the recurring survey answers to one user (measuring poverty level over time) and c) have a bit of security from someone randomly filling out or accessing surveys (i.e. when we use sequential numbering and it's easily guessable) and d) provide a way to manage recipients surveys.

Other information: each recipients gets approx. 8 surveys over the 3 years. In the best case, recipients get the survey in their main language (often not English), so multi-language should be thought into it (but it's different from the routing of the website, where we have to guess based on IP or browser language or cookie. We know who is accessing the survey (thanks to the UID) we could easily serve the right language based on the recipients main language field. As a start it could also be only English (as it is now, until the discussion here found its decision.

Any thoughts on this @andrashee @renestalder @sdwivedi @mkue?

[ssandino]

Some quick examples sketches (mobile first, as most recipients don't have an computer). This should give a better idea of how the survey tool could look like.

[andrashee]

An option – which has been in discussion – is to create a standalone solution:

• based on a react app in a separate top-level folder in the repo (surveys/...)

sgtm

• connected to the (new) tailwind components (for the moment we would use button and text field component)

sgtm

• all answers saved directly in our Firebase DB in separate collection without any personal data (except UID, which does not allow for conclusions to real person), so it can be better analysed and used for real-time insights, similar to our financial transparency)
• make surveys accessible with a subdomain (surveys.socialincome.org/...)

This sounds good to me. We then can have some functions to aggregate statistics into a publicly readable collection.

What could be a good unique identifier for the surveys (also used in the URL to access it)? The most obvious option could be the randomly assigned document id, which is created by firebase for each user. This could also be helpful, if the state of the survey (i.e. submitted, started) should be written into the respective recipients document (and allowing this via firebase rules).

How would user XY with UID=S5bTLl2ZVeccOPJcJ788 access a survey:

surveys.socialincome.org/S5bTLl2ZVeccOPJcJ788/ -> overview of all surveys for XY surveys.socialincome.org/S5bTLl2ZVeccOPJcJ788/onboarding -> onboarding survey for XY

Remember: Recipients don't have a login. So the UID should make sure that a) we know who filled it out, b) can connect the recurring survey answers to one user (measuring poverty level over time) and c) have a bit of security from someone randomly filling out or accessing surveys (i.e. when we use sequential numbering and it's easily guessable) and d) provide a way to manage recipients surveys.

Generally, UUIDs are not necessarily designed as a cryptographical random generator. They are designed to create unique ids, but are not per design unpredictable. https://research.nccgroup.com/2021/05/10/using-uuids-for-authorization-is-dangerous-even-if-theyre-cryptographically-random/

I think I would prefer if we generate for each recipient a secure token, add this to the recipient document as an attribute (e.g. survey_token), and then use that one instead of directly the UUID. We could then design the firestore rules that one can read/write a survey document with survey_token id, if there exists a recipient with the given survey_token.

Another approach would be to use proper jwt tokens using the auth module in firebase. https://firebase.google.com/docs/auth/admin/create-custom-tokens#create_custom_tokens_using_the_firebase_admin_sdk.
We can create the token when generating the survey links. The token contains the recipient's uuid. The react app can then call the auth endpoint firebase.auth().signInWithCustomToken(token). Once authenticated it can query the survey collection. In the request, the token is passed along and one can read the recipient's uuid in the security rules. I would go for this approach since jwt token authentication is a standard and widely used.

[ssandino]

The progress of the survey tool can now be viewed on this board view.