VoteSafe, a voter-registration website, sends the email address and phone number a person types into its form to Twitter’s advertising system. The values are hashed, which is not the same as hidden. I tested it twice, with fabricated data, and captured the request both times.
VoteSafe is an online tool for registering to vote in the United States and for checking an existing registration. To use it you give it your name, your date of birth, your home address, your email address and your mobile number. That is the ordinary price of the service, and none of it is the problem.
The problem is where some of it goes.
I loaded the registration page in a real browser from a United States address, filled every field with data I made up, and recorded every network request the page sent. Then I searched those requests for the values I had entered, in plain text and in every common hash form: SHA-256, SHA-1 and MD5. A tracker that receives “your data, but hashed” still receives your data; the hash is just a fixed fingerprint of it. I ran the whole test twice to be sure it was not a fluke.
The name I used was Qzxwprobe Vbnmtester. The email was [email protected]. The phone was a fabricated number. Nothing here belongs to a real person.
When you move past the first screen of the form, VoteSafe fires a Twitter conversion event it labels register-submit. It is sent to analytics.twitter.com and t.co, and it carries two things: an email_address field and a phone_number field.
The email_address value in the request was 9cbb573fd9b9b398a2758fbb9c135fd09ae7a8a5992f2323ec1b3b0494e8b4c6. That is exactly the SHA-256 hash of the email I typed. The phone_number value was the SHA-256 hash of my phone number in international format. Both appeared in both test runs. This is Twitter’s standard advanced conversion matching, working as designed.
Hashing is not anonymisation. The same input always produces the same output, so one email becomes one specific string, every time, for everyone. Twitter already holds the plain email addresses and phone numbers of its own users. It can hash its own records once and match the fingerprints. A hashed email is not a shield; it is a join key. The point of sending it is precisely that the receiver can tie it back to a person.
What that buys the advertiser is the ability to recognise a voter registrant inside Twitter’s system, add them to audiences, target them, and measure whether an ad drove them to register. What it costs the registrant is that an act of civic participation becomes an advertising event, attached to their identity, with none of it visible on the page.
It is worth being exact about the limits, because the limits are part of the finding. The name, the date of birth and the home address were not seen leaving to any third party, in plain text or hashed. A Meta (Facebook) pixel and Google tags are present on the site and fire their own events, but in this test I did not see them carry the form fields; only Twitter received the email and phone. The ZIP code was sent in plain text to Sentry, an error-monitoring service, which is careless but minor. The one clean, repeatable, provable leak is the email and phone going to Twitter.
A person using a site called VoteSafe is doing the most basic thing a citizen does, and doing it because the site promises to make it safe and simple. They are not told that their contact details will be fingerprinted and handed to a social-media advertising platform the moment they proceed. Consent for that is neither asked nor given. Voter contact information is exactly the kind of data that should not be quietly wired into an advertising identity graph, and that is what is happening here.
The test used an automated real browser from a United States IP address, fabricated inputs, and full capture of outbound requests. Detection matched the entered values against SHA-256, SHA-1 and MD5 of each value and its normalised variants. The email hash and the phone hash both appeared in the Twitter requests on two separate runs. The captured requests are retained. If VoteSafe changes this behaviour, the change will be visible in the same way, and I will note it.
↓ Download the full evidence bundle (raw request captures, hash proof, reproduction method)
Tested 9 September 2026. Findings describe the site’s behaviour as observed on that date. The full request captures are available on request.