How might we determine the appropriate moment to show the clickwrap agreement to organizers?
Early ideas/exploration
Idea 1: Show the clickwrap agreement when organizers are being given the right to be an organizer perhaps in preferences.
Pros:

• Organizers can optionally agree to handle PII responsibly before being granted organizer rights iof they want to
• Ensures all organizers see the clickwrap agreement before accessing any PII.
• Provides a central place for agreeing and revoking the agreement

Cons:

• We don't have an automated process for giving organizers right yet.

Example:

Idea 2: Show the clickwrap agreement when the organizer selects any of PII questions in the event creation process.
Pros:

• The agreement is shown only when the organizer chooses to collect PII, making it more contextually relevant.

Cons:

• Organizers may overlook the agreement if they are focused on selecting questions.
• Organisers may just be clicking around to explore the feature and having the agreement always appear might be distracting

Example

Idea 3: Show the clickwrap agreement when the organizer enables registration (only shows if questions are selected)
Pros:

• The agreement is shown only when the organizer chooses to collect PII, making it more contextually relevant.
• Agreement display is tied to a key action (enabling registration), increasing the likelihood that organizers will pay attention to it.

Cons:

• Showing the clickwrap after the organiser has selected questions means that if they don’t agree their effort selecting questions would have been in vain

Example

Idea 4: Show the clickwrap agreement below the PII section,
Pros:

• The agreement is shown where the organizer selects questions, making it more contextually relevant.
• Organizers can edit events and uncheck the agreement to revoke access

Cons:

• Organiser might not pay attention to it and proceed to enable registration
• Would require additional safeguards like an error message for when organisers try to enable registration without
• agreeing to the clickwrap.
• Add more text to the UI

Example

Idea 1 would be the best option but not feasible currently as mentioned above
Ideas 3 and 4 are the next best. Would explore more on them further.

Next steps

• How might other organizers(apart from the event creator) access the clickwrap and how might we limit access to PII to only those organizers who have agreed to the clickwrap agreement?
• How might we store and provide easy access to the clickwrap agreement for organizers in case they want to revoke their access to PII?

Some comments on the above:

Idea 1: Show the clickwrap agreement when organizers are being given the right to be an organizer perhaps in preferences.

I don't fully understand what "are being given the right" means here. At any rate, if we put this in Special:Preferences, we could make it visible only if the user is already an organizer. There might be a few details to hash out, but I would say that option 1 is overall doable.

One thing about options 2 and 3 is that there doesn't seem to be a way to revoke the agreement, as it's just a modal that's shown when access is required and you don't already have it. Also, since the modal uses JavaScript, we would need a no-JS version for it -- that would be a hard requirement, as anyone should be required to accept the agreement in order to see PII, regardless of the client they're using.

Option 4 gives the user a way to revoke their access, but I wonder how obvious it would be that they'd be revoking access for all their events, not just the one they are editing.

Another thing to note, related to the previous comment, is that option 1 and 2/3/4 are not mutually exclusive. There could be a checkbox in the registration form for enabling access, and another checkbox in the preferences for enabling or disabling access. This is similar to how IPInfo works. It would be more work to implement a checkbox in two places, but perhaps something to consider, maybe for a future iteration.

Idea 1 - organizers will see the click wrap only one time over their organizing tenure?

Ideas 2 through 4 - organizers will see the click wrap agreement every time they organize an event? Might that become redundant and lead to some sort of satiation overlooking in cases where someone organizes many events?

How are we ensuring that organizers read the agreements? that they are informed on the subject? vs. that they are simply clicking a box to quickly move forward?
Do organizers understand the consequences of not following the agreements? the potential impact?

I like option 1 and four 4, and maybe another idea could be a combination of both, like:

• Show the clickwrap agreement below the PII section, with some text (Like: to enable PII questions on your event, please go to your preferences and accept the PII agreement) and a button that would open a new tab to lead them to the user preferences where they can click to agree, like option 1, this would be shown only if the organizer has not accepted the PII agreement yet or revoked the agreement, and in case the organizer wants to uncheck the agreement they can to do it on their preferences.

cc @ldelench_wmf;
@Iflorez let me know if this answers your questions

