[Gnso-rpm-data] [Ext] RE: Advice Needed: Complications Regarding Saving Survey Responses

Fri Aug 17 17:00:59 UTC 2018

I think the proposal sounds like a reasonable way to move forward to give survey takers the ability to pause and return.

Michael R.

From: Gnso-rpm-data [mailto:gnso-rpm-data-bounces at icann.org] On Behalf Of Ariel Liang
Sent: Friday, August 17, 2018 6:42 AM
To: Dorrain, Kristine <dorraink at amazon.com>; gnso-rpm-data at icann.org
Subject: Re: [Gnso-rpm-data] [Ext] RE: Advice Needed: Complications Regarding Saving Survey Responses

Hello Kristine and all,

Please see below the responses from Analysis Group to Kristine’s question. Analysis Group has been making progress on the alternative options/workarounds, and will be able to provide another update shortly. We will keep the Sub Team posted.

Please let us know if you have any further comments/questions.

Best Regards,
Mary, Julie, Ariel & Berry

==

Kristine: If we do NOT use passwords, than anyone with the link can take the survey, right?
AG: That is correct. The survey will be publicly available, and anyone with the link will be able to take the survey.

Kristine: So if DO use passwords and we allow users to create them, what is the risk if they don’t create “unique” passwords?  Because I’m not seeing any risk to just letting them create a password. This is just a little placeholder -  a dog-earing of the electronic page if you will, it’s not performing a security function.  (Right??)
AG: If we allow users to create passwords, the survey will remain publicly available and anyone with the link will be able to take the survey. Users who create passwords will be able to save their responses and return to them later. The concern involved with non-unique passwords is that, because the password will be the only way for our programming to identify which survey record to re-open (i.e., users will not be creating unique user IDs and we will not be collecting IP address due to GDPR issues, so saved responses will be cataloged only by their password), if any users create the same password, their survey responses will appear in the survey data as if they came from one respondent when in fact there are two distinct respondents answering the questions. This can cause consistency issues, since we will be unaware of instances where this happens. For example, if a user chooses the password "1234" and completes questions 1-10 and leaves the survey, and then a second user attempts to create a password "1234" -- the second user will unwittingly log-in to the first user's survey and pick-up the survey at question 11. We will be unaware of this happening, but may find that the data appear inconsistent and/or invalid during our analysis of the data.

Kristine: Or are you saying that the password is really just a token and if someone else arbitrarily creates the same one (like “1234” or “password”) we’ll have a mess?
AG: Yes, as described above, we run the risk of overwriting or combining responses in a way that would cause responses to be impossible to untangle.

To continue to follow up with our progress on the passwords:
One solution that we would like to suggest is that users can be allowed to create a password, and we will embed a page visit counter next to the password field. We will suggest that users use the number from the counter for their password. This will guarantee that passwords will be unique for each user, although the pattern of the password generation may be a bit transparent.  We have identified a way to implement this solution but will need to be careful to make sure the directions for password creation (for first-time visitors) and log-in (for return visitors) are very clear. Unfortunately, the password creation and log-in fields appear as one field in the survey. We are unable to place them on separate pages (i.e., create a log-in page for first-time users and a separate log-in page for return users).

We are also investigating issues related to cookies, and expect to have resolved that issue and any related implementation issues by the end of this weekend if not sooner. We can send you another update tomorrow as we continue to make progress. There is a trade-off to consider regarding a portion of potential respondents who choose not to complete the survey if they learn that cookies are being sent to their computer.

From: "Dorrain, Kristine" <dorraink at amazon.com<mailto:dorraink at amazon.com>>
Date: Thursday, August 16, 2018 at 7:55 PM
To: Ariel Liang <ariel.liang at icann.org<mailto:ariel.liang at icann.org>>, "gnso-rpm-data at icann.org<mailto:gnso-rpm-data at icann.org>" <gnso-rpm-data at icann.org<mailto:gnso-rpm-data at icann.org>>, "Dorrain, Kristine" <dorraink at amazon.com<mailto:dorraink at amazon.com>>
Subject: [Ext] RE: [Gnso-rpm-data] Advice Needed: Complications Regarding Saving Survey Responses

Thanks for this Ariel:

My initial thought is this.

If we do NOT use passwords, than anyone with the link can take the survey, right?

So if DO use passwords and we allow users to create them, what is the risk if they don’t create “unique” passwords?  Because I’m not seeing any risk to just letting them create a password. This is just a little placeholder -  a dog-earing of the electronic page if you will, it’s not performing a security function.  (Right??)

Or are you saying that the password is really just a token and if someone else arbitrarily creates the same one (like “1234” or “password”) we’ll have a mess?

(ccing myself since I’m out tomorrow and I want to see the answer!)

Kristine

From: Gnso-rpm-data [mailto:gnso-rpm-data-bounces at icann.org] On Behalf Of Ariel Liang
Sent: Thursday, August 16, 2018 9:42 AM
To: gnso-rpm-data at icann.org<mailto:gnso-rpm-data at icann.org>
Subject: [Gnso-rpm-data] Advice Needed: Complications Regarding Saving Survey Responses

Dear Data Sub Team members,

Analysis Group is in process programming the surveys; the actual/potential registrant survey has already been pushed to the beta testing phase.

A complication was discovered. Analysis Group informed staff that it is not possible to allow survey takers to “save” their responses and return to the surveys later to complete, unless the survey taker is given a login credential that can be validated. To create a login credential, the simplest way is for Analysis Group to obtain a list of email addresses of the individual survey takers. This, however, cannot be achieved given the outreach method that we are using to distribute the surveys (e.g., public links accessed via mailing lists, announcements, social media). Although GDD has the email contacts of registries and registrars, ICANN Org is not allowed to share the email contacts with Analysis Group directly due to the rightful use of these email contacts and associated legal/GDPR implications.

Analysis Group is exploring other options/workarounds for survey takers to “save” their responses. One option is to allow users to create their own passwords, though it is difficult for Analysis Group to enforce unique password creation. They are experimenting with methods of suggesting unique passwords to users who would like to create a password. Another option is to distribute "cookies" with the survey, which will allow respondents to return to surveys that they have started. This option requires Analysis Group to explore any legal issues involved in the use of cookies. In summary, these options may raise technical and privacy issues that need to be cleared internally by Analysis Group. Consequently, this complication may add to the time for the surveys to be launched. Staff are seeking clarification from AG on the ETA to solve these technical/privacy issues.

QUESTION: The need to get the surveys out ASAP/as many responses as possible thus needs to be weighed against the benefit of enabling respondents to save their responses/impact to the response rate. What does the Sub Team advise?

Thank you for input!

Best Regards,
Mary, Julie, Ariel, Berry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-data/attachments/20180817/c7ccf389/attachment-0001.html>