Lantern Security Architecture

Last Updated: January 4, 2026
Version: 1.0

Our Security Philosophy

Lantern is built on the principle of privacy by design. We strive to implement the strongest security measures possible while maintaining usability. We are transparent about our approach and actively welcome community feedback to identify and address potential vulnerabilities.

Core Commitment: If we don't have your data, we can't leak it, lose it, or be forced to hand it over.

Hybrid Security Architecture

Lantern uses different encryption strategies for different types of data:

1. Profile Data (Zero-Knowledge Encryption)

What: Birth date, real name (if any), sensitive PII
How: Passphrase-based client-side encryption
Storage: Encrypted ciphertext on Firestore

User passphrase (never leaves device)
    ↓
Derives AES-256 key (PBKDF2, 600k iterations)
    ↓
Encrypts data client-side
    ↓
Server stores: encrypted blob + public salt

Result: Backend CANNOT decrypt without user's passphrase

Implementation: See ZERO_KNOWLEDGE_ENCRYPTION.md

2. Chat Messages (Device-Only Storage)

What: Direct messages between users
How: Stored locally on device, server only relays
Storage: Device's encrypted local storage (IndexedDB)

Alice writes message
    ↓
Encrypted on Alice's device
    ↓
Relayed through server (no storage)
    ↓
Delivered to Bob's device
    ↓
Decrypted on Bob's device
    ↓
Stored in Bob's local IndexedDB (encrypted)

Result: Server NEVER stores chat history

Why This Approach:

✅ Server cannot access message content
✅ Simpler than full Signal Protocol
✅ Users control their own data
✅ Fast, no server storage costs
⚠️ Messages lost if device is lost (unless backed up)

What: Lantern names, interests, mood, venue check-ins
How: Stored plaintext in Firestore
Why: Required for social discovery and matching

Rationale: These fields are intentionally public/semi-public for the app to function. Privacy is maintained by:

Not collecting photos (ever)
Not displaying ages
Auto-deleting check-ins after 48 hours
Anonymous Lantern names instead of real names

4. Location Data (Ephemeral Processing)

What: GPS coordinates for proximity features (Waves, check-ins, Lantern Hub)
How: Requested from browser, validated by server, immediately discarded
Storage: NONE - location is NEVER persisted

User grants browser location permission
    ↓
Browser provides GPS coordinates (one-time)
    ↓
Client sends to server for proximity check
    ↓
Server validates (IP cross-check, velocity check)
    ↓
Server responds: "You are within 50ft of User X" OR "Check-in valid"
    ↓
Location data DISCARDED (not stored)

Privacy Model:

✅ Location used in real-time for proximity calculations
✅ Location validated server-side to prevent spoofing
❌ Location history NEVER stored
❌ Movement tracking NEVER implemented
❌ Location profiles NEVER built

Security Considerations:

Browser permission required (user must explicitly allow)
Permissions Policy restricts to same-origin: geolocation=(self)
Server-side validation prevents location spoofing (see TODO.md)
IP geolocation cross-check catches VPN-based fake locations
Velocity checks flag impossible travel (teleportation detection)

Data Retention:

GPS coordinates: 0 seconds (processed and discarded)
Check-in events: 48 hours (timestamp + venue ID only, no GPS)
Wave interactions: 7 days (user IDs only, no location)

Threat Mitigation:

Location spoofing → Server-side validation with IP cross-check
Stalking → Pattern detection, block functionality, shadow banning
Merchant fraud → WiFi verification, fraud scoring, rate limiting

See docs/TODO.md → "Location Security & Anti-Fraud" for complete threat model and mitigation roadmap.

Security Features by Category

Authentication & Access Control

Feature	Implementation	Status
User authentication	Firebase Auth	✅ Live
Passphrase strength	12+ chars, mixed case, numbers, symbols	✅ Implemented
Passphrase hashing	PBKDF2, 600k iterations	✅ Implemented
Session management	Key cached in memory, cleared on logout	✅ Implemented
Multi-device support	Re-enter passphrase on new device	✅ Designed
Account recovery	Backup codes (planned)	⏳ TODO

Data Encryption

Data Type	Encryption	Storage	Can Server Decrypt?
Birth date	✅ AES-256-GCM	Firestore	❌ No
Real name (if collected)	✅ AES-256-GCM	Firestore	❌ No
Chat messages	✅ Device encryption	Device only	❌ Not stored
Lantern name	❌ Plaintext	Firestore	✅ Yes (public)
Interests	❌ Plaintext	Firestore	✅ Yes (public)
Mood	❌ Plaintext	Firestore	✅ Yes (public)
Check-ins	⚠️ Partial	Firestore (48hr)	⚠️ Geohash only

