Respondent anonymity and zero telemetry

Encryption only helps if the page around it doesn't give people away. So the respondent experience is kept deliberately bare.

#What respondents see

• A privacy tip. Poll pages suggest answering on a personal device over a personal network, such as a phone on cellular data or home Wi-Fi, and note that a VPN adds protection. It links to a short guide on writing feedback that can't be traced back to you.
• A zero-telemetry pledge. The page says, in plain words, that we collect no analytics, fingerprinting or tracking.
• A note about personal invites. When someone arrives by a personal link, the tip explains that their link was swapped for an anonymous ballot in their browser, which proves they were invited but can't show which answer is theirs.
• A note about return codes, on polls that allow replies: the code is created in the respondent's browser and is the only way to read a reply.

#What the page doesn't do

• No third-party scripts. Poll pages load no marketing, behavioural or advertising scripts.
• A strict script policy. Our pages send a Content-Security-Policy that lets the browser run only script files served from our own site, with no inline script. So even a mistake that injected a tracking tag couldn't run it.
• Nothing stored in the browser to recognise a respondent. The anonymity explainer and the privacy tip live in page state only. The one exception is a personal-invite ballot, which is saved on the device so someone can finish later; it holds the ballot, not their identity.

#What we do record

Being precise matters more than the pledge, so here's the full list for a poll submission:

• The encrypted answer, stored with the poll it belongs to and nothing else.
• A count of answers per day for the admin's dashboard chart.
• For access-code polls, that a code was used. For personal invites, that an invite's ballot was issued, and on which day.
• A rate-limit counter per network and poll, keyed by a hash of the IP address that rotates daily, and deleted once its window has passed. It slows ballot stuffing, records that a network submitted to a poll, never what it answered, and it isn't linked to the answer.

Data retention and metadata boundary covers how long each of these lasts.

#Minimum group size

When you design a poll, the Minimum group size (k-anonymity) setting records how small a group you're willing to report on. It's saved with the poll and in any results document you publish. Admins see nothing until the larger of three and this setting has answered, and respondents are told that number on the poll page before they answer. While the poll is open, admins first see results three answers after that, later answers arrive in random groups of three to five, and a few answers are always held in reserve until the poll closes, so no one's answer can be picked out. How batched release works.

#Where analytics do run

• Public marketing pages and the signup funnel use first-party analytics. Visitors can opt out on the Privacy page, and Global Privacy Control is honoured.
• The signed-in admin app records a few first-party product events about setup, such as which way you chose to add recipients. They go to our own database, carry no respondent data, and use no third-party analytics.
• Poll pages and reply pages record none of this.

The banner and pledge are user-visible signals. How you distribute links, and who can see who took part, still matter.

#Related

• Aggregate results and anti-inference controls
• Data retention and metadata boundary
• Batched release and the exit pool