Privacy
What I keep about your lodge, where it lives, who can see it, and how you get it back. Written plainly, by the brother who runs this.
The short version
- Your lodge's records are your lodge's. I look after them for you, use them only to run the software, and hand the lot back in full if you ever leave.
- Everything stays in Australia — on Amazon's servers in Sydney, encrypted, backed up continuously.
- I keep very little about members: a name, an honorific, membership type and, only if your lodge chooses to record it, an email address. No dates of birth, addresses, phone numbers, card numbers or bank logins — there are no fields for them.
- Nothing is sold, shared or used to train AI. Ever. The one AI job — reading a photographed receipt or page of minutes — sends that one image to a specialist service that doesn't train on it.
- I treat the fact of your membership as sensitive, and I follow the Australian Privacy Principles even though a business my size isn't legally required to.
- Only your own officers see your lodge. That's checked on every single request, and every change is logged — who, what, when — for seven years.
- Your lodge can have encryption even I can't unlock — and I recommend it. It's the recommended default for new lodges, chosen by each lodge at setup: members' names and emails are encrypted in your officer's browser before they ever reach me, and I hold no key. Section 9 has the honest detail.
- 1. Who I am
- 2. How I think about this
- 3. What I keep
- 4. What I don't keep
- 5. What I do with it — and never do
- 6. The AI bit
- 7. Where it lives, and who else touches it
- 8. How it's protected
- 9. Encryption only your lodge can unlock — the recommended default
- 10. How long I keep it
- 11. Seeing, fixing, exporting and deleting
- 12. Emails, cookies and counting visitors
- 13. If something happens to me
- 14. A note for Grand Lodges
- 15. Changes, questions, complaints
1. Who I am
I'm the Treasurer of Lodge Trinity for the Masonic Year 2026–27, and LodgeMadeSimple is software I built for our own lodge's books and records and now run for other lodges under that name. In this page "I" means me; "your lodge" means the lodge I've set up on the software; "officers" means the brethren your lodge has asked me to give a sign-in (usually the Treasurer and Secretary); and "members" means the brethren whose details your lodge records.
This covers the app at admin.lodgemadesimple.com, the website at
www.lodgemadesimple.com, and the emails I send and receive in running it. The
agreement between me and your lodge — what I provide, what it costs, and who answers for
what — is the Service Terms; this page is part of it.
2. How I think about this
- Your lodge is in charge of its records. You decide what to record about your members and your money; I provide the tool and keep the data safe. I don't decide what goes in and I don't use it for anything except running and supporting the software.
- I follow the Australian Privacy Principles by choice. The Privacy Act 1988 exempts most businesses with turnover under $3 million. I don't think what a lodge holds deserves the minimum, so I handle it as if the Act fully applied to me — and I treat a brother's membership of the Craft as sensitive information under that Act, because that is what it is.
- Keep little, keep it here, make it easy to leave. The member record is deliberately thin, the data is in Sydney, and getting your records out (or deleted) is part of the deal, not a favour.
3. What I keep
Five kinds of thing. Your officers put in nearly all of it; I collect only the small amount needed to keep the lights on.
| What | Specifically | Where it comes from |
|---|---|---|
| Officer sign-ins | Name, email, a sign-in identity, which lodge(s) the person can open, the role they hold there (Treasurer, Secretary or Admin — for now every role can do the same things; a read-only sign-in for auditors is planned), and when they signed in. | Set up by me when the lodge asks; managed by the lodge after that. |
| The lodge's records | Members: name, honorific, membership type (regular, honorary, affiliated), active or not, an email if the lodge adds one, and which charges they can deliver. Brethren from other lodges: name, home lodge, honorific. Officers for each Masonic year. Annual dues and whether they're paid. Meetings: who attended, dinner takings and guests. Income, expenses and transfers between cash and bank, with a category and description. Receipts and invoices as photos or PDFs. Bank-statement lines the lodge imports to reconcile (date, amount, description — never bank logins). Notice papers and minutes the lodge drafts, uploads or emails in, including the sender and subject of an emailed notice. | Typed, uploaded or emailed in by your officers. |
| The activity log | For everything created, changed or deleted: who, when, and what changed (the before and after). So the lodge can audit itself, and so a new Treasurer can see exactly what the last one did. | Written automatically. |
| Technical bits | Ordinary server and app logs (IP address, browser, pages requested, errors, response times) and a cookieless count of page views. Used only to keep it running, fast and secure. | Generated automatically when you use it. |
| Messages to me | What you send through the contact form, the in-app "Feedback & help" link or by email, with your name and address; and the lodge's billing contact for its annual invoice. | From you. |
The demo lodge on the website is made-up brethren and made-up money.
4. What I don't keep
- No dates of birth, home addresses, phone numbers, occupations or next-of-kin — there are no fields for them.
- No card numbers, no bank logins. The software records that a payment happened; it never takes money.
- Nothing about a member's health, family or circumstances.
- No tracking cookies, advertising identifiers or marketing profiles.
Your officers can of course type anything into a free-text box like an expense description or the minutes. I'd ask you to keep personal detail there to what the record genuinely needs.
5. What I do with it — and what I never do
I use what's in the software to:
- run it for your lodge — show your officers the records, produce your reports, notice papers and statements, keep your accounts;
- keep it secure — sign officers in, check on every request that they can only see their own lodge, spot misuse, enforce the per-lodge caps;
- help you — answer questions, set things up, sort out the changeover at installation, look into a problem you report;
- send the lodge its annual invoice and the occasional notice about the service;
- improve the software, using aggregate numbers about how it's used (which features get used, for example) — never an individual lodge's records.
I never sell or rent anything; share it with advertisers or data brokers; email members to sell them things; use any lodge's records to train an AI; or open a lodge's records for any reason other than helping that lodge when it asks, investigating a security problem, or because the law makes me.
6. The AI bit
There are exactly three places the software uses AI, and each only happens when someone asks for it:
- Reading a receipt. Photograph it, and the image goes to Anthropic's Claude, which reads off the vendor, amount, date and likely category. The officer then confirms or corrects it.
- Reading minutes. Upload a photo of handwritten or typed minutes and the same service transcribes it into the minute sections for editing.
- Setting a lodge up. If a lodge joining hands me its member roll on paper, I can photograph that page and the same service reads the names off it, so I'm not typing them in one by one. That's the one case where a page carrying members' names goes to the service — only ever the roll your lodge gave me for exactly that purpose, only during setup, and your officers review the result before anything is saved.
Only the one image and my instructions are sent — nothing else from the lodge's records. Under Anthropic's commercial terms the content isn't used to train their models and is kept only briefly for misuse monitoring. The photo itself stays filed with your other records in Sydney. Your lodge can also turn AI off for good in its Settings — then nothing is ever sent to an AI service, officers type things in by hand, and I type your roll in by hand too. The switch covers all three uses, including mine. On a lodge with member-privacy encryption (section 9), the receipt- and minutes-reading aren't available at all — the server can't read an encrypted image, so there is nothing it could send.
7. Where it lives, and who else touches it
All of it — records, receipts, documents, accounts, backups — sits on Amazon Web Services in Sydney. A handful of specialist services handle small, specific things; I chose them for their security and their terms restrict what they may do with the data. Here's the complete list.
| Who | For what | What they see | Where |
|---|---|---|---|
| Amazon Web Services | Hosting, database, files, sign-in, backups, email — sending ours, and receiving what's sent to a lodge's notice-paper address or my help@ address — and the monitoring that tells me when something's slow or broken. | Everything. | Sydney. |
| Anthropic | Reading receipt, minutes and setup roll photos (section 6). | That one image and my instruction, per request. | United States. |
That's it — I don't send information anywhere else, in Australia or overseas. If Australian law or a court ever requires me to hand something over, I'll do so and tell the lodge unless I'm prohibited from doing that.
If your lodge uses the desktop app. There's an offline version that runs on a lodge officer's own computer, where the records stay — not on my servers. It does send the service one small thing: a licence check, carrying the licence's own id, the lodge id, the app's version and a random number that identifies the installation (not the person), so I can tell a licence isn't being used on more computers than it's licensed for. Never any of the lodge's records.
8. How it's protected
- Each lodge sees only itself, checked every time. Every request names the lodge it's for, and the software confirms on the spot that the signed-in officer has been given access to that lodge and what their role allows. One lodge's Treasurer cannot read another lodge's books. Automated tests check this isolation before every release.
- Encrypted on the way (HTTPS) and at rest.
- No public sign-up. I set each lodge up by hand; the lodge adds its officers.
- Backed up continuously. The database can be restored to any point in the last 35 days; uploaded files keep earlier versions for 12 months.
- Every change logged with who and when, kept for seven years.
- Caps on uploads and AI scans per lodge, so a compromised sign-in can't do much damage.
I won't claim certifications I don't hold or that anything is unbreakable. If your lodge or Grand Lodge wants more detail on any of this, ask and I'll walk you through it.
9. Encryption only your lodge can unlock — the recommended default
Everything in section 8 still stores your roll on the server in a form that could, in principle, be read by whoever holds that server. If your lodge would rather nothing readable ever reach the server at all, member-privacy encryption stops that too. It is per lodge, chosen at setup, and what I recommend for every new lodge — unless a lodge prefers otherwise, I set it up switched on. A lodge that declines it works exactly as this page describes everywhere else.
When it's on, a member's name and email — along with the vendor and "submitted by" name on an expense, the payer name on income, a visiting brother's name, a South visitor's name on a meeting, the text of notice papers, and uploaded receipt and minutes files — are encrypted in the officer's own browser before they're ever sent to me. What I store is ciphertext: scrambled bytes I cannot turn back into names. Reading them needs a passphrase that never leaves the browser and that I never receive.
- Built on the browser's own cryptography. AES-GCM with keys derived by PBKDF2, using WebCrypto — no third-party crypto library. The whole scheme is one small file of about 200 lines, and anyone technical your lodge or Grand Lodge asks can read it end to end.
- Several keyholders. More than one officer can hold access, each with a passphrase of their own choosing — so the key doesn't leave with one person.
- Recovery goes to the lodge, never to me. A one-time recovery code is delivered to the lodge's own email address, and getting back in never routes through me. Whoever can read that inbox holds the way back in, so the code should be kept as carefully as a master key.
- I cannot read it. There is no master key on my side. There is nothing to hand over that reads.
How hard is it to break? The AES-256 encryption itself can't be brute-forced — there are more possible keys than atoms in the earth. So the only real attack is guessing the passphrase, and the 600,000-round key stretching makes each guess cost real computing time. That means the strength is set by the passphrase — specifically, by how many words are in it. Taking words chosen at random, here is roughly how long an attacker who had stolen the whole encrypted database would need:
| Passphrase | Criminal with a GPU cluster | Nation-state (≈1,000× that) |
|---|---|---|
| 4 random words — the minimum “copper willow tin garden” | a few years | about a day |
| 5 random words “amber pilot marble hedge lantern” | ~25,000 years | ~25 years |
| 6 random words “cedar orbit ribbon flint marsh clover” | ~200 million years | ~200,000 years |
This is why the app asks for at least four words, with a space between each, and shows a strength meter as you type. Four words already puts you beyond a criminal with a stolen copy of the database; five or six beyond any attacker, at any budget, for many thousands of years. Longer wins: a memorable phrase of several words beats a short complex one. (Cautious figures for today's hardware and my current settings; "random" means chosen by chance, not a saying you'd recognise — a phrase you make up yourself can be weaker than its word count suggests, which is one more reason to go long.)
And the recovery code isn't a back door around this: it's 128 random bits, generated for you — far stronger than even a six-word passphrase, so it's never the easier way in. A keyholder can regenerate it at any time, which retires the old one.
Being honest about the edges is part of the point:
- It's encryption, not deletion. The (encrypted) data still lives on my hosting in Sydney. I can't read it; it is still there.
- Metadata isn't hidden. I can still see that a lodge exists, roughly how many members it has, and when records change — just not who anyone is.
- Your officers' login emails stay in the clear — signing in needs a real email address, so that one identifier isn't encrypted. It's a login identity, separate from the encrypted member roll.
- A few features switch off while I can't read what I hold: the AI receipt-scanning and minutes-reading (the server can't read an encrypted image), my bulk member-import at setup, and — for now — the emailed-in notice-paper path. Everything else works as normal.
10. How long I keep it
- While your lodge uses it — everything, so the lodge always has its full history. (Your lodge's own record-keeping duties — generally seven years for financial records — are yours; the software simply never throws anything away.)
- If your lodge leaves — I give you a complete export (section 11), then delete the lodge's data within 14 days of your asking or the end of your subscription, whichever you prefer. Backups age out within a further 35 days, earlier file versions within 12 months.
- Activity log entries expire by themselves seven years after they're written.
- Emails in — a notice paper emailed to the lodge's notices address is filed within minutes and the email itself is deleted on the spot; other mail to my addresses keeps its raw copy (attachments included) for 7 days, and the conversation itself I keep as long as it's useful for the matter at hand.
- Technical logs last one to three months.
11. Seeing, fixing, exporting and deleting
Lodges: your officers can see and correct every record in the app. Ask and I'll send a full export — members, accounts, dues, attendance, documents, the activity log — as spreadsheets and PDFs, and delete the lot as described above. No charge for either, no questions asked.
Members: your lodge, not me, decides what's recorded about you, so the quickest way to see or fix your details is a word to your lodge Secretary.
Officers: you can change your own name and email in the app. When you leave office, the lodge removes your access; your name stays on the log entries you made so the lodge's history stays true.
12. Emails, cookies and counting visitors
I email officers about the service: sign-in and password messages, the lodge's annual invoice and reminders, and notices such as planned maintenance or a change to this page. I don't send marketing email, and I never email members. If your lodge records a member's email address, it sits there for the lodge's own use; I don't send anything to it.
The app uses only the cookies and browser storage needed to keep you signed in. The website has no analytics at all; the app measures its own errors and speed with Amazon's monitoring in Sydney — cookieless, no identifier stored — which is why there's no cookie banner. No advertising or social-media trackers anywhere.
13. If something happens to me
Fair question to ask of a one-man operation. Three things are in place: your lodge can export everything, any time, free; a second, trusted person holds access to the accounts the software runs on, so it keeps running if I can't; and if I ever wind it down, every lodge gets at least 90 days' notice and its complete records. I'll put that in writing for any lodge or Grand Lodge that asks.
14. A note for Grand Lodges
I understand a Grand Lodge carries responsibility for its lodges' information. For any jurisdiction looking at LodgeMadeSimple I'll gladly sign a written data-handling agreement built on this page and the Grand Lodge's own requirements; provide a technical security summary or fill in a security questionnaire; agree continuity terms — notice periods, and how each lodge gets its own records back if I ever stop; and, if the Grand Lodge prefers, turn the AI features off across its jurisdiction — every lodge can already do this for itself in its Settings — so nothing at all leaves Australia.
15. Changes, questions, complaints
I'll update this page as the software changes. Anything material — a new provider, a new use, anything leaving Australia — I'll email to every lodge's officers before it takes effect, and update the date at the top. Small clarifications I'll just publish here.
Questions, requests and complaints: privacy@lodgemadesimple.com.