Privacy: what is public, what is encrypted, what cannot be deleted

One page for whoever has to decide whether Logbook may be used: a data protection officer, a secretary, the admin of a group. It describes Logbook as it works today, a beta on Sui Testnet. "Anyone" means anyone on the internet, without an account.

The short answer: Logbook is suitable for votes and surveys whose participation and results are not confidential. It has no anonymous mode. One kind of campaign for the members of groups, the secret ballot, records a ballot that Logbook’s relayer sends without the member’s address, within the limits its page lists, and is a beta on a test network that is not for binding decisions. Membership of a group is public, and nothing recorded on the blockchain can be erased.

#Why Not a Database?

A database is simpler, and you can delete from it. Use one if you trust its operator. Logbook exists for the votes where somebody will not: where the body running the vote, or its software supplier, could be suspected of changing the roll or the count.

• What the blockchain adds. Once a campaign has its first response, nobody can change its questions. Nobody can add, alter or remove a response, or reopen a campaign that has ended. For a campaign of a group, who may respond is fixed at the moment it is created. That holds for the organiser and for Logbook's servers. Public answers can be recounted by anyone without asking either; encrypted answers by the people the campaign names as readers
• What it costs. The record cannot be deleted either. That is acceptable only for data that is not about a person, and today the record is about a person: see below
• Two limits of the promise. Logbook holds the key that can upgrade the contract (see What Logbook Can Do). And the beta runs on Sui Testnet, which its operators reset from time to time: nothing here is kept for good yet

#What Is Public

Each participant acts under one address outside communities, and under an address of its own in each community (a group and the groups inside it), which this site derives for the account. Inside a community one address serves all its groups and campaigns. Logbook’s servers could connect the addresses of one account with each other: they pay for their transactions and serve the account’s encrypted list of them. What remains true of these addresses: a Google account on a device that never opened its addresses before cannot always check that the record of them which Logbook’s store serves was made by the account, and then takes it as served. The page says so in a notice, on each page load until it is answered: “This device could not check that the stored record of your addresses was made by you. It has never opened them before, and with a Google account the signature made when they were created can no longer be checked. That means: whoever runs Logbook’s store could have given your account addresses they also hold the keys of, and could then act as you in your communities. Before you rely on them, compare your address in a community (the account menu on its page) with the one shown on a device you have used before. Until then, do not register a ballot key and do not sign a roll from this device: Logbook will not let you.” Until the person has compared and said so, this site refuses, from that device, to register a ballot key, to sign a roll as returning officer and to create a secret-ballot campaign, whoever its returning officer is; it does not refuse joining, a member card or a response under those addresses. A wallet user who signs one key-server session message for another site gives that site every one of their community addresses, for good; a key left in a browser by somebody who closed the page without signing out stays there until anybody signs in on that browser, or 30 days pass, and the keys derived from it can be read by scripts of the page, which is why this site loads none from anywhere else; and Logbook’s server sees when an account’s list is read or written, and its database keeps history for days. For a Google sign-in it is computed from the Google account. It is a pseudonym, not a name, and not a secret.

Public, timestamped and, by design, never deleted under the address that did it:

• Every campaign it responded to, and when, also when the answers are encrypted. For a campaign with public answers, the answers too
• Not responding. For an open campaign of a group, anyone can list who could respond and has not
• Every group it joined, left or applied to, also groups whose name is hidden, and also applications that were rejected or withdrawn. With each membership: when it began and ended, how the person came in (which invitation link, so also who else came through the same link), and which admin ended it
• Roles: who created, owns and administers what; who was appointed and has not accepted
• Seats: which address holds which seat of a list, under a code for the seat
• Email checks, where a community uses them: a keyed code of the mailbox next to the address, the day the check ends, and each renewal, which shows that the person signed in with Google that day
• Address lists of campaigns, with every address added or removed later
• That an address has a member card, when it was written and how long each part is
• Whether Logbook paid the gas, which marks a Google account or a connected app
• The size and the time of every write

