Security
Protection Built In, Not Bolted On
Security was foundational to Village design. Your community's data stays protected, isolated, and under your control.
Our Security Philosophy
We believe security comes from architecture, not promises. Village was designed from day one to protect your community's data through technical measures, not just policies. Here's what that means in practice.
What We Protect
🔐 Your Stories & Content
Family narratives, photos, and documents are encrypted in transit and protected at rest through tenant isolation, access controls, and server-side encryption for stored files. Only your community members can access them.
👥 Your Membership
Member information is visible only within your Village. Other Villages cannot see your member list.
💬 Your Conversations
Chat messages and video calls stay within your community. Video calls use encrypted WebRTC transport with optional end-to-end encryption.
🗳️ Your Decisions
Governance votes and polls are private to your community. Voting records are protected.
What We Don't Do
Understanding what we refuse to do is just as important as understanding our protections.
Vendor Exclusions
- No Google services anywhere (no Docs Viewer, no Fonts, no Analytics)
- No Facebook/Meta integration or tracking pixels
- No third-party analytics that track your behaviour
- No advertising networks or data brokers
- No tracking CDNs on public pages. Member media loads from the Village's own servers, same-origin, so the member's session applies to every request and no CDN sees it
Data Practices We Refuse
- We never sell your data to anyone
- We never share data with third parties for marketing
- We never use your content to train AI models
- We never mine your data for insights to sell
- We never track you across websites
Federation Security
When Villages connect through Federation, security remains paramount. Federation enables collaboration without compromising independence.
How Federation Protects You
- Each Village controls exactly what they share with partners
- Federation agreements are explicit and documented
- Either party can adjust or revoke access at any time
- Shared content is clearly marked as federated
- Dispute resolution processes protect both communities
Think of it like neighbours agreeing to share a garden path, not handing over house keys. Each Village remains sovereign over their own space while choosing specific, controlled connections with others.
Access Controls
Who Can Access Your Data
- Your Members: Full access to content they're authorised to see
- Your Moderators: Administrative access within your Village only
- Platform Operators: Infrastructure access only, never content access
Technical Security Measures
We implement industry-standard security practices across our infrastructure.
Encryption in Transit
All connections use TLS 1.3. Your data is encrypted between your device and our servers.
Data Protection at Rest
Data is protected at rest through multiple layers including application-level encryption for sensitive credentials, server-side encryption for file storage, and infrastructure access controls.
Secure Authentication
Passwords are hashed with bcrypt. Session tokens are cryptographically secure and time-limited.
CSRF & XSS Protection
All forms use CSRF tokens. Content Security Policy headers prevent script injection.
Post-quantum signature
Sealed records can carry a second signature, ML-DSA-65 (NIST FIPS 204), beside the first. It is turned on per account.
Which records, and how to check it
It is on today for the Villages on our EU host that have it turned on. Provenance seals, Governance API receipts, Email Decision Record receipts and proof-chain summaries carry it. The downloadable checker verifies it, and the key fingerprint is on the evidence index. The implementation is our own, tested against NIST’s published test vectors and checked against two independent implementations; no person has audited it.
Threat Response: April 2026
In April 2026, Anthropic disclosed a model capable of discovering software vulnerabilities at scale across every major operating system and writing working exploits for them. The capability class will proliferate within 12–18 months. This changes the security landscape for every organisation that stores data on infrastructure it does not control.
Village’s architecture has a small attack surface, and the application and its data are hosted on EU and NZ infrastructure that is not US-owned. No US-owned company holds Village content. The two US services that can receive anything from us receive no content: Midnight, which is built to receive one hash a day where anchoring is turned on, and Let’s Encrypt, which sees only our server names. Anything else that can touch a US service, such as push notifications through your device vendor, the public STUN server our video bridge may ask for its own address, or the optional Xero integration, is named under Third-Party Services below with what it receives. We have taken specific steps to strengthen our position against the scenarios this capability enables.
Encryption at Rest
All data on both production servers (EU and NZ) is encrypted using AES-256-CBC via Percona Server for MongoDB. MDSL holds the keys in a key file on the same server, kept apart from the database files, so a copy of the database files alone does not yield readable data. Completed April 2026.
48-Hour Patch Cycle
When vulnerabilities are disclosed in Linux, Node.js, MongoDB, or Nginx, we apply patches within 48 hours on both servers. Our two-server architecture makes this tractable — we can patch both servers in hours, not the months that large enterprises require.
File Integrity Monitoring
Both servers run AIDE (Advanced Intrusion Detection Environment) with daily automated integrity checks against established baselines. Unauthorised file modifications are detected rather than assumed absent.
No US Cloud Dependencies
The US CLOUD Act gives US authorities the power to compel disclosure of data held by US companies, regardless of where the data is physically stored. No US-owned cloud hosts Village or holds its content. Hosting on EU (OVH France) and NZ (Catalyst Cloud) sovereign infrastructure addresses both legal compulsion and the security risks that now compound it.
For a detailed analysis of the threat landscape, read Mythos and the Economics of Cyberattack and the AI Governance series.
Our answers to the seven questions
Our page on what “sovereign” has to mean sets seven questions to put to any provider that calls itself sovereign. Here are our answers for Village, as at 9 November 2026, with the outside services named in full under Third-Party Services above.
1. Who owns the company, all the way up?
Village is run by My Digital Sovereignty Ltd (MDSL), a New Zealand company, NZBN 9429053246547. Its director is John Stroh, and the company works from Amberley, New Zealand.
MDSL owns the software and operates the servers it rents. The servers belong to two hosting companies, Catalyst Cloud in New Zealand and OVH in France, and neither is US-owned.
2. Can a foreign law reach your data?
New Zealand law reaches MDSL, because MDSL is a New Zealand company. We handle personal information under the New Zealand Privacy Act 2020 and, where it applies to you, the GDPR. Our agreement with you is governed by New Zealand law in New Zealand courts, without taking away consumer rights you have where you live.
Each Village is held on one server in one country, never split: in France on OVH, under French and EU law, or in New Zealand on Catalyst Cloud, under New Zealand law. No US-owned company hosts or stores Village content, so the CLOUD Act route that runs through a US provider does not run through our hosts.
That tells you who holds the data. It does not put Village outside the law: any company answers to the law of the countries where it is incorporated and where it operates, and a request from another country can arrive through New Zealand’s own legal process.
Some things do leave that boundary, and Third-Party Services above names each with what it receives: translation text goes to DeepL in Germany, email passes through Proton in Switzerland, place names go to Nominatim in the UK. Three matter most to this question. Time-stamping authorities in Europe receive a fingerprint (a hash) of a record, never the record. Anchoring on the Midnight ledger is built: where it is turned on, the ledger is to receive one hash a day, the hash of our signed daily estate root, and nothing else. And a community that turns on the optional Xero integration sends its own financial data to Xero, a New Zealand company running on US infrastructure, which US law can reach.
3. Who holds the encryption keys?
There are three kinds of key, and the answer differs for each.
Storage keys. The databases on both servers are encrypted at rest with AES-256 (Percona Server for MongoDB). MDSL holds the keys in a key file on the same server, kept apart from the database files, so a copy of the database files alone does not yield readable data.
Signing keys. MDSL holds the signing key for every active Village today. The keys sit on a separate signing host that MDSL operates at OVH in France, outside the application that writes records: the application sends what is to be signed, and the private key never leaves that host. Under the arrangement in place today, every active Village’s signing key is held on that host in France, whether the Village is hosted in New Zealand or the EU.
Because MDSL holds these keys, a lawful order served on MDSL can reach what MDSL can decrypt or sign. That is why the process under the fifth question is written down. We have also built and deployed a split-key arrangement in which two of three key holders must sign together, so MDSL cannot sign alone; no Village is on it yet.
Transport keys. Connections use TLS 1.3. The certificates are issued by Let’s Encrypt, and the private keys stay on our servers.
4. Where do the support staff work?
Village is built and run from Amberley, New Zealand, by MDSL’s director, with AI agents doing the building and the reviewing under his direction.
Platform administrators manage the servers and answer support requests. Through the application they cannot read a Village’s stories, photos or messages; only the Village’s own moderators have that authority. The hosting companies’ staff, in New Zealand and in France, have the access any host has to its hardware. The databases are encrypted at rest under keys MDSL manages, not the hosts; the key file sits on the same server, so that encryption protects a copy of the database files, not a server someone has control of.
The help assistant inside Village runs on our own infrastructure with a local model, so a question you type to it stays on our servers. If you ask in German, French, Dutch or te reo Māori, the text of the question and of the answer passes through DeepL in Germany for translation.
5. What happens under a foreign court order?
Our terms set out the process. Where we receive a binding legal request, we comply only with what we actually hold, in the form we hold it, and we will not build new means of access in order to comply. Where data is held in encrypted form to which we do not hold the keys, we cannot produce its contents. We notify the affected community before responding, unless the law prohibits it.
The same process applies whether the request comes from a New Zealand authority or from an overseas one acting through New Zealand’s legal-assistance arrangements. We do not destroy records, purge audit logs or tamper with keys in response to a request or in anticipation of one, and the hash-linked record histories are built so that a deleted or reordered entry in the middle of a history can be seen; removing the newest entries is not yet detectable. We do not disclose a community’s information to anyone, a state included, without lawful compulsion or the community’s own authorisation.
6. Can you leave with your data intact?
Yes. You can export your records at any time in an open format. For 90 days after the agreement ends we keep them available for export, then delete them, except copies the law makes us keep. If MDSL stops providing Village, our terms give at least 90 days’ notice (60 is the least the general terms allow) and keep your records exportable for 90 days after the end.
Any member can file an access or portability request, confirm it from an email link, and download their own data as JSON, CSV or PDF, with a portability certificate signed under the Village’s key that a receiving Village can verify. A Village owner, administrator or moderator can export the Village’s shared records one record type at a time, page by page, through the Village’s programming interface.
Sealed records stay checkable by anyone holding the record and the public verification material, whether or not MDSL continues to operate. The checking programs are downloadable, run offline, and each is published with its SHA-256.
7. Can an outsider check the claim?
Village is built by AI agents under John Stroh’s direction and reviewed by AI agents. No person has audited the code, and no outside firm has assessed its security.
One piece of outside human review exists: the Governance API sandbox was reviewed by an experienced architect, as an expert peer review. That is a review, not an audit and not a penetration test.
What you can check today without trusting us: downloadable offline checkers for sealed records, consignment files and Village Gateway decision exports, each published with its SHA-256; time-stamps from outside authorities under RFC 3161, which the checkers verify; the signed daily estate root in our published index, with its two time stamps and any ledger anchor it carries; and, on accounts where it is turned on, a second, post-quantum signature (ML-DSA-65) on sealed records, which the downloadable checker verifies.
The answers in this section were checked by AI agents against the code on 9 November 2026.
What We Have Introduced
We have added three features to strengthen the security of every Village.
Two-Factor Authentication (2FA)
A second verification step when you log in — a code from an authenticator app on your phone. Even if your password is compromised, your account remains protected.
- Easy setup — scan a QR code with any authenticator app
- Backup codes — eight single-use recovery codes in case you lose your device
- Village policy — your administrators can set 2FA as optional, recommended, or required
Security Awareness Check
A brief five-question questionnaire each quarter when you log in. Topics include recognising phishing emails, password management, shared device safety, and suspicious links.
- Educational, not punitive — no consequences for wrong answers
- Takes about two minutes — five questions, one from each category
- Earn a badge — completing the check awards a quarterly security awareness badge
AI-Moderated Discussions
For important community decisions, AI provides neutral, factual context to help inform the debate.
- AI briefing — a neutral summary of background information, approved by a moderator
- Comment classification — labels comments as factual claims, opinions, or questions
- Discussion summary — a neutral summary of the debate, generated and approved by moderators
- Guardian Agents — every factual claim is verified against source material and labelled with a confidence badge before you see it
What We Don't Disclose
Transparency is important, but so is operational security. We deliberately don't publish certain details.
This page tells you what we protect and what principles guide us. The how remains appropriately confidential.
Email Decision Record
Email Decision Record, our service for deciding on outgoing email and recording each decision, has its own security page. It covers the keys each organisation holds, signed and timestamped receipts, checking records without us, the exact mailbox permissions it asks for, and where its data is held.
Email Decision Record security · Email Decision Record service status
Reporting Security Issues
We take security reports seriously. If you discover a potential vulnerability:
Responsible Disclosure
- Email security concerns to: security@mysovereignty.digital
- Include detailed reproduction steps if possible
- Allow reasonable time for us to address the issue before public disclosure
- We commit to acknowledging reports within 48 hours
Questions About Security?
We're happy to discuss our security approach. Contact us for more details about how we protect your community.
Security is an ongoing commitment, not a one-time achievement. We continuously review and improve our practices.
Last updated: November 2026