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, 100,000 iterations
- Unique IVs: Each note gets a unique 12-byte initialization vector
- Encryption Location: Your browser, before any data leaves your device
2. Key Management
Your encryption keys are derived from your unique user ID using industry-standard cryptographic functions:
- User-Specific Salt: Deterministic but unique salt generated from your user ID
- Key Material: Combined user ID and static application salt
- High Iteration Count: 100,000 PBKDF2 iterations for brute-force resistance
- Memory Protection: Keys stored only in browser memory, never sent to servers
3. What Gets Encrypted
Note Content
Title and content encrypted separately with same IV
Metadata
Folder assignments and organization data protected
Tags
All tags and labels encrypted before storage
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: Password Recovery Limitation
Due to our zero-knowledge architecture, if you lose both your password and backup keys, your notes cannot be recovered. Not even our team can decrypt your data. Please store your backup keys 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
Key Derivation
Generate encryption key from user ID using PBKDF2
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
Recreate encryption key from user ID
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)
- Device Security: Your device must be secure; malware could potentially access decrypted data in memory
- 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
Security Recommendations for Users
Best Practices
- Strong Passwords: Use unique, complex passwords for your Typelets account
- Secure Backup Keys: Store your backup keys in a secure password manager
- Enable 2FA: Add an extra layer of security with multi-factor authentication
- Keep Devices Updated: Ensure your devices have the latest security updates
- Secure Networks: Avoid using public Wi-Fi for sensitive note-taking
- Regular Backups: Export important notes periodically as an additional backup