Data Retention

Data Type	Retention Period	Auto-Deletion
Check-ins	48 hours	✅ Yes
Wave history	7 days	✅ Yes
Chat messages	Device-dependent	⚠️ User's responsibility
Encrypted PII	Until account deletion	✅ Yes (30 days after request)
Public profile	Until account deletion	✅ Yes

Threat Model

What We Protect Against

✅ Database breach - Encrypted PII remains secure
✅ Rogue employee - Cannot access encrypted data
✅ Legal data requests - Cannot decrypt what we don't have keys for
✅ Man-in-the-middle attacks - HTTPS everywhere (Cloudflare)
✅ Server compromise - Chat messages not stored on server
✅ Session hijacking - Firebase Auth token security

Known Limitations

⚠️ Lost passphrase - Data unrecoverable (by design)
⚠️ Compromised device - Local data accessible if device unlocked
⚠️ Phishing attacks - Users can be tricked into revealing passphrase
⚠️ No forward secrecy (chat) - Same encryption key for all messages from a user
⚠️ Metadata visible - Server knows who's chatting with whom (not content)

Future Improvements Under Consideration

🔄 Signal Protocol integration - For perfect forward secrecy in chat
🔄 Backup codes - Account recovery without compromising security
🔄 Encrypted metadata - Hide social graph from server
🔄 Hardware security keys - Optional 2FA with YubiKey, etc.
🔄 Sealed sender (chat) - Hide sender identity from server

Why Not Full Signal Protocol Everywhere?

Short answer: Tradeoffs between security and simplicity.

Detailed reasoning:

Signal Protocol Would Provide

✅ Perfect forward secrecy (past messages safe even if key compromised)
✅ Post-compromise security (future messages safe after key rotation)
✅ Deniability (cryptographic proof messages are authentic)

But Would Require

❌ Complex key management infrastructure
❌ Online key directory (public key lookup service)
❌ Ratcheting state synchronization across devices
❌ Significant development and maintenance overhead
❌ Harder to audit for small team

Our Current Approach

✅ Simple, auditable encryption (standard AES-256-GCM)
✅ Zero-knowledge for sensitive PII
✅ Device-local storage for ephemeral chats
✅ Easier to implement correctly
✅ Lower attack surface (simpler code)

We may upgrade to Signal Protocol in the future as the platform matures and we have security engineering resources to implement and maintain it correctly.

Security Posture vs. Competitors

Feature	Lantern	Signal	WhatsApp	Instagram DMs
E2E encrypted messages	⚠️ Partial*	✅ Yes	✅ Yes	❌ No
Server stores messages	❌ No	❌ No	❌ No	✅ Yes
Profile encryption	✅ Yes	❌ No	❌ No	❌ No
Photos stored/shared	❌ Never	✅ Yes	✅ Yes	✅ Yes
Real names required	❌ No	✅ Phone#	✅ Phone#	✅ Yes
Forward secrecy	❌ No	✅ Yes	✅ Yes	❌ No
Open to audits	✅ Yes	✅ Yes	⚠️ Partial	❌ No

*Device-local encryption, not E2E

Lantern's unique position: We prioritize anonymity + zero-knowledge PII storage over feature richness.

Community Security Program

We Welcome Security Research

Lantern is committed to transparency and continuous improvement of our security posture. We actively encourage:

🔍 Security audits from the community
🐛 Vulnerability reports via responsible disclosure
💡 Suggestions for security improvements
📊 Public security discussions on our GitHub

How to Report Security Issues

Please DO:

Email security concerns to: security@ourlantern.app (when available)
Use GitHub Issues for non-sensitive security discussions
Wait for acknowledgment before public disclosure (responsible disclosure)
Provide detailed reproduction steps

Please DON'T:

Publicly disclose critical vulnerabilities before we've patched them
Test vulnerabilities on production systems without permission
Use automated scanners that could disrupt service

What to Expect:

Acknowledgment within 48 hours
Status updates every 7 days
Credit in our security advisories (if you want)
Public fix timeline (we aim for 30 days for critical issues)

See VULNERABILITY_DISCLOSURE.md for full policy.

Security Audits & Reviews

Date	Auditor	Scope	Status
TBD	External firm	Full security review	⏳ Planned
TBD	Community	Open source review	⏳ Planned

We will publish audit results publicly (with sensitive details redacted).

