1118901 - Evaluate FFTF 'Call U.S. Congress' Tool for Net Neutrality Campaign

Status: RESOLVED WONTFIX

(Mozilla Foundation Communications :: Website, task)

Description

[Andrea Wood [:andreawood]]

Qs we need to answer: 

1. Can we implement a "Call Congress" tool as described below that protects PII and will pass security and legal review?
2. Is this call tool possible to implement by mid-February for Mozilla? Who will lead dev?

---
EMAIL BACKGROUND FROM HOLMES @ FFTF:
Hi everyone–
...

If you use our backend, building the frontend for it on your side is pretty straightforward. It’d also be pretty quick for someone on your side to set up a working call tool using the open source product, though that means you have to manage more small details, like the call targeting and the call script. It’s probably best for everyone to use the same backend.

–Holmes


–––

The TLDR for developers is: build a page that submits a form with the phone number and zip to our page (which we will provide soon, and let me know if this becomes a blocker), or set it up yourselves (much more work, but not hard).

Best practice is to show the call script/instructions and ask people to share the action on multiple social media accounts (with big sharing buttons) after they submit the form. The mockup below is an example (text not final).

Here’s more info from our developer.

I wanted to give you a quick run-through of how our call tool works. It's really simple, and should be straightforward for anyone with basic Python skills to get running.

There are two main components:

1. The frontend web site

This can be anything. It just has to be a web page that submits a form with the phone number and zip code to the backend component.

2. The server side component (Python)

The backend app is open source and available at https://github.com/fightforthefuture/call-congress

The readme does a good job of explaining how to get it set up, it's very simple. The only external dependency is Twilio API. Here's an outline of how the request lifecycle works:

    A request comes in from the frontend with a user's phone number, zip code, and the name of the campaign (eg. https://call-congress.fightforthefuture.org/create?campaignId=fcc-blanket&zipcode=55419&userPhone=6509065975 <-- put your phone number here;)

    The app reads the data/campaigns.yaml file for information about the call-fcc campaign (or whatever you passed in). This file contains rules for each campaign, and links to the audio files for the voice prompts, which can be hosted anywhere. This is all in a straightforward format, also documented in the readme

    Based on the campaign data, the app determines which phone numbers to call in the sequence and hands these off to Twilio API to initiate the phone call


    Twilio calls the visitor, reads them the prompts outlined in the campaign data and connects them to the recipient

Different rules in the campaigns file let you customize the call list. The default behavior is to call a person's members of Congress based on zip code, (each time the recipient hangs up or the user presses star it skips to the next call) but the campaigns can be customized in all sorts of crazy ways. Most of this is documented in the README: https://github.com/fightforthefuture/call-congress#campaign-configuration

The only real quirk is that zipcode is required, even for campaigns that aren't location based.

But other than that, it's pretty straightforward. And if you have any specific questions, I'm happy to help. Feel free to call me, 650-906-5975

Thanks,

Jeff

=====
Hey Andrea–

Great. I’m adding Jeff to discuss specifics about PII.

There’s also a dependence on a third party service for connecting calls, just to flag that now: Twilio.com, but it’s a very mature product and I’m sure the twilio folks can give your team the assurances it needs.

> -- Is there a way to build this so that we don't collect or store any PII, e.g. we ask people to call a # and input their zip to be connected?

We could do that, yes. It will convert worse I believe, but I think we could do it that way if it would make it much easier to get approval.

In practice they expose their number to us by calling unless they block caller ID, and then their zipcode too once they enter it, and that’s stored for the duration of the call anyway. Right now, we don’t have to store peoples info beyond the duration of the call, and I’m pretty sure we do not. So, it might not make much difference, unless there’s some strict sense in which it does within your policies.

> -- Most people don't know their zip+4 (just zip) -- are matches accurate even without zip+4?

I’m not sure if the call tool uses zip+4 right now. Jeff?

What I think we decided was that zip+4 would be optional but not required, and that users who don’t get connected to the right rep can enter zip+4 as a solution. We’ve noticed that many users who live on a border zipcode and frequently participate in campaigns will know to enter their zip+4. And most other users won’t notice or have a bad experience. 

What we’ve done in the past is give the user a single randomly chosen house member, if their zip matches multiple house members. For this campaign the Senate is the main target, so in all but a few weird literally edge cases (where zip's span states) zip will be good enough, I think.

Asking users for their street address makes the form much harder to use for mobile users, so I’m a big fan of getting as much mileage as possible out of just zipcode.

Comment 1

[Dave Steer]

Note on timing: should line up with the campaign launch on February 5th (not mid-February....if possible). If not possible, we can always add it in.

--Dave

Comment 2

[Andrea Wood [:andreawood]]

UPDATE FROM FFTF RE: PII:

I'm just catching up on this thread, so forgive any re-hashing, but I wanted to address the PII questions.

It's easy to set the app up so that users can call into our phone number and key in their zip code inside the call. From a PII perspective (at least from our perspective) this isn't functionally different than collecting phone number and zip through a web form, submitting to our server and using it to call the user's phone. Either way, our server is receiving the user's phone number and zip code at some point in the process, and we've found the web forms convert better.

(Note we can also "split the difference:" have a user fill out their number in a form, get called by our server, and then key in their zip code within the phone call)

We are using the Twilio API to connect the calls, and they do keep records of the metadata (including phone number) associated with each call. They are functionally a telephone switchboarding service, and any phone company will do the same regarding user phone calls.

Our server does not actively store user information. There are some passive logs on each incoming request, which will include the user's phone number, but these logs are transitory and are destroyed automatically after 10 days. These are helpful to monitor that the application is working properly, but they could be disabled if needed.

We will not store any personally identifiable information like phone numbers, zip codes, or IP addresses. We only need this information during the request lifecycle to connect the call.

Hopefully that helps with regard to PII. We set the call tool up from the beginning to be sensitive to data storage. Many of our users have fears of surveillance or retaliation, and there is no reason to store any data we don't need to run the app.

With respect to matching 5-digit zip codes to representatives: this is generally very reliable. It's not always 100% accurate for people who live on the borders of districts, but in practice there haven't been widespread problems.

Let me know if you have any other questions. I'm happy to set up a meeting if you want to discuss any details.

Comment 3

[Andrea Wood [:andreawood]]

Moved this issue to Github: https://github.com/MozillaFoundation/movement-building/issues/2

Closing this bug.