A private group hides its name, its description and what its members wrote. It does not hide who its members are.

#What Is Encrypted, and Who Reads It

Answers. A campaign has one of five settings. In every one of them somebody reads each address's answers: No answer setting is a secret ballot. "After the end date" hides the interim result. It does not hide how anyone voted: after the end it is a roll-call vote. All answers of one response are stored together, so a person's answers to different questions are linked to each other too.

One kind of campaign is different: a secret ballot, for the members of groups. Your ballot is recorded without your address when the relayer sends it, which is what this page does. The record of such a ballot on the blockchain does not say which member cast it: an admin of your group, the returning officer and somebody who reads the blockchain cannot read that from it. (A ballot you send yourself, from the file this page offers when the relayer does not take yours in time, is recorded beside the address that sent it.) Your answers are sealed for the key servers this vote names, which are to release the key only after the vote ends.

What it does not hide, and what it does not protect against:

• It does not stop you from showing somebody how you voted, or somebody from watching you vote. If you could be pressed to prove your vote, this is not protection against that.
• In a small group the result can show how people voted: a unanimous result shows everybody’s vote.
• Whether you voted is not written down, but it can show. The number of ballots is public as it grows, batch by batch: in a small group, or at a quiet hour, one more ballot next to who was online points to a person. The relayer sends ballots at fixed times, every half hour, and a question group leaves only when at least five ballots of that same group are waiting (five on this site’s relayer; an operator can set another number); it never puts two question groups into one transaction, and until a vote’s last half hour it sends one group of a vote a minute. So at a fixed time your ballot reaches the blockchain as one among at least five ballots of its question group, and four of those may belong to people acting together, who know their own and so know yours. In the last three minutes before the end the least number is one: where fewer than five people answer a group in a half hour, those ballots wait until then and leave however few they are, and a voter who is the only one of a group in that last stretch leaves alone. After the end, when the ballots are opened, a batch whose ballots all say the same tells what each of its voters chose to whoever can tell who was in it: reckoned with each ballot as an independent draw, a batch of five is unanimous about one time in three on a question that splits 80 to 20 (6 times in 100 at 50 to 50, 59 in 100 at 90 to 10). Batching makes linking harder; it does not make it impossible. A ballot that waits for those last three minutes may not be recorded: a transaction sent then can fail, and nothing extends a vote. Several ballots of yours for different groups can reach the blockchain minutes apart or, when few people vote, together in the last three minutes before the end, each among the ballots of its own group.
• Logbook could work out how you, by name, voted. One service receives your ballot from your network address, pays for your other actions in the community from that same address, serves your encrypted list of communities, and sees you sign in. So Logbook, or Cloudflare, which hosts it and carries every one of those requests, could put them together: this member, this ballot. After the vote ends the ballot is opened by whoever this vote lets open it (in a vote that opens for everyone: anyone), and then it is: this member, this vote. Logbook keeps no table that says so. It does keep, for two days, half of what such a table needs: daily counters of its sponsor, named by keyed hashes of your address in the community and of your network and written in one moment (what it stores is listed under Data Storage). The other half, which ballot came from which network, passes through its relayer and is not stored by it. What stands in the way is that, not mathematics. A second relay run by somebody else, which would prevent it, does not exist yet.
• Before the end your answers can be read by the key servers this vote names, if enough of them act together; whoever created the vote chose them, and a creator who runs them reads the count as it goes. You can also open your own ballot early and show it.
• Your passkey is kept by your device’s passkey provider (Apple, Google, a password manager), which may copy it to your other devices. Whoever can use your passkey can vote as you and work out which ballots are yours.
• A device with malware can read what the passkey derives. So can a changed copy of this page, and this page is served anew on every visit by Logbook and by Cloudflare, which hosts it: either could serve a changed one. So can a browser extension that reads this page. The operators of the Sui node and of the indexer this page asks see which vote your network address reads, and when; the page asks them for whole lists (every ballot of the vote, the whole roll, the whole part of the list of ballot keys that yours lies in), not for your ballot or your key alone.
• This page gives you no receipt when the relayer takes your ballot in time; when it does not, the page offers the ballot as a file, and that file is one. Your passkey is a receipt in every case: at any later time it can work out again which ballots are yours. Whoever makes you use it, or takes it over, learns how you voted in past votes of this kind.
• What you write can identify you: your style, a fact only you know. Nothing hides that.

