🔒 TempSend

1. Overview

TempSend is a privacy-first file sharing service that uses end-to-end encryption to ensure your files remain private. Unlike traditional file sharing services, TempSend never has access to your files or encryption keys. All encryption happens in your browser before files are uploaded.

Key Principle: If we can't decrypt your files, neither can anyone else (including hackers, governments, or even us).

2. Encryption Architecture

2.1 Encryption Algorithm: AES-256-GCM

TempSend uses AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode) for file encryption:

• AES-256: Industry-standard encryption with 256-bit keys (2^256 possible keys)
• GCM Mode: Provides authenticated encryption, ensuring both confidentiality and integrity
• Key Strength: Considered secure against quantum computers for the foreseeable future
• Performance: Fast encryption/decryption suitable for large files

2.2 Key Generation

Encryption keys are generated in your browser using the Web Crypto API:

• Keys are generated using cryptographically secure random number generation
• Each file or room gets a unique 256-bit encryption key
• Keys are never transmitted to the server
• Keys are only stored in URL fragments (after the # symbol)

2.3 Initialization Vectors (IVs)

Each file uses a unique Initialization Vector (IV):

• IVs are 96 bits (12 bytes) for AES-GCM
• Generated randomly for each file
• Stored alongside encrypted files (IVs are not secret)
• Ensures the same file encrypted twice produces different ciphertext

3. File Upload Process

Here's what happens when you upload a file:

1. Key Generation: Your browser generates a random 256-bit AES key
2. IV Generation: A unique 96-bit IV is generated for the file
3. Encryption: The file is encrypted using AES-256-GCM with the key and IV
4. Encoding: The encrypted file (ciphertext) is encoded as base64url
5. Upload: Only the encrypted file and IV are sent to the server
6. Storage: The server stores the encrypted blob and metadata (filename, size, MIME type, expiry)
7. Key Storage: The encryption key is included in the URL fragment (after #), which is never sent to the server

Important: The server never sees the plaintext file or the encryption key.

4. File Download and Decryption

When someone accesses a file:

1. URL Parsing: The browser extracts the file ID and encryption key from the URL fragment
2. Metadata Request: The browser requests file metadata (filename, size, IV) from the server
3. Blob Download: The encrypted file blob is downloaded from the server
4. Decryption: The file is decrypted in the browser using the key and IV
5. Display/Download: The decrypted file is displayed or downloaded

Security: If the key is missing or incorrect, decryption fails. The server cannot decrypt files even if compromised.

5. Locked Rooms

TempSend supports "Locked Rooms" - encrypted galleries where multiple files share the same encryption key:

• Room Creation: A room is created with a unique room ID and expiry time
• Room Key: A single encryption key is generated for the entire room
• Shared Key: All files in the room are encrypted with the same room key
• Key Distribution: The room key is included in the room URL fragment
• Multiple Files: Users can upload multiple files to the same room
• Independent IVs: Each file still uses a unique IV for security

Use Case: Perfect for sharing multiple files with a group - share one link, everyone can access all files.

6. Chat Encryption

TempSend includes encrypted chat functionality within rooms:

• Room Key Reuse: Chat messages are encrypted using the same room key
• Client-Side Encryption: Messages are encrypted in the browser before sending
• Unique IVs: Each message uses a unique IV
• In-Memory Storage: Messages are stored in server memory (not persisted to disk)
• Automatic Deletion: Messages are deleted when the room expires
• Private Messages: Private messages are encrypted with the same room key but include recipient information

Privacy: The server never sees plaintext chat messages, only encrypted ciphertext.

7. Automatic Expiry and Deletion

TempSend implements automatic expiry to ensure content doesn't persist indefinitely:

• File Expiry: Individual files can have their own expiry times (30 sec, 1 min, 5 min, 15 min, 30 min, 1 hour, 6 hours, or room expiry)
• Room Expiry: Rooms expire based on their creation settings (5 min, 30 min, 1 hour, 6 hours, 12 hours)
• Automatic Cleanup: Expired content is automatically deleted from the database and disk
• No Recovery: Once expired, content cannot be recovered
• Background Process: Cleanup runs periodically to remove expired content

Privacy Benefit: Automatic deletion ensures your files don't remain on servers indefinitely.

8. Server-Side Security

While encryption happens client-side, we also implement server-side security measures:

• HTTPS/TLS: All connections use TLS encryption for transport security
• Swiss Servers: Servers located in Switzerland with strong data protection laws
• No Logging: We do not log IP addresses, user agents, or request details
• Minimal Metadata: Only essential metadata is stored (filename, size, MIME type, expiry)
• Encrypted Storage: Encrypted file blobs are stored on disk
• Database Security: SQLite database with WAL mode for better concurrency
• No Backups: We do not keep backups of expired or deleted content

9. What the Server Never Sees

Critical Security Guarantee: The server never has access to:

• Plaintext file contents
• Encryption keys (for files or rooms)
• Decrypted chat messages
• User identities or personal information
• IP addresses (we don't log them)
• Browser information or device identifiers

Even if the server is compromised, attackers cannot decrypt your files without the encryption keys (which are only in URL fragments, never sent to the server).

10. URL Structure and Key Storage

TempSend uses a special URL structure to keep keys private:

• URL Format: /room.html#roomId:roomKey
• Fragment Identifier: Everything after the # is the URL fragment
• Never Sent to Server: URL fragments are never transmitted in HTTP requests
• Client-Side Only: Fragments are only accessible via JavaScript in the browser
• Key Security: This ensures encryption keys never leave your device

Important: If you share a URL, you're sharing the encryption key. Only share with trusted recipients.

Password Protection: Rooms can be password protected, which adds an additional layer of security. However, if you share the URL (which contains the encryption key), anyone with the URL can access the room even without the password. Password protection is useful for preventing unauthorized access if someone gains access to the URL, but it does not prevent access if the URL itself is shared.

11. Voting System

TempSend includes a voting system for files:

• Anonymous Voting: Votes are tracked using hashed fingerprints (not personally identifiable)
• Fingerprint Generation: Combines IP address, User-Agent, and Session ID (hashed, not stored in plaintext)
• One Vote Per File: Each fingerprint can vote once per file (up, down, or neutral)
• Vote Toggle: Users can change their vote or remove it
• Privacy: We don't store personally identifiable voting information

12. Abuse Reporting System

TempSend includes a privacy-preserving abuse reporting system:

• Anonymous Reporting: Reports use hashed fingerprints (not personally identifiable)
• Threshold-Based Deletion: Content is automatically deleted after multiple unique reports
• No Content Logging: We don't log the content of reported files
• Moderator Review: Reports can be reviewed by moderators (if implemented)

13. Technical Specifications

Encryption:

• Algorithm: AES-256-GCM
• Key Size: 256 bits
• IV Size: 96 bits (12 bytes)
• Key Derivation: Web Crypto API random generation

Encoding:

• Ciphertext: Base64url encoding
• IVs: Base64url encoding
• URLs: URL-safe characters only

Storage:

• Database: SQLite3 with WAL mode
• File Storage: Encrypted binary blobs on disk
• Chat: In-memory storage (not persisted)

14. Security Guarantees

What TempSend guarantees:

• Files are encrypted before leaving your device
• Encryption keys never leave your device (URL fragments only)
• The server cannot decrypt your files
• Even if the server is compromised, files remain encrypted
• No tracking, analytics, or third-party data collection
• Automatic expiry and deletion of content

What you're responsible for:

• Safeguarding encryption keys (in URLs)
• Sharing URLs securely with intended recipients only
• Using the service in compliance with laws and terms
• Backing up important files before uploading

15. Limitations and Considerations

Important limitations to be aware of:

• Key Loss: If you lose the encryption key, files cannot be recovered
• Expiry: Files automatically expire and are permanently deleted
• URL Sharing: Sharing a URL shares the encryption key - only share with trusted recipients
• Browser Security: Encryption depends on browser security - use updated, secure browsers
• No Recovery: We cannot recover lost keys or expired files
• Service Availability: Service may experience downtime or interruptions

16. Open Source and Transparency

TempSend is designed with transparency in mind:

• Client-side code is visible in your browser (JavaScript)
• You can inspect the encryption implementation
• No hidden backdoors or data collection
• Privacy-first architecture is verifiable

Verification: You can verify that encryption happens client-side by inspecting the browser's JavaScript code and network requests.

17. Comparison to Other Services

How TempSend differs from traditional file sharing:

18. Best Practices

To maximize security and privacy:

• Use updated, secure browsers
• Only share room/file URLs with trusted recipients
• Don't share URLs in public places (social media, forums)
• Set appropriate expiry times for your content
• Back up important files before uploading
• Verify the URL contains the encryption key (after #)
• Use HTTPS when accessing TempSend
• Clear browser history if using a shared device

19. Frequently Asked Questions

Q: Can TempSend decrypt my files?

A: No. We never have access to encryption keys, so we cannot decrypt your files even if we wanted to.

Q: What happens if I lose the encryption key?

A: Unfortunately, files cannot be recovered without the encryption key. This is by design for security.

Q: Can the government access my files?

A: Even with a warrant, we cannot decrypt your files because we don't have the encryption keys. Only someone with the key (in the URL) can decrypt files.

Q: Is TempSend open source?

A: The client-side code is visible in your browser. You can inspect the JavaScript to verify the encryption implementation.

Q: How do I know my files are secure?

A: You can verify security by inspecting the browser's network requests (encrypted files only), checking the JavaScript code (client-side encryption), and confirming keys are only in URL fragments.

20. Security Details Explained

At the bottom of each room page, you'll see a security details bar that shows the current security status of the room. Here's what each indicator means:

Lock Status

• 🔒 Locked (Green): The room is password protected. A password is required to access the room and its files. This provides an additional layer of security beyond encryption.
• 🔓 Unlocked (Gray): The room is encrypted but not password protected. Anyone with the room URL (which contains the encryption key) can access the room. This is still secure because all files are encrypted, but there's no password barrier.

Password Protected

If you see "Password Protected" with a checkmark, the room has password protection enabled. This means:

• The server enforces password verification before allowing access to room metadata or files
• You must enter the correct password to access the room
• Password verification is required both client-side and server-side for security
• Even if someone has the room URL, they cannot access the room without the password

Encrypted

All rooms show "Encrypted" with a checkmark. This means:

• All files are encrypted using AES-256-GCM encryption
• Encryption happens in your browser before files are uploaded
• The server never sees unencrypted file contents
• Only someone with the encryption key (in the URL) can decrypt files

AES-256-GCM

This indicates the encryption algorithm used:

• AES-256: Advanced Encryption Standard with 256-bit keys (industry standard)
• GCM: Galois/Counter Mode provides authenticated encryption (confidentiality and integrity)
• This is the same encryption standard used by banks and government agencies

Important Note: Even if a room is "Unlocked" (not password protected), it is still fully encrypted. The difference is that anyone with the room URL can access it. Password protection adds an additional barrier, but sharing the URL still shares access to the room.

21. Verification Limitations

Important Disclaimer: While we would love to guarantee that encryption keys are never shared with the server, it is theoretically impossible to provide such verification without exposing the server's codebase to everyone. Doing so would itself create a major security vulnerability. We appreciate your understanding of this limitation.

You can inspect the client-side JavaScript code and verify that encryption happens in your browser. However, there is no way to definitively prove that the server never receives encryption keys without compromising the server's security. This is a fundamental limitation of web-based encryption systems.

Despite this limitation, we have designed TempSend with privacy by design principles:

• All encryption code is visible in your browser (JavaScript)
• You can inspect network requests to verify only encrypted data is sent
• URL fragments (where keys are stored) are never sent in HTTP requests
• The server has no mechanism to request or receive encryption keys
• Password protection is enforced server-side to prevent unauthorized access

22. Conclusion

TempSend is designed with privacy and security as the top priorities. By implementing end-to-end encryption with client-side key generation, we ensure that your files remain private even if our servers are compromised.

Key Security Practices:

• Keep URLs secure: URLs contain encryption keys - only share with trusted recipients
• Use updated browsers: Ensure your browser supports modern encryption APIs
• Set appropriate expiry: Choose expiry times that balance convenience and security
• Verify the URL: Always check that URLs contain the expected # fragment with the key

For more details, review our Privacy Policy and Terms of Service.