As presented in the Design Engineering meeting. The best option is a modified version of idea 4, this solves the cons of idea 4.
Idea 4.1: Clickwrap agreement shows above the questions, the questions are disabled by default if the clickwrap is selected the questions becomes enabled
Pros:

• The agreement is shown where the organizer selects questions, making it more contextually relevant.
• Ensures organiser pays attention to it because it controls the other questions.
• No need for an additional error message since you cannot select questions without agreeing

In addition the clickwrap agreement should be per event and irrevocable after enabling registration
Why:

• Organisers decide to use or not to use PII based on per event basis so an agreement based on PII usage should be on per event basis. The other alternative to this is to tie the agreement to become an organizer and make it compulsory and irrevocable.
• It reduces misuse of data.
• What happens if i revoke the global agreement after organizing 10 events, am I no longer to be held responsible for the use of the PII of those events?
• If I am organizing 1 event and I revoke the agreement during that event, does it mean I am no longer to be held responsible for the use of the PII of the event, I could have copied/exported/screenshot all the data and then revoke my agreement.
• Additional organisers added don’t need to look for where to revoke the agreement and we don’t need to add another UI element on the event dashboard to opt out of the agreement.

If organisers come back to edit the event info after enabling registration, they can change the PII questions but not their agreement:

Other organisers who have been added can see a request on the UI to accept the agreement before seeing PII:

NB: These are not the final designs, these are just to show the idea.

Next steps:

• Reach out to legal to find out if we can make the agreement irrevocable
• Find out the exact language and copy for the agreement.

@ldelench_wmf - sharing my trust and safety inputs below :)

1. I like the idea of this clickwrap agreement for the MVP as we explore ways to seamlessly integrate the ANPDP for future versions! I read through the thread to see @gonyeahialam's suggestions. I like the modified version of idea 4 where organizers will have to check the box before selecting questions.
   • I'd also recommend adding on a pop-up message that highlights the need and importance to keep PII safe when they click on "enable registration" or "save changes" like in idea 3.
   • For future versions, i think we can also make it part of the process for getting "organizer user rights" while still maintaining the clickwrap agreement for when they're creating the form. i know that for now (for the MVP), we have a pre-approved vetted list of organizers, is that still correct?
2. I also agree that the "agreement" should be irrevocable to avoid the messiness of them revoking when they've been somewhat exposed to the data.
   • For additional organizers, will they also have the same organizer rights as the event creator? if that's the case i'm guessing they would've already been added to the beta testers group before they can access data? if that's not the case (at least for the MVP), Trust and Safety can vet additional organizers before they're added in addition to having the clickwrap agreement before they access data.
   • do we currently have a limit to the number of additional organizers every event should have? if we don't, it will be a good idea to have that, to minimize data exposure
3. The main safety concern i have here is how to/or being able to hold organizers accountable for data misuse (i.e using participant PII to harass online/offline, dox etc. ) for the MVP since we don't have organizer permissions yet (correct me if i'm wrong on this). I have a few open questions;
   • Are we currently able to track which organizer created what event and for how long? especially after the event has ended/ the event page no longer exists? This data will be useful if there has to be an investigation on data abuse
   • Are we able to revoke an organizer's access to data after the agreement has been breached or there's been a report of data misuse/abuse? before, during or after the event. I know these PII questions are optional and participants are also empowered to edit their information until the retention period but i think we also need to have a way to revoke access if needed. other actions we can explore in addition to this are warnings or removing organizers from the betatesters group (and we can explore building a temporary workflow for this). Currently for advanced right holders who sign NDAs, i know breaches are reported to the ombuds committee who investigate and share their conclusion with Legal and T&S. Thus for these organizers who will have access to PII, there has to be some measures in place, and legal may have more insights on this too
   • Similarly, we need to empower participants to know how to escalate or report data misuse. do we currently have a privacy statement that is included in the participant UI? maybe we can include an email address as a way to report? it could also be a popup message when participants start answering questions like in idea #3. I'm also concerned that this could be misused but i'll let Legal share their insights as well. Also acknowledging that this might not be feasible for the MVP but just wanted to flag and also we don't have to make it a hard requirement for now
4. Finally, re: @Iflorez's question on how do we make sure organizers read the agreement, i'm not sure if it's feasible at this stage but i've seen examples where you can only "agree" after you've read (or at least scrolled through) the T&Cs. that's a way to at least encourage reading

