Executive Summary
I built BurnLink, an open-source file sharing service that prioritizes privacy through client-side encryption and zero-knowledge architecture. This article outlines the technical approach, design decisions, and lessons learned from developing a production-grade privacy-focused application.
The Problem Statement
Traditional file sharing services rely on server-side storage and management of user files. This creates inherent security challenges:
- Service providers maintain persistent file storage
- Centralized infrastructure creates single points of failure
- Encryption at rest does not eliminate server-side access risks
- User metadata and access patterns remain visible to service operators
- Long-term liability for data retention
A better approach would eliminate the need for users to trust a third party with their sensitive data.
Solution Architecture
BurnLink implements a zero-knowledge file sharing system with the following principles:
- Encryption occurs in the user's browser before any data transmission
- Server infrastructure stores only encrypted data without access to decryption keys
- Files are automatically deleted after access or expiration
- User authentication is optional for basic operations
- Complete source code is publicly available for audit
Encryption Flow
The encryption and data handling process follows this sequence:
1. User selects file in browser
2. Browser generates encryption key locally
3. File encrypted using AES-256-GCM in browser
4. Encrypted file uploaded to server
5. Server generates one-time access token
6. Decryption key transmitted separately via URL fragment
7. URL fragment not sent in HTTP headers
8. Recipient downloads encrypted file
9. Browser decrypts locally using key from URL
10. File automatically deleted from server
The critical design decision: encryption keys never reach the server infrastructure. The URL fragment remains client-side only and is not transmitted to servers in HTTP requests.
Technical Implementation
Architecture Components
Frontend
- Client-side encryption using Web Crypto API
- Vanilla JavaScript implementation for minimal dependencies
- Progressive enhancement for broader compatibility
Backend
- Node.js runtime with Express framework
- PostgreSQL database for metadata management
- Object storage for encrypted file retention
Infrastructure
- Docker containerization for deployment flexibility
- Support for multiple hosting platforms
- Environment-based configuration
Core Technologies
- Language: JavaScript (Node.js)
- Framework: Express.js
- Database: PostgreSQL
- Storage: Object storage provider
- Encryption: AES-256-GCM (Web Crypto API)
- Deployment: Docker, serverless functions, or traditional VPS
Feature Set
Security Capabilities
- Client-side encryption with strong cryptographic algorithms
- Zero-knowledge server architecture
- Single-use access tokens
- Brute-force protection with automatic account lockout
- CSRF token protection
- No user tracking or analytics collection
- No third-party data sharing
User Experience Features
- Registration-free operation
- Drag-and-drop file upload interface
- Optional password protection
- Customizable expiration periods
- View-once mode with 60-second access window
- Support for batch file operations
Developer Features
- REST API for programmatic access
- Self-hosting capability
- MIT open-source license
- Comprehensive documentation
- Docker support for containerized deployment
Design Decisions and Rationale
Why Open Source
Security software benefits from public scrutiny. Open-source release enables:
- Community security audits
- Bug identification and resolution through collaborative effort
- Adoption by organizations with self-hosting requirements
- Trust building through transparency
Why Client-Side Encryption
Server-side encryption provides compliance with storage regulations but does not eliminate the need for users to trust the service provider. Client-side encryption ensures:
- No single organization has complete access to files
- Transparency through code availability
- User control over encryption process
Why Zero-Knowledge Architecture
Zero-knowledge design ensures that even service operators cannot access file contents. This provides:
- Protection against internal data breaches
- Compliance with privacy regulations
- User confidence in privacy guarantees
Implementation Challenges and Solutions
Technical Challenges
Challenge: Web Crypto API inconsistencies across browsers
Solution: Compatibility testing and polyfill strategies
Challenge: Secure key derivation from user passwords
Solution: Implementation of industry-standard key derivation functions
Challenge: Managing encryption state in single-page applications
Solution: Careful state management using local browser storage
Challenge: Rate limiting and DDoS protection
Solution: Implementation of per-endpoint request throttling
Operational Challenges
Challenge: Monitoring encrypted data for quality assurance
Solution: Metrics collection on encrypted metadata only
Challenge: User support without access to file contents
Solution: Comprehensive error messaging and documentation
Challenge: Infrastructure cost optimization
Solution: Efficient storage management and automatic cleanup policies
Lessons Learned
Technical Insights
- Web Crypto API provides robust encryption capabilities with careful implementation
- Zero-knowledge architecture requires comprehensive system design, not just encryption
- Rate limiting and anti-abuse measures are essential from deployment start
- Infrastructure costs increase significantly with scale
Community Insights
- Transparency and clear communication build user trust
- Comprehensive documentation reduces support burden
- Open-source projects require ongoing maintenance commitment
- Community contributions significantly improve code quality
Business Insights
- Privacy and security are increasingly valued by users
- Self-hosting option appeals to enterprise and security-conscious users
- Open-source development model can be competitive advantage
- Security credentials and third-party audits build market confidence
Future Development
Planned enhancements include:
- Third-party security audit and publication
- Mobile application development
- Team collaboration features
- Performance optimization for high-throughput scenarios
- Advanced analytics for self-hosted deployments
Community Contribution
The project welcomes contributions from developers, security researchers, and users:
- Bug reports and issue tracking: GitHub Issues
- Code contributions: Pull requests welcome
- Security vulnerability reporting: Responsible disclosure process
- Feature requests: GitHub Discussions
Conclusion
BurnLink demonstrates that privacy-first file sharing can be both technically sound and user-friendly. Open-source development enables transparency, security audits, and community participation. The project shows that building privacy-respecting tools is possible without compromising functionality or usability.
Resources
- Project Repository: https://github.com/paperfrogs-hq/BurnLink
- Live Deployment: https://burnlink.page
- Documentation: https://github.com/paperfrogs-hq/BurnLink/wiki
- Security Policy: https://github.com/paperfrogs-hq/BurnLink/blob/main/SECURITY.md
For questions, feedback, or contributions, please visit the GitHub repository or open a discussion in the community forums.
Top comments (0)