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

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:

1. Encryption occurs in the user's browser before any data transmission


2. Server infrastructure stores only encrypted data without access to decryption keys


3. Files are automatically deleted after access or expiration


4. User authentication is optional for basic operations


5. 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.