Thanks for your guidance here, @AJones ! To answer your questions:

i know that for now (for the MVP), we have a pre-approved vetted list of organizers, is that still correct?

Correct, our current workflow is 1) prospective organizers add themselves to this list; 2) Campaigns team periodically pings @Urbanecm_WMF to review/add to the organizer user group, which provisions access to organizer features on meta-wiki.
After consulting with the Stewards, we will eventually replace this process to: prospective organizers request to be added to the organizer user group on https://meta.wikimedia.org/wiki/Meta:Requests_for_help_from_a_sysop_or_bureaucrat (they have confirmed that this is OK as long as the volume of requests stays reasonably low).

For additional organizers, will they also have the same organizer rights as the event creator? if that's the case i'm guessing they would've already been added to the beta testers group before they can access data?

Correct! Organizer A cannot add organizer B to an event unless organizer B has been added to the organizer user group (if they try to, they receive an error).

do we currently have a limit to the number of additional organizers every event should have?

Yes, a given event allows a maximum of 10 organizers.

Are we currently able to track which organizer created what event and for how long?

I believe so; @Iflorez has built this into our initial dashboards - let me know if this is sufficient.

Are we able to revoke an organizer's access to data after the agreement has been breached or there's been a report of data misuse/abuse?

I think this would happen by removing the user from the organizer user group, which would mean they no longer have access to any registration/participant data. Is that how we're approaching this, @cmelo?

do we currently have a privacy statement that is included in the participant UI? maybe we can include an email address as a way to report?

Yes, here is what it looks like currently:

Perhaps we could include a note in the participant registration modal along the lines of "to report concerns or misuse of data, please contact privacy@wikimedia.org"? Or is there less intimidating language we could use?
cc @gonyeahialam

Side note: I've moved this task to "blocked" while this is in review with Legal, Trust & Safety, Security.

Hey @ldelench_wmf, the Security team's review is complete. You'll find below our feedback:

• Clickwarp’s language and format: The language sounds adequate, although I defer to Legal’s judgment. The user flow #4 explored has lots of benefits. It provides a good balance between informating organizers of the sensitivity of the data processed and making sure the call to action is not overlooked. No concerns.
• Auditing capability to find what organizers had access to what: This was raised by Trust & Safety and was also a point of concern for the Security team during previous review iterations. For the MVP, the initial dashboard provides a good point of reference to investigate or respond to potential privacy violation incidents. No concerns.
• Clickwrap agreement being per-event and irrevocable: I agree that it’s a necessity. Organizers consenting to handle PII for specific events means auditing can be performed at a more granular level (see point above). As for consent being irrevocable, while I concur that it’s needed, I recommend that we (a) clarify this point to the organizers — perhaps in the privacy statement, and (b) point them to the process for requesting a withdrawal of their access if they no longer need it. If that process isn't in place yet, that can be implemented later.
• Storage of consent provided by event organizers: a challenge with consent management is the need to store consent indefinitely for various reasons such as enabling audit, demonstrating compliance. With this requirement comes the risk of storing identifying information and exposing it to privacy violations for a long period of time. Accordingly, I recommend that (a) whatever the DB table schema used, it be kept out of the usual data replication flow — wiki replicas, Wikimedia Dumps and (b) that the table do not contain any identifying information, other than the obvious organizer ID.
• Access control of personal information in dashboard: As mentioned in April’s review, the more the PII viewers, the larger the pool of potential abusers. Accordingly, I am echoing’ T&S recommendation to limit the number of additional organizers each event can have. Based on my experience, I would recommend a maximum of 3-5. Is there any rationale behind the choice of 10?

A lot of good feedback has already been voiced, so I'll try and keep mine to what has not already been said.

I think with the current mitigation measures in the MVP around the de-identification/aggregation of potentially sensitive answers, optional nature of answers, access controls, etc. we are in distinct territory from the traditional access agreement (ANPDP) and from the similarly lengthy access agreement linked to from the IP Info tool (shown as an example above).

