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 secret ballot and no anonymous mode, 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 for the whole of Logbook: the same in every campaign and every group. 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 that address:
- 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 a 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
#What Is Encrypted, and Who Reads It
| What | Who reads it |
|---|---|
| The members part of a member card (usually the name and a title) | The card's owner, the owner and admins of the group, and every current member |
| The admins part of a member card (usually the email) | The card's owner, the owner and admins of the group |
| The text of an application, and the card sent with it | The applicant, the owner and admins of the group, while it waits |
| Name, description and card form of a private group | Its owner, its admins and its current members |
| The admins' copy of a list: the names of the seats, the expected holders, their emails | The owner and admins of the group. Logbook's servers store the ciphertext |
| Title, questions and documents of a campaign that is not open to anyone | Everyone who can open it: with the password, on the address list, or a member of its groups when it was created; and its creator |
| Answers | By the campaign's setting, below |
| Setting | Who reads every answer, next to the address that gave it |
|---|---|
| Everyone | Anyone, at once. The answers are plain text on the blockchain |
| Everyone with access | Everyone who can open the campaign |
| Voters only | The creator, and everyone who has responded |
| Only me | The creator |
| After the end date | Nobody but the respondent until the campaign ends, the creator included. From the end on: everyone who can open the campaign, for good. On a campaign open to anyone, that is anyone |
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 and logs neither. But 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
#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. They keep daily counters by address and by IP address for two days. Their logs name no address
- 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
#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.
#What Cannot Be Deleted
| Request | What can be done | What stays |
|---|---|---|
| Delete my response | Nothing | The response, with its time; the answers, public or encrypted |
| Delete my membership | Leave the group | The record of the membership with every date; the events of joining and leaving; every response given |
| Delete my application | Withdraw it while it waits | That the address applied, and whether it was rejected and by whom; the encrypted text |
| Delete my member card | Remove the card, or leave the group: nobody is given its keys any more | Every encrypted version in the history of the blockchain. Whoever read it may have kept a copy |
| Release my seat on a list, or my mailbox | The owner of the community releases it | The seat's entry, and the events that name the address it was taken from |
| Remove me as an admin | The owner removes the admin | The record that the address was an admin, from when to when |
| Delete what Logbook's servers hold | Counters lapse after two days; a connected app's session ends when you disconnect it; an operator can delete a stored file | Logs at Cloudflare for Cloudflare's retention; a file on Walrus until its storage period ends; whatever the outside operators logged |
| Make my address untraceable to me | Remove the card and the list entry | For a Google account, Mysten can compute the address again at any time. Other members may remember |
#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