> Beta, on a test network. It runs on Sui Testnet, a test network its operators may reset: a vote and its record can be lost. Ballots are sealed for key servers of the test network. Their operators promise neither to keep serving nor to keep their keys, so a vote may never open. Nobody outside Logbook has audited the contracts or this site. Tested: Chrome on a computer, with a test authenticator. Not tested yet: Safari, Firefox, iPhones, Android phones, and the passkey providers people use (iCloud Keychain, Google Password Manager, password managers). Do not use it for a decision that binds anybody.

What such a campaign adds to the public record: that an address of a community has a ballot key (its commitment, when it was set, how often it was replaced), the roll of every such campaign (the commitments, in order), and every ballot, beside the address that paid for it (the relayer’s, for a ballot the relayer sent). None of these can be erased: a ballot can be deleted from the blockchain's current state after its keeping, and copies of it remain. Two more things are kept with the secret-ballot mode and community addresses, in Cloudflare D1 databases. The vault: for each account, its seed for the addresses it has in communities, sealed for the key servers under that account, and its encrypted list of those communities; kept without a time limit, until the account moves it away: on the Account page it can be kept on the person’s own device with a file instead, and Logbook’s store then deletes its record and keeps a mark that it was moved (a fingerprint of the sealed seed), so that nobody makes another record in its place (what Cloudflare can restore of the database stays for up to 30 days). The relayer’s queue: each ballot handed to the relayer (the box, the part, the ballot’s number, the sealed answers, the proof), from the moment it arrives until it is recorded, at most until its vote ends. The row holds no network address. It holds the fixed time of the ballot’s batch, which is the start of a half hour, and whether the ballot came in the last half hour before the end of its vote: so the half hour in which a ballot arrived is in the row, and the moment within it is not. Per campaign and per day the relayer also keeps how many ballots it paid for and what they cost. Cloudflare can restore a D1 database to any minute of the last 30 days (7 on its free plan), so a deleted row, and the minute it first appeared, can be brought back by whoever has the Cloudflare account until that time has passed. The relayer writes no log line for a request. For two days it keeps a counter per network and day, under a name made from the network address with a secret that changes daily: what that network wasted (a ballot whose proof does not verify, a request that is not a well-formed ballot), in all and for each vote. A network that wasted nothing has no counter. What Cloudflare itself logs of each request (network address, path, time) is its own, as for every page. See Secret Ballot.

Encrypted data on a public blockchain is still public data. Anyone can copy the ciphertext, and it stays there. What protects it is the rule that decides who is given the key.

#Who Can Connect an Address to a Person

• Fellow members and admins of a group, through member cards: every current member reads the name next to the address. Admins also read the email, and where people join by a list, the admins' copy says which person each seat was meant for, while the blockchain says which address took it
• Mysten Labs, for a Google sign-in: its sign-in service (Enoki) computes the address from the Google account, at every sign-in. Google knows that the account uses Logbook
• Logbook, where the email check is switched on. Its check server sees the email address of the Google sign-in while it makes the check, for the address it confirms. It stores no email address and writes neither into a log line. For two days it keeps daily counters named by the address the check is for, by the IP address, and by keyed fingerprints of the Google account and of the mailbox. And the code it writes on the blockchain is made with a secret that Logbook holds, so Logbook could test whether a given email address is behind a given address. Google knows that the account signed in for the check
• Anyone the person tells, and anyone who can tie the address to them through something else it did

