Building Trustworthy Applications Through Security by Design
Most applications that handle your personal data don't encrypt it.
They store it in plaintext on third-party servers. They send it through public APIs to train machine learning models. They back it up to cloud services owned by companies you've never heard of.
Then they call it "privacy."
They'll add a privacy policy. They'll mention encryption in their marketing. They'll promise not to sell your data (while still feeding it to third-party AI companies). And they'll sleep fine at night because they technically followed the letter of the law.
But here's what nobody says out loud: if you're building a tool that stores personal details about someone's relationships — their health struggles, their family situations, their career anxieties, their confidential professional contacts — you have an obligation. Not a feature. An obligation.
The obligation to make sure that data never leaves your control.
We started building Meaningful around this principle. And it forced us to rethink everything about how modern applications are built. More importantly, it forced us to rethink how we write secure code.
The problem with "privacy as a feature."
When privacy is treated as a feature, it becomes optional.
It's something you add because users ask for it. Something you charge money for. Something you mention in the landing page copy and then move on.
But privacy for relationship data isn't optional. It's fundamental.
Consider what happens when you log a note about your friend: "struggling with depression, mentioned it over coffee." That's not metadata. That's not an email. That's someone's private life. If that leaks, it doesn't just expose data. It violates trust.
Or what happens when you record a voice note after talking to a colleague: "internally frustrated with management, looking for exit opportunities." That's career-sensitive information. In the wrong hands, it ends someone's opportunities.
Most relationship management tools don't think about this at all. They treat relationship data the same way they treat any other user data: convenient to store, easy to monetize, useful for training models.
The problem is relationship data is different.
It's not your data alone. It's other people's personal lives. Their most precious memories. Things they told you in confidence that you're just keeping a note about.
What goes wrong when relationship data leaks
It's not hypothetical.
In 2021, a misconfigured S3 bucket leaked millions of contact records from a major CRM platform. Not just names and phone numbers. Notes. Conversation history. Personal details.
In 2023, an AI training dataset included relationship management tool exports — full chat histories, personal notes, everything. People's private thoughts about their friends and colleagues became training data for a language model.
It doesn't have to be a headline breach. Sometimes it's just negligence.
A developer leaves a MongoDB connection string with authentication disabled. A backup gets stored in the wrong region. A third-party API integration gets compromised. A disgruntled employee exports user data.
And suddenly, everything you recorded about your relationships is out there.
But here's what's worse: you probably didn't even know it was vulnerable. Because the tool you trusted with that data didn't encrypt it. They just promised to "keep it safe." Which is like promising to keep your house safe by having the front door unlocked but hoping no one walks in.
Why third-party AI is a privacy nightmare
Most "AI features" in relationship tools are actually just API calls to OpenAI or Anthropic.
Your relationship data gets sent to their servers. They process it. They return a response. And somewhere in the terms of service, it says they might use your data to improve their models.
The companies doing this aren't being malicious. They're following their business model. But the business model is: user data is a training asset.
So when you ask your personal CRM "who haven't I talked to in 3 months?" you're not just getting an answer. You're sending your entire contact list, interaction history, and relationship context to a third-party server. Where it gets logged. Cached. Possibly included in training data.
This is especially problematic for relationship data because it reveals patterns about your actual life. Your friends. Your family. Your professional network. Your vulnerabilities.
An AI trained on millions of people's relationship data can infer things about you that you never explicitly said. It can infer who your best friends are. Who your romantic interests might be. Who's struggling. Who's isolated.
That's not data you consented to share. And definitely not data you should have to share to use a relationship management tool.
How we built Meaningful differently
When we started building Meaningful, we made a different choice.
We decided: relationship data stays in your control. Full stop.
That meant several technical decisions that complicate our infrastructure but protect your privacy. And it meant establishing a security-first development process to ensure we never accidentally compromise that promise.
Encryption at rest with per-user keys and salts
All personal data — your contacts, your notes, your interaction history, anything sensitive — gets encrypted with AES-256-CTR before it touches our MongoDB database.
But here's the part that matters: we don't use a single master key for all users.
Each user gets a unique encryption salt stored in their account. When we encrypt their data, we derive a unique key for that user using:
userKey = HMAC-SHA256(ENCRYPTION_KEY, userId + encryptionSalt)
This means:
- If our database is compromised, attackers get encrypted data
- Even if the master encryption key is leaked, they'd need 400+ individual user salts to decrypt anything
- Each user's data is isolated — a breach doesn't expose everyone
Each piece of encrypted data stores a random 16-byte initialization vector (IV) and the ciphertext. On read, we decrypt server-side and strip the ciphertext before sending anything to your browser. You never see the encrypted version. But the database only stores the encrypted version.
This means if someone breaks into our database, they get ciphertext. Not your actual data.
Private AI inference (no third-party APIs)
Our AI assistant, EdgeAI, runs on a dedicated DigitalOcean droplet that we control. Not OpenAI. Not Anthropic. Not any third-party API.
The model is Llama 3.2 3B, open-source and quantized to run on modest hardware (4GB RAM, 2 vCPUs). It processes your requests locally. Your data never leaves our infrastructure.
When you ask EdgeAI "who should I reconnect with?" your contact list, interaction history, and journal entries stay on our servers. The model reads them. Produces a response. And that's it. No logs sent to third parties. No training data harvested.
The trade-off is infrastructure cost and complexity. We pay for a dedicated droplet. We manage model updates ourselves. We own the responsibility if something breaks.
But the benefit is: your relationship data is never exposed to third-party training pipelines.
Local transcription for voice notes
We use faster-whisper (OpenAI's open-source Whisper model) running locally to transcribe voice notes.
You record a note. It gets transcribed on your device or on our servers — but the audio never touches OpenAI. It stays local.
This matters because audio contains not just what you said, but tone, emotion, context. It's rich data about your relationships. Sending it to third parties for transcription would leak that.
Selective encryption based on context
We don't encrypt everything equally because not everything is equally sensitive.
A chat message where you ask EdgeAI "how do I politely decline an event?" gets encrypted because it might involve relationship context.
A chat message where you ask "what's the capital of France?" doesn't get encrypted because it's not personal data.
The decision is made at write time based on the intent of the conversation. App-query and app-action intents (anything touching your actual contacts and relationships) get encrypted. General knowledge and chitchat don't.
This is a tradeoff: encrypted data can't be cached or quickly searched across users. But it's the right tradeoff for relationship data.
Building a security-first development strategy
Here's what sets security apart from other technical choices: you can refactor a bad architecture. You can rewrite inefficient code. But you can't "fix" a security breach after the fact.
We take security seriously. And we don't share your data with anyone because we know how important it is for you.
That means security isn't something we patch in at the end. It's woven into how we think about every feature, every API, every line of code that touches your data.
Writing secure code isn't about writing it once and hoping it works. It's about building security reviews into your development process.
We didn't want to just implement encryption. We wanted to make sure the implementation was actually solid. So we built a systematic security review workflow.
Starting with the security-reviewer skill
We started by adapting the security-reviewer skill from the Claude Code community. This skill provides a comprehensive framework for detecting OWASP Top 10 vulnerabilities, hardcoded secrets, injection attacks, and unsafe cryptographic practices.
But we realized a general-purpose security reviewer wasn't enough for our specific needs. We needed custom security reviews for the three areas that matter most for Meaningful: encryption, authentication, and input validation.
Building three custom security skills
We created three specialized security review skills tailored to our codebase:
1. security-review-encryption.md
This skill checks:
- No hardcoded encryption keys (always in
process.env) - Salt generation uses
crypto.randomBytes()(not predictable) - Key derivation uses HMAC-SHA256 (strong hash)
- No plaintext data logged after encryption
- Version field prevents algorithm downgrades (old data stays readable)
This skill checks:
- All sensitive routes have
authmiddleware - Passwords hashed with bcrypt (never plaintext comparison)
- JWT tokens validated on every request
- No hardcoded secrets
- Role-based access control enforced
This skill checks:
- All user inputs validated (type, length, pattern)
- No SQL injection (using parameterized queries)
- No XSS (React auto-escapes, but we verify)
- File uploads have size and type limits
- API responses filtered (passwords/secrets never returned)
Core security checks we run
For every code change touching encryption, auth, or user input, we run these checks:
# 1. Check for hardcoded secrets
grep -r "ENCRYPTION_KEY\|API_KEY\|SECRET" server/ \
--include="*.js" | grep -v "process.env" | grep -v ".env"
# 2. Check for SQL injection patterns
grep -r "query.*req\.body\|query.*req\.query" server/ --include="*.js"
# 3. Check for plaintext password comparison
grep -r "password\s*==" server/ --include="*.js"
# 4. Check for unprotected routes
grep -r "router\.\(post\|put\|delete\)" server/routes --include="*.js" \
| grep -v "auth" | grep -v "public"
# 5. Run npm audit
npm audit --audit-level=high
# 6. Check encryption key derivation
grep -r "deriveUserKey\|HMAC\|hmac" server/utils/encryption.js
Quick security audit script
We also use a quick shell script that developers can run before committing:
#!/bin/bash
echo "🔐 Security Audit — Meaningful"
echo "================================"
echo "1. Checking for hardcoded secrets..."
grep -r "ENCRYPTION_KEY\|API_KEY\|SECRET\|password" server/ \
--include="*.js" | grep -v "process.env" | grep -v ".env" || echo "✅ No secrets found"
echo -e "\n2. Checking npm dependencies..."
npm audit --audit-level=high || echo "⚠️ Some vulnerabilities found"
echo -e "\n3. Checking for unprotected routes..."
grep -r "router\.\(post\|put\|delete\)" server/routes --include="*.js" \
| grep -v ", auth" | grep -v "public" || echo "✅ All sensitive routes protected"
echo -e "\n4. Checking encryption usage..."
grep -r "encrypt\|decrypt" server/routes --include="*.js" \
| grep -v "encryptionSalt" | head -5
echo -e "\n✅ Audit complete. Review findings above."
This is the kind of thing that's boring to do manually but trivial to automate. By running it every time code touches security-sensitive areas, we catch problems early.
The infrastructure cost of privacy
Being privacy-first is expensive.
We run a second server just for AI inference. We manage encryption keys and rotation ourselves. We store more data (encrypted data is larger than plaintext). We can't use certain optimization techniques that would require plaintext access.
If we were comfortable with the standard playbook — send everything to OpenAI, store data plaintext, train on user interactions — we could save significant costs.
But we're not.
Because relationship data isn't a cost center to optimize. It's something we're responsible for protecting.
What this means for you
When you use Meaningful, here's what's actually happening:
- Your contact information and relationship notes get encrypted with AES-256 using a key derived from your account
- Your voice notes get transcribed locally
- Your AI assistant processes everything on a private server
- Your calendar sync stays within your control
- Your data is never sent to third-party AI APIs for training
- We run security audits before every code change touching encryption, auth, or user input
This doesn't make Meaningful immune to data breaches. No system is. But it means if something does go wrong, the damage is limited to encrypted data. And we have a very high responsibility to protect it because we control it entirely.
It also means EdgeAI won't hallucinate as easily. Instead of sending sparse context to a 70B parameter model trained on the entire internet, we send rich, relevant context to a small model running on our infrastructure. The model stays grounded in your actual relationship data instead of making things up based on general knowledge.
The philosophy behind this
This isn't about being preachy about privacy.
It's about recognizing what relationship data actually is: someone's trust, written down.
And it's about recognizing that security is something you build into every decision, not something you bolt on at the end. It's not a feature. It's an obligation.
If you're building an application that touches people's personal information, you need to ask yourself: are we treating security like a feature we'll add later? Or are we building it into the foundation?
The difference matters. And your users will notice.
Resources
If you're building privacy-focused applications, you might find these resources useful:
- Security-reviewer skill — The foundational repository for Claude code from which we adapted the framework
- Meaningful security skills — Our three custom security review skills (encryption, auth, input validation)
- OWASP Top 10 — Essential reference for web application security
Try Meaningful — fully free during alpha.
The code is built on security. The commitment to your privacy is real.