Count Love

Protests for a kinder world.

Why and How We Count Anonymously

In our deliberations about how the Count Love app should work, we've given much thought to the role of protests and the act of being counted as forms of political speech. We want to let individual participants declare their presence and preserve that declaration as historical record. Yet, we are not naive to the reality that the act of making one's self known at a protest comes with neither a guarantee of privacy nor safety.

With the goal to record political dissent while respecting individual privacy, we designed a technical solution to privately count individuals by limiting our ability to answer the question, “Have we seen this individual before?” We store enough information to be able to claim with certainty that we have never counted a protestor before. However, we do not store enough information to link any individual with a particular submission record. This key feature allows us to know when we should count a new submission while also preventing us from placing a specific person at a demonstration.

The puppy matching conundrum
As a simple example, consider the following puppy matching game. You are allowed to adopt one Labrador puppy, but you are blindfolded and cannot see any of them (truly, this is not more ridiculous than any other contemporary “matching” reality show). You are allowed to pet the puppies as many times as you want, and someone will tell you the color of the puppy that you've just pet. The first puppy that you pet is a black Labrador (seems to like to lick hands). The second puppy that you pet is a yellow Labrador (very soft, but a bit aloof). The third puppy that you pet is a black Labrador—but is this the same as the first puppy? You only know for certain that you have pet at least two and at most three puppies. Asked if you've met one of the chocolate labs yet, you can answer “no” with complete certainty. However, asked if you've pet Logan the black Labrador yet, you can only answer, “I don't know.” This puppy counting conundrum illustrates how a Bloom filter works, and it is the key technology that allows us to count submissions anonymously.

In this blog post, we describe our Bloom filter implementation in detail along with other techniques that we use to encrypt and anonymize submissions. We share these technical details because we believe in privacy through peer review, mathematical uncertainty, and computational intractability. We welcome feedback and suggestions for improvement.

Details about our privacy technical implementation

Our software stack for counting submissions consists of an iOS app that transmits location and demonstration information and a server application that determines uniqueness and aggregates event details. We wrote the iOS client in Swift and the server application in PHP.

Constructing and transmitting the payload
When a user submits an event, the app prepares a payload using iOS's unique device ID, a serialized version of the phone's location, and an event description. Because the iOS device ID is unique, we never include it in its raw form. Instead, we combine the ID with the current date and then take the SHA-256 hash, producing an identifier specific to that phone on that day. We never transmit the payload unencrypted, and we never store the identifier hash on our servers. We believe these practices should make the task of obtaining and reversing a hash back to its original specific app ID quite difficult.

All communications between the iOS app and occur over HTTPS. To transmit its payload, the app makes an HTTPS post request using Apple's URLSession class. Our SSL certificate comes from Let's Encrypt, and to minimize the possibility of a man-in-the-middle attack, we've pinned the issuing certificate authority to prevent the app from communicating with other HTTPS endpoints. For more motivation on why everyone should pin their certificates, read this fascinating story about Gmail and certificate authorities.

Server-side Bloom filtering and data aggregation
When our server receives a submission, we extract the hashed device ID and pass it to the Bloom filter to determine submission uniqueness. You can learn more about Bloom filters here and here.

Our current Bloom filter implementation creates eight different hashes based off of the hashed device ID. We treat these hashes as extremely large numbers, take the modulus of these hashes and the size of the Bloom filter (which varies depending on the size of unique submissions that we want to be able to count), and then check for the existence of all eight remainders in our table of previously seen hashes. If at least one remainder is new, we know that it is a unique submission. If every remainder already exists in the table, we count the submission as a potential duplicate.

For a specific event, this gives us a range of counts. We know that the minimum number of attendees that we can count is the number of unique submissions, and the maximum number of attendees that we can count is the number of unique submissions plus the number of potential duplicates. After determining uniqueness, we discard the hashed ID, update the Bloom filter table with any new remainder values from the last set of modulus operations, and archive the location and event description data for aggregation.

Each night, we reset the Bloom filter by emptying the table and then inserting a few random values back into the table so that the first few submissions after a reset cannot be identified by their set of moduli.

Through the use of encryption, SSL pinning, hashing, and minimal data collection and storage, we've attempted to reduce the ways that someone could obtain an unencrypted payload and then use that payload to conclusively link a submission record to a particular person. These techniques allow us to record counts of individual protesters without jeopardizing their privacy. We welcome any feedback to help us further these safeguards.