Even so, I still think having a simple agreement here is helpful to emphasize for organizers their responsibility in collecting this additional information. This clickwrap should also help future-proof the tool for when additional questions are eventually added (or if the tool's functionality changes). In the future, we may also want to consider access terms specifically designed for event organizers to agree to rather than the more general information in the site Terms of Use. Having the clickwrap functionality in place now would make that change a smaller change in text rather than needing this clickwrap functionality added later on.

Notes on text of clickwrap

From the text shown in the modified version 4, I would recommend not making a general claim that PII is only shown if the agreement is made. Usernames will be shown to event organizers whether or not they make this agreement, and usernames can also present PII. It also seems that none of the additional questions can be asked without agreeing first, even though the additional questions contain a mix of those flagged as PII and those that are not. Accordingly, I think it might be more accurate to focus the text not on "PII" but instead on participant information beyond usernames. Example language below to illustrate.

1. Event creator:

To collect participant information beyond usernames, you must accept the following:

• I agree to handle the participant information collected during event registration with care and in accordance with the Terms of Use.

2. Additional organizers:

To view participant information beyond usernames, you must accept the following:

• I agree to handle the participant information collected during event registration with care and in accordance with the Terms of Use.

If "beyond usernames" doesn't seem clear enough, happy to work out some more iterations with y'all to convey the message.

As another note: from the mockups, I liked that the "you must agree" info was shown to the additional organizers before their "I agree" language. In the initial mockup for event creator, that was instead shown as a parenthetical after the agreement text, which seems less clear. Perhaps there is a technical limitation at play, but if you are able to break up the introductory information then it could be clearer to move the prompt about choosing questions to be below the prompt about agreeing. For example:

• To collect participant information beyond usernames, you must accept the following: [agree checkbox]
• Choose questions for participants to answer... [ rest of that text]: [question option checkboxes]

Per my earlier comment, I still recommend against saying "to view participant personal identifiable information" (reasons copied and pasted below)

...I would recommend not making a general claim that PII is only shown if the agreement is made. Usernames will be shown to event organizers whether or not they make this agreement, and usernames can also present PII. It also seems that none of the additional questions can be asked without agreeing first, even though the additional questions contain a mix of those flagged as PII and those that are not. Accordingly, I think it might be more accurate to focus the text not on "PII" but instead on participant information beyond usernames.

And if "beyond usernames" doesn't seem clear enough, then I'm happy to work out some more iterations with y'all to convey the message.

In T334761#9002692, @MMoss_WMF wrote:

Per my earlier comment, I still recommend against saying "to view participant personal identifiable information" (reasons copied and pasted below)

...I would recommend not making a general claim that PII is only shown if the agreement is made. Usernames will be shown to event organizers whether or not they make this agreement, and usernames can also present PII. It also seems that none of the additional questions can be asked without agreeing first, even though the additional questions contain a mix of those flagged as PII and those that are not. Accordingly, I think it might be more accurate to focus the text not on "PII" but instead on participant information beyond usernames.

And if "beyond usernames" doesn't seem clear enough, then I'm happy to work out some more iterations with y'all to convey the message.

Hello @MMoss_WMF, for the MVP

• organizers will no longer be able to choose if they want to ask participants questions or not. By default, all participants would be shown the questions and it is optional for them to answer.
• The table with the list of participants and their responses will only include the non-PII questions' responses
• The only place participants' responses to PII questions will be shown is in the aggregated responses that become available at the end of the event

As a result of the above the agreement is only needed to view the aggregated responses. So the copy 'participant information beyond username' doesn't reflect this, since they can see every other information without accepting the clickwrap except the aggregate data. Hence the reason why PII was specified in the agreement copy. Also, the agreement is not compulsory since the organizer may not be interested in the aggregated responses.

Clickwrap appears when the event creator is enabling registration(Work in progress)	Clickwrap appears here for additional organizers or if the event creator didn't accept when enabling registration

If we do not mention PII in the copy, we can modify it thus:
To view the aggregated responses of participants you must accept the following:

• I agree to handle the participant information collected during event registration with care and in accordance with the Terms of Use.

What do you think?

Hello, @MMoss_WMF would like your feedback on the previous comment.

Latest design/copy

Clickwrap appears when the event creator is enabling registration	Clickwrap appears here for additional organizers or if the event creator didn't accept when enabling registration

Hi @gonyeahialam, apologies again for missing this. Since the responses will be aggregated, the responses should no longer be personally identifiable, so I still think it is best to avoid mentioning PII in the copy.

Your proposed copy that does not mention PII should work fine for this release. For later updates to the feature we may want to revisit this copy and link out to a policy more specific to the collection and use of information through this tool, rather than the general site TOU.

To view the aggregated responses of participants you must accept the following:

• I agree to handle the participant information collected during event registration with care and in accordance with the Terms of Use.

In T334761#9040031, @MMoss_WMF wrote:

Hi @gonyeahialam, apologies again for missing this. Since the responses will be aggregated, the responses should no longer be personally identifiable, so I still think it is best to avoid mentioning PII in the copy.

Your proposed copy that does not mention PII should work fine for this release. For later updates to the feature we may want to revisit this copy and link out to a policy more specific to the collection and use of information through this tool, rather than the general site TOU.

To view the aggregated responses of participants you must accept the following:

• I agree to handle the participant information collected during event registration with care and in accordance with the Terms of Use.

Thank you for the feedback @MMoss_WMF. Is it okay to specify "in accordance with Wikimedia Foundation's Terms of Use" rather than "in accordance with the Terms of Use" to make things clearer?

Thank you for the feedback @MMoss_WMF. Is it okay to specify "in accordance with Wikimedia Foundation's Terms of Use" rather than "in accordance with the Terms of Use" to make things clearer?

Update: From our Slack conversation, @MMoss_WMF has agreed to this.

Latest Design

Clickwrap appears when the event creator is enabling registration. Design specs	Clickwrap appears here for additional organizers or if the event creator didn't accept when enabling registration. Design specs

Current AC conflict with the non-PII data display requirements. If this is implemented as described, organisers can see the raw data prior to aggregation, but when the data is aggregated they will not be able to see it any longer unless they accept the clickwrap agreement.

Just adding some past updates from legal here for documentation purposes

“Organizers do not need to accept the clickwrap to see non-PII data. The click-wrap is to signal extra precaution around the PII questions (particularly age and gender), which is not needed for a question about comfort contributing to wiki projects.
The caveat to the above is that the ability to give free-text responses on the Wikimedia affiliates “non-PII” question may still end up collecting PII responses (given that it is free-text), so that’s where the PII/non-PII distinction falls a bit apart. I think in the future releases as more questions are added to the registration tool, the PII/non-PII distinction will likely make less and less sense, and you’ll eventually want to move more to a back-end categorizing around “risk of PII” — which on the front-end, rather than telling organizers which questions are PII or not, you’d more be telling them which will be reported in aggregate or not.
Right now, your current PII/non-PII scheme is fine and clickwrap just for those designated as PII responses is a good rule of thumb. Just know that there is lurking complexity and you might want to shift gears in the future when the PII/non-PII categories may shift more into a risk analysis than clearly defined categories.”

In T334761#9174328, @gonyeahialam wrote:

Just adding some past updates from legal here for documentation purposes

“Organizers do not need to accept the clickwrap to see non-PII data. The click-wrap is to signal extra precaution around the PII questions (particularly age and gender), which is not needed for a question about comfort contributing to wiki projects.
The caveat to the above is that the ability to give free-text responses on the Wikimedia affiliates “non-PII” question may still end up collecting PII responses (given that it is free-text), so that’s where the PII/non-PII distinction falls a bit apart. I think in the future releases as more questions are added to the registration tool, the PII/non-PII distinction will likely make less and less sense, and you’ll eventually want to move more to a back-end categorizing around “risk of PII” — which on the front-end, rather than telling organizers which questions are PII or not, you’d more be telling them which will be reported in aggregate or not.
Right now, your current PII/non-PII scheme is fine and clickwrap just for those designated as PII responses is a good rule of thumb. Just know that there is lurking complexity and you might want to shift gears in the future when the PII/non-PII categories may shift more into a risk analysis than clearly defined categories.”

Another past update: Legal has said we do not need to inform organizers that they are unable to revoke their acceptance of the clickwrap agreement.

@gonyeahialam Hello! It looks like this task is the same as T340115 at this point (in terms of the AC). I can close it, correct?

In T334761#9276848, @ifried wrote:

@gonyeahialam Hello! It looks like this task is the same as T340115 at this point (in terms of the AC). I can close it, correct?

This task is the parent task of other clickwrap tasks
The other task was created for engineering work, I think.