BurnLink: An Open-Source End-to-End Encrypted File Sharing Platform

Joy Majumdar — Wed, 10 Jun 2026 22:49:58 +0000

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.

DEV Community: Joy Majumdar