Climate Chorus · Closed pilot · Current as at 23 September 2026
This describes the pilot as it works today: sending is real, and a first-party datastore (Supabase, Australian region) sits behind it. Your message really goes to the decision-maker, from your own email, under your name, and your climate views are handled as sensitive information under the Privacy Act. This document has three parts: A the privacy & collection statement, B the consent and in-app wording (shipped), and C the other documents the pilot needs. Not legal advice.
The app is authoritative and this page is wrong. That rule is here permanently. The app is the thing you actually meet; this is a description of it, and a description can drift. If you spot a difference, tell us at the address below and we will correct it.
Climate Chorus Pty Ltd runs this pilot. For any privacy question, a correction, or to have your details deleted: hello@climatechorus.com.
What we collect, and what you can do about it
| Data | Why | Stored by us? |
|---|---|---|
| Your name (optional) | Goes on the message you send (a real constituent carries more weight) | Only if you save your history |
| Your email (optional) | Two things only: to tell you when a decision you acted on moves, and to send occasional updates on what people did together and what it changed | Yes, if you opt in – on a separate record from your activity |
| Which decisions you follow / have acted on + when | To send relevant updates and measure whether people act, return and share | Yes (linked to your email if given) |
| Suburb / postcode | To show local decisions; marks you as a local constituent on messages you send | On device; sent with your action history if you save it |
| Anonymous device ID + usage events (opened, onboarded, tapped send, returned, shared, which parts of a decision page you open, how far you got in the exit survey) | Product analytics for the use/reuse/share funnel, and for which parts of a decision explanation people actually read | Yes – first-party, into our own datastore. No third-party analytics SDK. No message content, and no survey answers – how far you got is a count and a question name, never what you wrote |
| Recruitment group (from which invitation code you used) | To understand which group acted how | Yes (with events) |
| How you say you’re feeling (optional – the word you pick when you start) | To adapt the app to you: it sets the wording your draft message opens with, and which support page you land on. | No. Your feeling is not recorded and never leaves your device. It is held on your phone so the app can use it, and that is all. We record only that onboarding was finished, not the word you chose. |
| Your answer to the week’s question (optional – one multiple-choice question on the home screen) | Your answer becomes the line your next message opens with. | No. Which option you pick is not recorded and never leaves your device. We record that the card was answered, and which week’s question it was – not what you chose. |
| Life stage (optional – asked once, at the start) | To make sense of the results: whether people at different life stages act, return and share differently | Yes, if you answer it (on your participant record) |
| Prior climate activity (optional – asked once, at the start: whether you have signed a petition, gone to a meeting, or written to a politician, council or government department in the last 12 months) | To make sense of the results: whether people who were already active act, return and share differently. With life stage, it is the second half of the only comparison the pilot makes. This is sensitive information – it says something about your political association – so it is collected only with your consent and only if you choose to answer | Yes, if you answer it (on your participant record) |
| Exit survey responses | To learn what worked and what didn't | Yes – form built into the app, not an external survey tool |
| Draft message content | — we never receive it | No. Drafts stay on your device – see §2a |
The table above is accurate row by row, but read quickly it invites the reading that storage follows from opting in. It does not. Stated plainly, and this is the fact on which most of this statement depends:
Kept from the door onwards, whether or not an address is ever given: the anonymous device identifier; the recruitment group and which Helper's code was used; the optional life-stage and prior-actions answers, once answered; one row per action taken, carrying the decision and a timestamp; and which parts of the app you open – including that you opened the Join tab and looked at a group, but not which group.
Held against a device identifier, not a name. None of the above carries your name. It is held against a random identifier minted by your browser, so on its own it does not identify you.
What the email address is for, and what it is not for. If you give one, we use it for two things: to tell you when a decision you acted on moves, and to send occasional updates on what people did together and what it changed. That is the purpose, and it is the whole of it. The address is not used to follow you around the app, and nothing you do here is emailed back to you as a record of itself.
How your address connects to your activity. Your address sits on a separate record from your activity. The two are joined through the device identifier – that is how we can tell which decisions you acted on, which is what the updates are about. That single join is the only connection between them.
What limits this in practice. Only we read any of it, and only for the two purposes above. The app itself cannot read any of it back: the key it ships with can write to two tables and read nothing at all, so there is no request a modified page or a hostile script could make that would return your data. That is a property of the database's permissions rather than a promise about our conduct, which is why we would rather rest the claim on it.
Deletion breaks the join permanently. The identifier is replaced, so the activity rows survive as counts that can no longer be traced to a person. Before deletion this data is pseudonymous rather than anonymous; after it, de-identified. That distinction is the honest one, and the reason we make it here is that the two words are often used as though they were the same.
Kept only on opt-in: the email address, and with it the ability to be told when a decision moves.
Never sent to us at all: the message and its recipient; the person's name and suburb, which stay on the device unless history is saved. There is no drafts table — the data model could not hold a message if someone wanted it to.
What lives only on your device, and what that costs you. Your onboarding answers, your name and suburb, your draft messages and the app’s own picture of what you have done are held in your browser’s storage and never sent to us. Read with the line above – the app cannot read back any of what we do hold – that has a consequence worth stating plainly rather than leaving you to discover: clearing your site data, browsing in a private window, or opening the app on another device starts you fresh, and nothing can be restored for you. We are not withholding a copy; the design means there is not one to give. Your email address is the one thing that leaves the device.
When you send by email, the app opens your own email app with the message ready, and you send it. The email – its words and who it goes to – travels through your own email provider.
Some decision-makers only take submissions through their own online form, which cannot be pre-filled. There the app copies your message to your clipboard and opens that body’s form in a new tab; you paste it in and submit it there. Your message goes to that organisation through their website, under whatever privacy terms they publish – we are not in the middle of it, and we never see what you sent.
Either way, Climate Chorus never transmits or stores the sent message or the recipient. We record only that you tapped send on a given decision, and which of the two routes it went by.
Decided, and built this way: Climate Chorus does not store draft or sent message content. With the mailto/contact-form hand-off the message never reaches us either way, and the data model reflects that – there is no drafts table; we only record that you tapped send on a given decision, and which route it went by (email or form).
If that ever changes, this statement must say so before it ships: that Climate Chorus staff could read what you wrote, with consent naming that explicitly, and message content and identity kept in separate tables joined by a message ID.
The decisions you act on, and the views in your messages, reveal your political opinions – which are sensitive information under the Privacy Act. So does the optional question at the start about what you had already done – signing, going to a meeting, writing in – which says something about your political association. We only collect and store this with your explicit consent, use it only for the purposes above, never sell it, and share it only with the service providers named in section 5. The question at the start names it as sensitive on the screen where it is asked, and you can skip it.
A letter to the editor is published under your name and suburb – public, permanent and searchable – which is a materially different consent from writing privately to a decision-maker. It is out of scope for this version and will be reintroduced with its own point-of-collection warning at the moment of drafting.
The pilot uses three providers, who only process data on our instructions: hosting (Netlify, static files only), a datastore (Supabase, Australian region) for your email and action history, and email (Google Workspace) for the occasional update, if you give us an address. Opening the app contacts no one else: every file it loads, including the React library and the webfont, is served from our own hosting.
About the email provider. Updates are sent by a person, from a Climate Chorus address, using Google Workspace – not a bulk-mail or marketing platform. Google therefore holds your address and the text of any update we send you, and it processes that outside Australia. Everything else we hold about you stays in the Australian datastore. If you never give us an address, no email provider ever sees anything of yours.
The datastore is Supabase, pinned to an Australian region. Row-level security is enabled on every table. The app in your browser cannot read anything back out of the database – it has no read access of any kind. It can add rows to two places, the usage record and the exit survey, and nothing else. Everything else it does – setting up your record, redeeming your invitation code, saving your address, stopping emails, deleting your data – goes through a small, fixed set of named operations on the server, each of which does one job and nothing more. A technical description of exactly which, for a reviewer, is kept with our internal notes rather than here.
Stopping emails and deleting use separate keys. Each action uses a key minted for that action alone, at the moment you ask for it, which works once and then stops working – within 60 minutes for deleting, 30 days for stopping emails. Asking again issues a fresh one and retires the old. A key for stopping emails cannot delete anything, and a key for deleting cannot stop emails.
Opening either link does nothing on its own: both pages ask you to confirm, and only that confirmation acts and spends the key. So a link followed by accident, or pre-fetched in the background by an email client, neither stops your emails nor deletes anything. AI features remain switched off, so no text is sent to an AI provider.
This describes the Climate Chorus closed pilot as it is built today, and it is kept in step with the app. It is not legal advice. We will have it reviewed and update it before any wider launch, and we will tell you here if what we collect changes.