Security Roadmap

Phase 1: Foundation (Current)

[X] Zero-knowledge profile encryption
[X] Device-local chat storage
[X] Passphrase-based key derivation
[X] Auto-deletion of ephemeral data
[X] HTTPS everywhere
[ ] Backup codes for recovery

Phase 2: Hardening (Next 6 months)

[ ] External security audit
[ ] Penetration testing
[ ] Bug bounty program
[ ] Encrypted metadata (geolocation)
[ ] Rate limiting and abuse prevention

Phase 3: Advanced (12+ months)

[ ] Signal Protocol for E2E chat
[ ] Hardware security key support
[ ] Sealed sender (hide social graph)
[ ] Zero-knowledge proofs for age verification
[ ] Homomorphic encryption for analytics

Transparency Commitments

What We Publish

✅ This security architecture - Our approach, tradeoffs, limitations
✅ Vulnerability disclosures - After patches are deployed
✅ Audit results - Full reports (sensitive details redacted)
✅ Data requests - Transparency reports (when legally allowed)
✅ Source code - Open to community review (planned)

What We Don't Publish

❌ Unpatched vulnerabilities - Until fixes are deployed
❌ User data - Ever. We don't have access anyway.
❌ Internal security details - That would aid attackers

Legal & Compliance

Data Requests

When law enforcement or government requests user data:

We verify the request is legally valid
We provide ALL data we have (compliance)
This includes:
- Encrypted PII (ciphertext only)
- Public profile data
- Account metadata (creation date, last login)
We CANNOT provide:
- Decrypted PII (we don't have passphrase)
- Chat message content (not stored on server)

Our stance: We comply with valid legal requests, but our architecture ensures we have minimal useful data to provide.

Transparency Reports

We will publish annual transparency reports including:

Number of data requests received
Number of requests complied with
Number of accounts affected
Types of data provided

(Subject to legal restrictions in some jurisdictions)

Questions & Feedback

For Users

See User Security Guide for:

How to create a strong passphrase
What to do if you lose your passphrase
How to verify Lantern's security claims
Understanding privacy tradeoffs

For Security Researchers

See Vulnerability Disclosure Policy for:

Responsible disclosure process
Scope and rules of engagement
Recognition and rewards (when available)

For Developers

See Security Development Guidelines (TBD) for:

Secure coding practices
Encryption API usage
Common pitfalls to avoid

Updates to This Document

This security architecture will evolve as Lantern grows. Major changes will be:

Documented in GitHub commit history
Announced to users (if user-impacting)
Reviewed by security advisors
Published with clear changelog

Last major update: January 4, 2026 - Initial architecture documented

Summary

What makes Lantern secure:

✅ Zero-knowledge encryption for PII (we can't decrypt)
✅ Device-local chat storage (we don't store)
✅ Aggressive data deletion (we don't keep)
✅ No photos, no real names, no ages (we don't collect)
✅ Transparent about limitations (we don't hide)
✅ Open to community review (we don't gatekeep)

What we're working on:

External security audits
Bug bounty program
Signal Protocol integration
Continuous improvement based on community feedback

Our commitment: Best-effort security, radical transparency, and openness to improvement.

If you find a vulnerability or have suggestions, please reach out. We're listening. 🔒

Lantern Security Architecture ​

Our Security Philosophy ​

Hybrid Security Architecture ​

1. Profile Data (Zero-Knowledge Encryption) ​

2. Chat Messages (Device-Only Storage) ​

3. Public Social Data (Unencrypted) ​

4. Location Data (Ephemeral Processing) ​

Security Features by Category ​

Authentication & Access Control ​

Data Encryption ​

Data Retention ​

Threat Model ​

What We Protect Against ​

Known Limitations ​

Future Improvements Under Consideration ​

Why Not Full Signal Protocol Everywhere? ​

Signal Protocol Would Provide ​

But Would Require ​

Our Current Approach ​

Security Posture vs. Competitors ​

Community Security Program ​

We Welcome Security Research ​

How to Report Security Issues ​

Security Audits & Reviews ​

Security Roadmap ​

Phase 1: Foundation (Current) ​

Phase 2: Hardening (Next 6 months) ​

Phase 3: Advanced (12+ months) ​

Transparency Commitments ​

What We Publish ​

What We Don't Publish ​

Legal & Compliance ​

Data Requests ​

Transparency Reports ​

Questions & Feedback ​

For Users ​

For Security Researchers ​

For Developers ​

Updates to This Document ​

Summary ​