So for the people who matter most in a vote, colleagues and the organiser, an address usually has a name. Together with the table above: they can know who voted, who did not, and, if they are among the readers of the answers, how.

#Who Else Sees What

• The Seal key servers, which release decryption keys, see every request: which address asks for which key, when and from which IP address. That is who opens which campaign or group, and who reads whose card
• Mysten's public Sui node and indexer see which IP address asks about which addresses, campaigns and groups
• Cloudflare, which hosts logbook.zone, sees every request with its IP address
• Logbook's servers see the sender, the IP address and the content of every transaction whose gas Logbook pays, before it reaches the blockchain. For two days they keep daily counters named by a keyed hash, different every day, of the sender's address and of the network. The log line of a sponsored transaction holds a short code for its sender, not the address; an error line can hold what the chain or a library reported (see Data Storage)
• DeepSeek, an AI provider in China: when the creator of a campaign runs the AI analysis, the campaign's texts and the answers the creator can read are sent to it in plain text, written answers included, without addresses. The creator is shown this and confirms; participants are told before they respond that it can happen. What is typed to the AI assistant on the campaign form goes there as well
• An app connected through the remote MCP connector acts with a session key that Logbook's servers hold, encrypted, for at most 7 days, and private data it reads is decrypted on those servers

Data Storage has the full table. What the outside operators keep, and for how long, is their policy: we have not verified it and do not control it.

#What Logbook Can Do

Logbook's servers hold no decryption keys. But the rule that decides who is given a key is code of the contract, and Logbook holds the key that can upgrade the contract: one key, not a multisig, and without a delay. With it Logbook could publish a version whose rule gives every key to an address of its choice, and read everything that is encrypted: private campaigns and their answers, member cards, applications, lists. The upgrade would be a public transaction that anyone could see. It is not yet prevented.

"Encrypted, also for Logbook" is therefore true of Logbook's servers and not yet true of Logbook.

The encryption also rests on the key servers: whoever controls two of the three on Testnet reads what they protect. Who runs the three key servers this site uses: two are run by Mysten Labs, the company behind Sui, which also runs the full node this site reads and the service behind Google sign-in; the third is a committee of operators reached through an address of Mysten Labs. They are independent of Logbook, not of each other: any two of the three release a key, so Mysten Labs alone could read what they protect.

#What Cannot Be Deleted

"Removed" on a blockchain means removed from the current state. Earlier versions and the transactions that wrote them stay in its history, and nobody can make every copy of that history go away.

#What This Means Under Data Protection Law

We are not your lawyers; this is the position we would expect a regulator to take.

• An address that can be tied to a person is personal data. Here it can be, by design: cards, lists, the sign-in service
• Membership of a group can itself be special-category data: a union branch, a faith group, a health-related or political society
• An answer in a vote is an opinion of an identifiable person
• Encrypted personal data is still personal data
• The right to erasure cannot be honoured for a response, a membership or an application. European regulators have said that the technical impossibility of deleting from a blockchain does not excuse this (EDPB Guidelines 02/2025 on blockchain technologies)
• Some of the operators named above are outside the UK and the EU, and the validators of a public blockchain are anywhere
• A data protection impact assessment is needed in any case, and it is yours to make

#Our Advice Today

Suitable for votes and surveys whose participation and results are not confidential: a house council's decisions, a public poll, a club's choice of date, a record that has to be provable later.

Not suitable for:

• an election or a vote that must be secret
• a group whose membership is itself sensitive: union, faith, health, political
• a survey whose answers must not be traceable to the people who gave them
• anything where a participant's right to erasure must be honoured in full

A secret ballot exists as a beta on a test network, for the members of groups, with the limits its own page lists (Secret Ballot); it is not for any of the uses above. If another page of Logbook promises more for it than that page does, that page and this one are the ones to believe: write to hello@logbook.zone.