Consent: specific, revocable, and never a key to the ballot

In plain words

Consent means you said yes to one specific thing. Not yes to everything, and not yes forever.

In this framework, nothing you save is shared unless you choose to share it. Each kind of sharing has its own switch, and every switch starts off. Before you publish an opinion, you see exactly what will be shown. If you add your name, that is a separate choice.

You can take a permission back later. That stops future use. It cannot pull back a copy someone already downloaded, screenshotted, or forwarded, and an honest system says so before you share.

One thing is outside consent entirely: your ballot. No checkbox can make your vote public, because a vote that can be proven can be bought or demanded.

Defined terms

• Consent. In EU law, "any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her" ¹. This framework uses the same four qualities (free, specific, informed, unambiguous) as a design standard everywhere, without claiming that EU law applies to any particular operator. See the glossary.
• Purpose-specific permission. A permission that covers one named use, such as "publish this opinion snapshot," and nothing else.
• Withdrawal. Ending a permission. Withdrawal stops future use under that permission; it does not undo past lawful use or recall copies already in other hands.
• Consent record. A stored entry showing who granted or withdrew which permission, for what purpose and scope, under which wording version, and when.
• Snapshot. A fixed copy of exactly the fields a person approved for publication, as previewed. Later edits to the private answer do not silently change a published snapshot.
• Non-waivable right. A protection the holder cannot give away by agreement. General Comment 25 treats ballot secrecy this way ³.

Evidence

What the law in one major jurisdiction requires of consent

The EU General Data Protection Regulation sets out conditions that make the abstract idea concrete. The person processing data "shall be able to demonstrate that the data subject has consented" (Article 7(1)) ². When consent is part of a document that covers other matters, "the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language" (Article 7(2)) ². The data subject "shall have the right to withdraw his or her consent at any time," the withdrawal "shall not affect the lawfulness of processing based on consent before its withdrawal," and "it shall be as easy to withdraw as to give consent" (Article 7(3)) ². When judging whether consent is freely given, "utmost account shall be taken" of whether a service is made "conditional on consent to the processing of personal data that is not necessary" for it (Article 7(4)) ².

These provisions are EU law. They are cited here as a well-developed statement of what meaningful consent requires, not as a claim that this project is subject to or compliant with the GDPR. Rules differ by jurisdiction; see jurisdictions.

Consent cannot unlock the ballot

The UN Human Rights Committee, interpreting Article 25 of the International Covenant on Civil and Political Rights, says voters "should be protected from any form of coercion or compulsion to disclose how they intend to vote or how they voted," and that "waiver of these rights is incompatible with article 25 of the Covenant" ³. The Venice Commission's Code of Good Practice goes further for the voter personally: "secrecy of voting is not only a right but also a duty, non-compliance with which must be punishable by disqualification of any ballot paper whose content is disclosed" ⁴.

The reasoning is practical. If a voter could consent to disclosure, a coercer could demand that consent. Consent that can be demanded is not free. That is why the framework's consent system covers priorities and opinions only, and why there is no ballot share button. See intimidation.

Research: the limits of consent as a privacy tool

Legal scholarship has questioned how much individual consent can carry. Daniel J. Solove's 2013 Harvard Law Review article argues that "privacy self-management," the model of notice and consent, faces "severe cognitive problems." He adds that "there are too many entities collecting and using personal data" for people to manage each relationship, and that "many privacy harms are the result of an aggregation of pieces of data over a period of time by different entities" ⁵. The implication for design is that a consent screen cannot be the only protection. Defaults, minimal collection, and limits that hold regardless of what a person clicks have to do much of the work.

Wording changes answers, including answers to consent prompts

Survey methodologists at Pew Research Center report that "even small wording differences can substantially affect the answers people provide," and warn against "double-barreled questions" that ask about "more than one concept" at once ⁶. Pew's guidance concerns survey questions, not consent prompts, so applying it here is an inference. The inference is direct, though: a permission that bundles two purposes is a double-barreled question, and its answer cannot be read as agreement to either purpose alone. More on question design is in question design.

Competing interpretations

Consent as the core safeguard versus consent as a weak signal. One position treats informed consent as the foundation of legitimate data use: if people understand and agree, use is justified. The critique summarized above holds that consent is often uninformed, fatigued, or structurally impossible to manage ⁵. The framework takes both seriously: it asks for consent where people make a real choice (publishing a specific opinion), and it removes choices that should never be offered (selling data, disclosing ballots).

Granularity versus fatigue. Many narrow permissions give precision but can exhaust people, which pushes them to click through. Few broad permissions are easier but less meaningful. There is no settled answer. The framework limits the number of permissions by limiting what it does: no marketing bundle, no data sale, no research program until one actually exists.

Withdrawal as deletion versus withdrawal as stopping. Some people expect "withdraw" to mean "erase everywhere." The GDPR's own text says withdrawal does not affect earlier lawful processing ², and no operator controls copies already in other hands. The framework treats withdrawal as stopping future use and removing the operator's hosted copy where possible, and says plainly that it cannot recall the rest.

Application to this framework

These are design requirements for the demo and for any future system. They are not claims of legal compliance.

Supporting rules:

1. No prechecked boxes. Every permission begins off and is granted by a clear action.
2. Preview before publish. The person sees the exact snapshot, including the question, the endpoints, their position, the date, the question version, and a "Demo opinion, not a ballot" label where it applies.
3. Versioned records. Each consent record stores purpose, scope, wording version, timestamp, and action (grant or withdraw). If the wording changes, earlier consent is not silently stretched to cover the new wording.
4. Honest withdrawal. Revoking a share link removes the hosted copy where possible. The interface states before sharing that screenshots, downloads, and previews in other services may persist.
5. Labels are not access control. Calling a link "for family" does not make it private. Anyone with a public link can see it. Named-recipient sharing would require a real, reviewed access-control design, which the current demo does not have.
6. Nothing reaches the ballot. The consent system has no permission that touches ballot choices, and the demo stores none. See privacy and private voting.
7. Releases need their own basis. Any future published release of real respondent data would need its own documented consent basis and privacy review.

Unresolved questions

• How should consent work for people who rely on an assistant to use the interface, so that help with access does not become pressure? See the discussion of assistance in the secret ballot.
• What is the right interval, if any, for asking people to reconfirm a standing permission to publish priorities?
• How should consent records themselves be protected, given that a record of "published an opinion on proposal X" is itself sensitive?
• If a future research program is ever proposed, what independent review should approve its consent wording before anyone sees it?