Zero-Knowledge Promise
We cannot read your notes, even if we wanted to. Your data is encrypted on your device before it ever reaches our servers. Only you have the keys to decrypt your content.
How Typelets Encryption Works
Typelets uses client-side encryption with a zero-knowledge architecture. Here's exactly how your notes are protected:
1. Client-Side Encryption (AES-256-GCM)
- Algorithm: AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode)
- Key Derivation: PBKDF2 with SHA-256, 250,000 iterations
- Unique IVs: Each note gets a unique 12-byte initialization vector
- Encryption Location: Your browser, before any data leaves your device
2. Master Password System
Typelets requires you to set a master password on first use. This master password is the foundation of your security:
- Mandatory Setup: You must create a master password before using the app
- Master Password + Per-Note Salt: Each note uses your master password combined with a unique per-note salt
- Key Derivation: 250,000 PBKDF2 iterations make brute-force attacks computationally infeasible
- Memory Protection: Keys derived in browser memory, never transmitted to servers
- Password Changes: Master password can be changed with automatic re-encryption of all notes
3. Master Password Change Process
When you change your master password, Typelets automatically re-encrypts all your data:
- Secure Re-encryption: All notes are decrypted with old password and re-encrypted with new password
- Atomic Operation: Password change either succeeds completely or fails with no data loss
- Key Rotation: New encryption keys are derived from your new master password
- Zero Downtime: Process happens seamlessly without interrupting your workflow
4. What Gets Encrypted
Note Content
Title and content encrypted separately with same IV
Metadata
Folder assignments and organization data protected
File Attachments
Uploaded files encrypted with same security model as notes
Server-Side Security
What Our Servers Store
Encrypted Data (What we store)
- Encrypted note titles and content (unreadable blobs)
- Initialization vectors (IV) for each note
- User account metadata (email, creation date)
- Folder structure (encrypted folder names)
What We Never See
- Your actual note content
- Note titles in readable form
- Your encryption keys
- Any decrypted information
Infrastructure Security
- AWS Hosting: Enterprise-grade cloud infrastructure with SOC 2 compliance
- TLS 1.3: All data in transit protected with latest encryption standards
- Database Encryption: Encrypted storage at rest (though data is already encrypted)
- Access Controls: Strict authentication and authorization for all system access
- Regular Audits: Continuous security monitoring and vulnerability assessments
Authentication & Access Control
Clerk Authentication
We use Clerk for secure user authentication, providing:
- Multi-Factor Authentication (MFA): Optional 2FA for enhanced account security
- Session Management: Secure JWT tokens with automatic expiration
- Password Security: Industry-standard password hashing and validation
- Account Recovery: Secure backup keys that you control
Important: Master Password Recovery Limitation
Due to our zero-knowledge architecture, if you forget your master password, your notes cannot be recovered. Not even our team can decrypt your data. Your master password is the only key to your encrypted notes - store it securely.
Privacy by Design
Data Minimization
- No Analytics: We don't use Google Analytics or similar tracking
- No Behavioral Tracking: We don't monitor how you use the app
- No IP Logging: We don't store your IP address or location data
- Essential Cookies Only: Only session cookies for app functionality
Open Architecture
Our security model is designed to be transparent:
- Client-Side Code: Encryption happens in your browser using standard Web Crypto APIs
- Verifiable Security: You can inspect the encryption process in your browser's developer tools
- Standard Algorithms: We use well-established, peer-reviewed cryptographic methods
- No Security Through Obscurity: Our security doesn't rely on hiding our methods
Technical Implementation Details
Encryption Process Flow
1
Master Password Entry
User enters master password for key derivation
2
Content Encryption
Encrypt note content with AES-256-GCM
3
Secure Transmission
Send encrypted data over TLS to servers
4
Encrypted Storage
Store only encrypted blobs in database
Decryption Process
1
Retrieve Data
Download encrypted note from servers
2
Key Recreation
Derive encryption key from master password + note salt
3
Local Decryption
Decrypt content in your browser
4
Display Content
Show readable content in the app
Security Auditing & Compliance
Regular Security Practices
- Dependency Scanning: Automated vulnerability scanning of all code dependencies
- Security Headers: Proper HTTPS, CSP, and other security headers implemented
- Penetration Testing: Regular security assessments by third-party experts
- Incident Response Plan: Documented procedures for security incident handling
Compliance Standards
- Encryption Standards: NIST-approved algorithms (AES-256, SHA-256)
- Key Management: Follows NIST guidelines for cryptographic key management
- Data Protection: Designed to support GDPR compliance requirements
- Industry Best Practices: Follows OWASP security guidelines
Threat Model & Risk Assessment
What Typelets Protects Against
Data Breaches
Even if our servers are compromised, your notes remain encrypted and unreadable
Government Requests
We can only provide encrypted data that's impossible to decrypt without your keys
Insider Threats
Our own employees cannot access your note content
Man-in-the-Middle Attacks
TLS encryption protects data in transit; client-side encryption protects against any interception
Security Limitations (Honest Disclosure)
- Browser Security: We rely on browser security and Web Crypto API implementations
- Key Loss: Lost passwords and backup keys mean permanently lost access to notes
- Social Engineering: We cannot protect against attacks that trick you into revealing credentials